Show HN: Appwrite – Open-Source and Self Hosted Firebase Alternative(github.com)
github.com
Show HN: Appwrite – Open-Source and Self Hosted Firebase Alternative
https://github.com/appwrite/appwrite
120 comments
I was about to throw in the towel after evaluating Firebase / Supabase last week for a new project I'm working on and revert back to good o'l Laravel, but Appwrite looks very interesting and could potentially solve my problem so I'll definitely check it out!
Just one question: is there also Postgres support?
Just one question: is there also Postgres support?
I’m curious why Supabase didn’t suit your needs, especially since you’re looking for Postgres support?
(Disclosure: supabase ceo)
(Disclosure: supabase ceo)
Hi, when are Supabase Functions expected to be released?
I'm quickly reaching a point in my project where direct DB calls don't cut it and I don't want to muck about with PG functions especially since I'm familiar with other programming languages. :(
Some suggestions: Using Supabase took me 5x the amount of time it should have taken me, honestly. 1. There needs to be more official snippets, PG especially. Create view, modify table, change constraints, and so on. If I'm your target demographic, it pays to watch issues raised/FAQs and integrate it in the UI. For example, I'm not very familiar with SQL and PG features. I had to learn the hard way that RLS does not apply to views. Basic for someone who knows DBs? Maybe. But I'm someone who wants to ship my product and my expertise is elsewhere. Would have loved to see this info in the UI.
2. Some things are just so hard to find! I spent a lot of time looking for something so simple. I think it was views? And also something under user authentication, I don't remember. Maybe you would benefit from user research - get a dev who hasn't used Supabase before, watch them build something with this and then address pain points.
I'm quickly reaching a point in my project where direct DB calls don't cut it and I don't want to muck about with PG functions especially since I'm familiar with other programming languages. :(
Some suggestions: Using Supabase took me 5x the amount of time it should have taken me, honestly. 1. There needs to be more official snippets, PG especially. Create view, modify table, change constraints, and so on. If I'm your target demographic, it pays to watch issues raised/FAQs and integrate it in the UI. For example, I'm not very familiar with SQL and PG features. I had to learn the hard way that RLS does not apply to views. Basic for someone who knows DBs? Maybe. But I'm someone who wants to ship my product and my expertise is elsewhere. Would have loved to see this info in the UI.
2. Some things are just so hard to find! I spent a lot of time looking for something so simple. I think it was views? And also something under user authentication, I don't remember. Maybe you would benefit from user research - get a dev who hasn't used Supabase before, watch them build something with this and then address pain points.
Thanks for the feedback. Extra snippets are a great idea, especially with Row Level Security which is a bit harder to google for.
> when are Supabase Functions expected to be released?
We’re doing another Launch Week starting on Monday next week. You will enjoy Thursday’s launch
> when are Supabase Functions expected to be released?
We’re doing another Launch Week starting on Monday next week. You will enjoy Thursday’s launch
Supabase Functions launching Thursday, March 31st, 2022!
I learned so much about postgresql and RLS from postgraphile starter project: https://github.com/graphile/starter/blob/main/%40app/db/migr...
also the project is worth checking out ;)
also the project is worth checking out ;)
For me, if I want to move quickly, there's just so many great example React + Firebase projects out there. It's so easy to get started, even if I would prefer to work with postgres over nosql. I could have just missed it in the docs or elsewhere, but I couldn't seem to find a really easy to follow todo or chat app or something like that. I created a database I think and then just had little idea how I'd tie it all together with my front-end. So I went back to firebase for an MVP.
Thanks for the feedback. We have these -
Examples: https://supabase.com/docs/guides/examples
React: https://supabase.com/docs/guides/with-react
Is this the type of thing you’re looking for? Perhaps they could be more prominent
Examples: https://supabase.com/docs/guides/examples
React: https://supabase.com/docs/guides/with-react
Is this the type of thing you’re looking for? Perhaps they could be more prominent
https://appwrite.io/docs/installation
https://appwrite.io/docs/production
I would really love to see something like this in the supabase docs. They are currently lacking a little bit for running a self hosted supabase instance for production.
https://appwrite.io/docs/production
I would really love to see something like this in the supabase docs. They are currently lacking a little bit for running a self hosted supabase instance for production.
thanks for the feedback - you're right, the appwrite docs here are very nice!
I'll spend some time today improving our self-hosting docs (https://supabase.com/docs/guides/hosting/overview)
I'll spend some time today improving our self-hosting docs (https://supabase.com/docs/guides/hosting/overview)
Thanks! We're going to be deploying Supabase on prem soon using Kubernetes. (We could probably contribute a Helm chart if you wanted.)
We're also happy paying customers! We need on prem to offer our own customers an on-prem solution.
We're also happy paying customers! We need on prem to offer our own customers an on-prem solution.
We always welcome contributions, but of course - no obligation
Basically the lack of cloud functions (need a place somewhere to run my backend code ) and the Hook Events being in alpha. I know you're working on it but for my project these features are critical.
When Supabase Functions are live and Hooks are stable then it will definitely work for the app I'm working on.
When Supabase Functions are live and Hooks are stable then it will definitely work for the app I'm working on.
You might be interested in what we're building with http://nhost.io. We have serverless functions available together with event triggers (hooks) on database events using Postgres and Hasura (GraphQL).
(Disclosure CEO of Nhost)
(Disclosure CEO of Nhost)
Got it! Make sure to tune in for next-week's Launch Week
I was trying Supabase on a toy project in Elm, ran into a weird CORS error. Even in React when using supabase-js the api call works, but using `fetch` (copied from chrome dev console) in dev console fails with CORS error. Supabase-js does something, which is not visible in the dev console.
Asked on Discord on two different channels after googling it for a while, no response whatsoever.
Supabase seems like a fine project, but without someone answering these kind of queries it's impossible to use.
Asked on Discord on two different channels after googling it for a while, no response whatsoever.
Supabase seems like a fine project, but without someone answering these kind of queries it's impossible to use.
> Supabase-js does something, which is not visible in the dev console
the JS client doesn't do anything special - it just makes a Fetch request to a URL.
You can find the cURL request inside your custom docs (inside the dashboard). Under the hood we use PostgREST: https://postgrest.org
the JS client doesn't do anything special - it just makes a Fetch request to a URL.
You can find the cURL request inside your custom docs (inside the dashboard). Under the hood we use PostgREST: https://postgrest.org
Not yet, but it's coming soon. Appwrite is not coupled to any database or other under the hood technology.
Just curious, did you try Hasura too?
Wow, that's an impressive set of features! I remember kicking the tires on the service a year ago and liked it but didn't have a big need for it. It looks like a lot of great stuff has been added in the time since then.
Thank you so much! We've been working very hard the last year, and looking back - yeh we did add a lot of stuff :)
I put this on Supabase's launch post too, but would you consider supporting a more traditional compute model? i.e. the ability to run an always-on docker container that runs a web server or similar (similar to dokku or heroku). I realise functions are the new hotness, but as far as I can see for non hobby projects they mainly have downsides any very little upside.
From their readme it looks like you can host it however you want:
> Appwrite backend server is designed to run in a container environment. Running your server is as easy as running one command from your terminal. You can either run Appwrite on your localhost using docker-compose or on any other container orchestration tool like Kubernetes, Docker Swarm, or Rancher.
> Appwrite backend server is designed to run in a container environment. Running your server is as easy as running one command from your terminal. You can either run Appwrite on your localhost using docker-compose or on any other container orchestration tool like Kubernetes, Docker Swarm, or Rancher.
Hmm... I think I'm not quite the target market. For me the whole point of a tool like this is that I don't need to worry about maintaining this kind of thing. All the guff around auth and functions is just stuff I have to put up with to get that hosted niceness.
There's two ways to address this if you don't wanna maintain/host.
There will be a hosted Appwrite Cloud option => https://appwrite.io/cloud
There is a way to do 1 click deployment on Digital Ocean Marketplace: https://marketplace.digitalocean.com/apps/appwrite
With these options, you can put off the whole mess with devops, infra, and hosting to someone else :')
There will be a hosted Appwrite Cloud option => https://appwrite.io/cloud
There is a way to do 1 click deployment on Digital Ocean Marketplace: https://marketplace.digitalocean.com/apps/appwrite
With these options, you can put off the whole mess with devops, infra, and hosting to someone else :')
Yes, this is something we would consider in the long run. Functions are great, but not for every use case.
Thank you so much for Appwrite! The community on Discord is very helpful and the self hosting guide is great. Very unlike my terrible experience with Supabase who seem to do their best to cripple the self hosted option
I was hoping someone here would compare the two. I might have to give Appwrite a try after all. Supabase's self-hosted option was wack when I tried it a few months ago.
My honest two cents, which is biased, so take liberal amounts of salt.
I think Supabase is verbose. You get to dig around the PostgreSQL instance, write SQL, etc. I know people that live and die by SQL, so if that sounds like you, Supabase is great.
Appwrite is more about simplicity. Our SDKs are simple, our UI is simple, our Documentation is simple, heck we even have a 1 line deploy: docker run -it --rm \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \ --entrypoint="install" \ appwrite/appwrite:latest
Use a part of Appwrite, or all of it. Heck, go dig in our code or checkout our open sourced Functions runtime. We don't care, we just want you to do more while writing less code.
Both have their audience, both are great, see which one suits your needs better :)
I think Supabase is verbose. You get to dig around the PostgreSQL instance, write SQL, etc. I know people that live and die by SQL, so if that sounds like you, Supabase is great.
Appwrite is more about simplicity. Our SDKs are simple, our UI is simple, our Documentation is simple, heck we even have a 1 line deploy: docker run -it --rm \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \ --entrypoint="install" \ appwrite/appwrite:latest
Use a part of Appwrite, or all of it. Heck, go dig in our code or checkout our open sourced Functions runtime. We don't care, we just want you to do more while writing less code.
Both have their audience, both are great, see which one suits your needs better :)
Our self-hosted solution was designed to be easy to setup in both development and production. I hope you'll enjoy our single command installation.
Also, self-hosting is at the core of what we do and once our cloud solution is out, we don't plan to add weird disabilities to it.
Also, self-hosting is at the core of what we do and once our cloud solution is out, we don't plan to add weird disabilities to it.
What are the issues with self hosting Supabase?
Godot support would be awesome
From my quick research when I was selecting the next backend I was going to use for a project in the past, and today reading some responses on this page:
- Appwrite is written in PHP. Just because something is open source, doesn't mean it is extensible, scalable or otherwise written well. I haven't seen many popular projects written in PHP recently. The only time I used PHP was in university, where the PHP application was the target machine in a CTF.
- AppWrite doesn't yet have their Cloud version, so they aren't ready to be a "backend as a service" - it's a product that isn't ready "as a service". That's why I didn't use it, and I can see similar sentiment here on HN. I'd be willing to try it out when it's ready.
- It's not built on Postgres. Their comment about Supabase using postgres did not include any real substance: "I'm trying to be as objective as I can, but building the entire ecosystem around a single product like Postgres ( even though tried and tested ) comes with its own downsides...". The downsides of what AppWrite might be that they're rolling their own database... in PHP? They may not be database experts, and there's lots to think about and fix when building a database, and Postgres has been tested for a long time.
- Not much progress is happening on the GraphQL side: https://github.com/appwrite/appwrite/pull/974/files, whereas Supabase has it: https://supabase.com/blog/2021/12/03/pg-graphql.
Overall, it seems like the project doesn't move as fast as its competitor (primarily Supabase) for features I care about, and perhaps this is caused by PHP?
Anyway, I'd love to hear your thoughts about my comments, Eldad and team.
- Appwrite is written in PHP. Just because something is open source, doesn't mean it is extensible, scalable or otherwise written well. I haven't seen many popular projects written in PHP recently. The only time I used PHP was in university, where the PHP application was the target machine in a CTF.
- AppWrite doesn't yet have their Cloud version, so they aren't ready to be a "backend as a service" - it's a product that isn't ready "as a service". That's why I didn't use it, and I can see similar sentiment here on HN. I'd be willing to try it out when it's ready.
- It's not built on Postgres. Their comment about Supabase using postgres did not include any real substance: "I'm trying to be as objective as I can, but building the entire ecosystem around a single product like Postgres ( even though tried and tested ) comes with its own downsides...". The downsides of what AppWrite might be that they're rolling their own database... in PHP? They may not be database experts, and there's lots to think about and fix when building a database, and Postgres has been tested for a long time.
- Not much progress is happening on the GraphQL side: https://github.com/appwrite/appwrite/pull/974/files, whereas Supabase has it: https://supabase.com/blog/2021/12/03/pg-graphql.
Overall, it seems like the project doesn't move as fast as its competitor (primarily Supabase) for features I care about, and perhaps this is caused by PHP?
Anyway, I'd love to hear your thoughts about my comments, Eldad and team.
Not the OP but just wanted to weigh in on the PHP point. Just because it isn’t the coolest/hottest language around, doesn’t make PHP any less suitable for a project like this. Laravel in particular has been a game changer for modern PHP-based backends and sites, and the language itself has been steadily evolving and improving. It may not get the column inches of the likes of Phoenix or Remix, but it is stable, battle hardened and fully suitable for the majority of use cases in 2022.
Plus the comment about it being not built on Postgres is absurd.
Postgres is great, but if something is not built on Postgres, it's bad? Use the right tool for the job. This looks like a combination of Redis and Maria, two great products with two different use cases which tells me the developers did think carefully about their architecture.
Postgres is great, but if something is not built on Postgres, it's bad? Use the right tool for the job. This looks like a combination of Redis and Maria, two great products with two different use cases which tells me the developers did think carefully about their architecture.
Can you elaborate what you mean by "comment about not built on Postgres is absurd? I said "It's not built on Postgres.", but I didn't say that was necessarily bad - though it is likely depending on the circumstances. Again, same for PHP, likely bad, but you'd need to know the circumstances, which is why I made the post.
My statement was a response to their employee's comment about the downsides of Postgres, which I quoted. I didn't say what avoiding Postgres is bad, 1. I quoted their unbacked comment, and then 2. I explained it is not bad to use Postgres and actually it's worse to roll your own database. Not sure where you got the fact they use Redis and Maria, that is not very clear on their website, but I found an article on Github: https://github.com/appwrite/appwrite/blob/master/CONTRIBUTIN...
It's much easier to understand Supabase (they use Postgres) vs. AppWrite (I could not find out what they use). They did mention their "new database: completely rewrote the Appwrite data management layer". https://medium.com/appwrite-io/everything-you-need-to-know-a...
My statement was a response to their employee's comment about the downsides of Postgres, which I quoted. I didn't say what avoiding Postgres is bad, 1. I quoted their unbacked comment, and then 2. I explained it is not bad to use Postgres and actually it's worse to roll your own database. Not sure where you got the fact they use Redis and Maria, that is not very clear on their website, but I found an article on Github: https://github.com/appwrite/appwrite/blob/master/CONTRIBUTIN...
It's much easier to understand Supabase (they use Postgres) vs. AppWrite (I could not find out what they use). They did mention their "new database: completely rewrote the Appwrite data management layer". https://medium.com/appwrite-io/everything-you-need-to-know-a...
> I said "It's not built on Postgres.", but I didn't say that was necessarily bad
The three other bullet points are criticisms of Appwrite, and now you're going to claim the fourth point about being not being built on Postgres was not a criticism? You set the tone with your three other arguments. Don't try to claim the fourth wasn't in line.
The Maria and Redis are the first bullet two points in the link you gave. I also actually read the docker-compose file instead of inferring.
The three other bullet points are criticisms of Appwrite, and now you're going to claim the fourth point about being not being built on Postgres was not a criticism? You set the tone with your three other arguments. Don't try to claim the fourth wasn't in line.
The Maria and Redis are the first bullet two points in the link you gave. I also actually read the docker-compose file instead of inferring.
It is your assumption to believe any of them are criticisms. In fact, none are.
"AppWrite is written in PHP", "AppWrite doesn't yet have their Cloud version" and "Not much progress is happening on the GraphQL side" are not criticisms, "It's not built on Postgres" is similar. These are just facts I've come across which others may like. Following each fact, I follow with my thoughts.
Christy Jacob, from AppWrite said an unqualified statement: "I'm trying to be as objective as I can, but building the entire ecosystem around a single product like Postgres ( even though tried and tested ) comes with its own downsides...", and that was my response.
This is a pointless meta discussion though, isn't it? It is childish to assume I meant everything has to be built on Postgres for me to use it, or to make it "proper". If you already think its obviously absurd, you should think why one would say it? Perhaps you misread or there is more to it.
"AppWrite is written in PHP", "AppWrite doesn't yet have their Cloud version" and "Not much progress is happening on the GraphQL side" are not criticisms, "It's not built on Postgres" is similar. These are just facts I've come across which others may like. Following each fact, I follow with my thoughts.
Christy Jacob, from AppWrite said an unqualified statement: "I'm trying to be as objective as I can, but building the entire ecosystem around a single product like Postgres ( even though tried and tested ) comes with its own downsides...", and that was my response.
This is a pointless meta discussion though, isn't it? It is childish to assume I meant everything has to be built on Postgres for me to use it, or to make it "proper". If you already think its obviously absurd, you should think why one would say it? Perhaps you misread or there is more to it.
You’re flat out lying at this point.
> In fact, none are.
Original post:
> doesn't mean it is extensible, scalable or otherwise written well
I could go on but there is no sense in arguing with intellectual dishonesty.
> In fact, none are.
Original post:
> doesn't mean it is extensible, scalable or otherwise written well
I could go on but there is no sense in arguing with intellectual dishonesty.
Before I even look into it, I'll tell you this: the headline was enough to grab my attention on its own. I strongly feel this is a badly underserved niche and I've had major issues with Firebase's limitations. You definitely have a winning idea here in this user's opinion.
I'd consider myself fortunate if I never have to deal with Firebase again.
Firebase simply did not behave as documented. Whole features shipped that were just wishful thinking.
It reeked of high-level management applying pressure to ship-now-no-matter-how-broken.
Firebase simply did not behave as documented. Whole features shipped that were just wishful thinking.
It reeked of high-level management applying pressure to ship-now-no-matter-how-broken.
My experience is quite different to this. I’d be interested to know which features behaved differently to their documentation?
I most vividly recall unit testing, storage emulator, auth. For example:
https://github.com/firebase/firebase-js-sdk/issues/5086
> Steps to reproduce:
> Step 1: Read the documentation for setting up cloud storage unit tests at: https://firebase.google.com/docs/rules/unit-tests#storage
> Step 2: Attempt to write unit tests following the examples in the documentation
The reporter describes five problems which will thwart you when you try to write code according to the official documentation.
How did these docs ship? Did nobody ever try the sample code and verify that the features worked as advertised? Did nobody write any tests to validate that the features actually worked? Are there no policies in place (e.g. "new features require tests" or perhaps code review) to prevent such mishaps?
https://github.com/firebase/firebase-js-sdk/issues/5086
> Steps to reproduce:
> Step 1: Read the documentation for setting up cloud storage unit tests at: https://firebase.google.com/docs/rules/unit-tests#storage
> Step 2: Attempt to write unit tests following the examples in the documentation
The reporter describes five problems which will thwart you when you try to write code according to the official documentation.
How did these docs ship? Did nobody ever try the sample code and verify that the features worked as advertised? Did nobody write any tests to validate that the features actually worked? Are there no policies in place (e.g. "new features require tests" or perhaps code review) to prevent such mishaps?
Firebase is great for Hackathons =D
That's great feedback and more validation to the problem we're solving. Glad to hear that. Would love to hear if there are any specific pain points with Firebase that you'd like to be addressed. Being an open source project thats the biggest advantage we have over Firebase. The community!
For me the most painful part was latency, and especially cloud function latency. I wanted to create an entire API through cloud functions and rapidly discovered that they have major issues with "cold startup". A lot of people have had this issue~ https://stackoverflow.com/questions/42726870/firebase-cloud-...
I found a lame workaround by setting up a cronjob to ping the API regularly, but there was still bad latency for cloud functions that were interacting with the database. It was 1-2s of latency, which was a total nonstarter for my realtime collaboration code. I had to go write a socket.io server by hand instead.
Also, there are extremely limited tools for observability/monitoring/logging of cloud functions, as well as for plain API interactions with firestore. I could see that trying to track down issues through that toolset was going to be nightmarish. In my opinion, for any app that scales beyond a small personal project, it is an absolute must to have good tools for inspecting logs with error rate graphs and stacktraces and so on.
I found a lame workaround by setting up a cronjob to ping the API regularly, but there was still bad latency for cloud functions that were interacting with the database. It was 1-2s of latency, which was a total nonstarter for my realtime collaboration code. I had to go write a socket.io server by hand instead.
Also, there are extremely limited tools for observability/monitoring/logging of cloud functions, as well as for plain API interactions with firestore. I could see that trying to track down issues through that toolset was going to be nightmarish. In my opinion, for any app that scales beyond a small personal project, it is an absolute must to have good tools for inspecting logs with error rate graphs and stacktraces and so on.
Thanks a lot for taking the time to type this. Really appreciate this.
If I understood everything correctly, may I ask why you were using a cloud function to build the a realtime application rather than relying on their realtime database directly ?
If I understood everything correctly, may I ask why you were using a cloud function to build the a realtime application rather than relying on their realtime database directly ?
It was because I needed to run validation over the inputs sent to the server, and then update other data which the user themself did not have authorization to access.
You can validate the data with Firebase rules. The other data can be updated with Firebase functions. They listen for state changes on the relevant data and then update the data that the user does not have access to.
I'm sure it's technically possible, but things were starting to feel hackier and hackier and already the latency was a no-go, so the value proposition was becoming less convincing. I'm still using it for user auth though, that seems to work well so far.
Appwrite is really meant to live happily beside your stack. Honestly, disable and rip out the containers you don't need, they're all stateless, and loosely coupled. You can disabled them in console.
Use what you find useful. I often use Appwrite just for Auth + Avatar/profile management. Something I do for every app... something that I find painful to do for every app :P
Use what you find useful. I often use Appwrite just for Auth + Avatar/profile management. Something I do for every app... something that I find painful to do for every app :P
Thanks a lot for clarifying . Makes sense :)
[deleted]
I was about to ask how you manage to support so many different language bindings, then I noticed that you’ve built an ‘SDK generator’ [1]. Very cool! I’ve not come across this concept before - how does it work?
[1] https://github.com/appwrite/sdk-generator
[1] https://github.com/appwrite/sdk-generator
We use twig templating syntax as an agnostic language that allow contributors from different coding backgrounds to help us build the SDK templates. Then we use our API spec file to auto-generate the source code and push the relevant code to the SDK repos and package manager, it works really well and help us maintain a big amount of SDKs with little overhead after the core templates are done. We actually plan to have a talk about, it's really cool!
Awesome job. I guess the API spec file is key to this! I see from the repo that you use swagger.
Best of luck with the project - as others have noted, this is a space ripe for improvement given the success of the closed source incumbent that is Firebase. I still mourn the loss of Parse!
Best of luck with the project - as others have noted, this is a space ripe for improvement given the success of the closed source incumbent that is Firebase. I still mourn the loss of Parse!
I'm pretty wary of this sort of thing, but I've got to say, what you've produced looks awesome, and I will be thinking of a product to try it on!
I know it sounds silly to say this, but the polish and content of your website really helps. Very, very impressed.
I know it sounds silly to say this, but the polish and content of your website really helps. Very, very impressed.
I had the same sentiment, I was thinking is this the localstack of the Firebase world? have you doomed yourself to replicate their problems? but no its a firebase _alternative_ not a replacement, well played. Lots of good explainer content too.
This is some really heart warming feedback! Thank you from the entire Appwrite team
It's a pleasure! Let me reward you with another feature suggestion :)
In my world, one thing that's always a little troubling is a document DB, particularly around doing analytics. Having an accompanying way to do that would be extremely handy. E.g. eventually consistent streaming of documents to postgres, which I could then use to drive some screens.
In my world, one thing that's always a little troubling is a document DB, particularly around doing analytics. Having an accompanying way to do that would be extremely handy. E.g. eventually consistent streaming of documents to postgres, which I could then use to drive some screens.
Thank you
I've been looking into supabase for a long time, trying to decide if i want to adopt it, but after many months of keeping an eye on them, appwrite comes along and i'm instantly sold. For me it means two things: supabase never really convinced me, and second, i was waiting for someone else to take the lead. Supabase is just fancy ui and marketing, while these guys seem the real deal. For home projects i'll just easily install appwrite(while i cannot do that with supabase after all these months of waiting), and for commercial apps i'm willing to pay appwrite to take care of infra and everything. Way to go guys, hats down and respects
I actually bookmarked the repo a few months ago but never got around to using it. Seems like a great product.
As someone who is building a small project for personal use (and has been frustrated with Firebase in the past) how does this compare? Will it be easy to switch an existing project over? Also, what is the plan for pricing on the hosted option?
As someone who is building a small project for personal use (and has been frustrated with Firebase in the past) how does this compare? Will it be easy to switch an existing project over? Also, what is the plan for pricing on the hosted option?
Seems pretty cool! One question, how do you finance the development?
Appwrite started as an open-source project 2 years ago. Last year we started a company and got a $10m seed from top VCs like Bessemer and Flybridge (ex-Firebase investors) to help us grow the community and speed product development.
Just out of curiosity. Why would a VC invest $10m in an Open Source project? I'd like to understand more about this model. You must have some path to a commercial offering I assume?
They have a cloud offering. Personally I'd rather pay for someone else to manage devops than myself.
I'd assume the Redhat model, but who knows.
Yes. Luckily a lot of amazing open-source companies like RedHat, Gitlab, Sentry, MongoDB and Elastic have already demonstrated multiple ways to build successful open-source business models, this is one area we don't need to reinvent the wheel at.
I can't tell if this is sarcastic or not since many of those companies are either open core, or they moved from open source licenses to proprietary source-available licenses.
Congratulations. That's incredible news.
Our amazing open source community keeps us going
Thank you!
What would be great is an agnostic layer that's just the real-time sync that you can plug your existing stack into. Sending json up and down your websockets to sync things and handling offline etc is tedious and slow.
That is exactly our plan! We like to decouple the different Appwrite components. This allows us to offer max flexibility for developers and let everyone use the server the way they like to. Using the REST API, Realtime or GraphQL with or without offline support - your call.
Sounds too good to be true. Are you saying that I, as a web developer, will be able to not touch devops stuff?
Does it work out of the box with everything included?
Because I really like only writing business logic.
Does it work out of the box with everything included?
Because I really like only writing business logic.
You should look into backend-as-a-service products because this is exactly what they do. Firebase is the classic but proprietary example with Appwrite and Supabase are up and coming open source examples.
Our aim is to try and reduce the friction during development as much as possible, but still leave developers max flexibility to build any products they like without limiting their creativity.
Maybe I'm looking in the right place but I couldn't find docs on scaling. How does Appwrite scale up WS connection pool, workers, cloud functions.
All of the Appwrite containers were designed to be stateless and easy to scale with replication, scaling the under the hood database is as easy as connecting it to a managed cloud solution.
I was wondering about the same thing. Is there instructions on how to scale the containers. Is it just matter of updating docker compose file or are there other configuration files I need to touch.
We don't have instructors for this, per-se. There is an older article about using docker swarm -> https://dev.to/appwrite/30daysofappwrite-docker-swarm-integr...
We're trying to update these old posts as we speak... hopefully we'll get to this soon :') Keep an eye out!
We're trying to update these old posts as we speak... hopefully we'll get to this soon :') Keep an eye out!
This is the first "Firebase clone" I've seen that attempts to implement the Firestore database model. Neat!
Is there a compatibility layer or migration guide for people looking to switch?
Hi, at this point the process is not so straight forward and you'll need to use the Admin SDK from Firebase and the Server SDK from Appwrite to manually copy your data over. We do plan on making this easier in the future.
Thank you! Actually the Firebase has done an amazing job on making the DB scalable, and we got to appreciate their work even more when working on our implementation.
Do you have any plans to support relational database functionality like joins?
Yes we do plan to add support got joins, transactions, atomic operations and geo queries soon
Love seeing open source projects evolve like this. Great work guys!
Thank you so much! The community support has been such a major part of our journey!
Any comparison with Supabase, which is also a backend-as-a-service? [0]
[0] https://supabase.com/
[0] https://supabase.com/
Couple of points here: https://medium.com/geekculture/appwrite-frequently-asked-que...
Both products are great, at Appwrite we created the majority of the product from scratch in aim to have tailored made dev-experience which was a big reason for starting the project from the first place.
Supabase uses Postgres instead of a Firestore like database, so it's not really a clone of Firebase.
Postgres supports jsonb which I've used with Supabase to act as a Firebase analog. I just pushed all data into a JSON blob rather than setting up tables, it worked well, pretty much the same as how I used Firebase.
I'm trying to be as objective as I can, but building the entire ecosystem around a single product like Postgres ( even though tried and tested ) comes with its own downsides...
Great work, I just cant see authorization feature. How does Appwrite handles this key concept right now ?
API keys are used by Server SDKs ( or Admin SDKs in the Firebase world ) to authenticate and perform more crucial server side tasks using the API
https://appwrite.io/docs/keys
Building on from firebase’ feature set, are there any plans to incorporate analytics/crashlytics?
Yes, definitely. But its something lower on the priority list ( from community feedback )
Strictly speaking, if I spin up a droplet on DO and install Appwrite on it, it won't be a BAAS anymore, correct?
Sorry but "self-host your own BAAS" is an oxymoron.
IMO, developers who chose Firebase do not want to manage servers.
Sorry but "self-host your own BAAS" is an oxymoron.
IMO, developers who chose Firebase do not want to manage servers.
You can launch a fully managed instance of Appwrite in 3 minutes on Elestio for $10/mo: https://elest.io/open-source/appwrite
We take care of deployment, security, backups, monitoring, alerts, OS and Software updates
We also give back part of the benefits to the open source project (we launched 2 weeks ago so we are still contacting all the projects owners currently ... Eldad you should get my email soon)
We take care of deployment, security, backups, monitoring, alerts, OS and Software updates
We also give back part of the benefits to the open source project (we launched 2 weeks ago so we are still contacting all the projects owners currently ... Eldad you should get my email soon)
100% right, we are working on a cloud edition that we hope to release soon. That said, their are a lot of use cases for self-hosting, and its also very cool to be able to deploy something as massive as this on your own localhost with a single command.
Awesome, I look forward to try your managed service.
I see it as risk management: perhaps start out with the hosted option. If they pull a Parse (shut down development and company), you still have the option of moving it to self hosting.
I have a firebase project I need to move asap.
How quickly, realistically, could I move to your solution?
Do the API’s map directly? Sorta? Or is this inspired by? Is the migration a significant dev effort?
Ping me docs and I’d consider it immediately.
How quickly, realistically, could I move to your solution?
Do the API’s map directly? Sorta? Or is this inspired by? Is the migration a significant dev effort?
Ping me docs and I’d consider it immediately.
Although we still haven't created a fully automated migration, this doesn't have to be a huge take, but it will be mainly be up to the way your app is integrated with Firebase and how coupled the two are.
For migrating you'll have to do two things, migrate your data and replace your Firebase API calls. Appwrite provides both REST and Realtime (WebSocket) APIs that should be replaced with any Firebase calls in your app. You can migrate your Firebase data to Appwrite by using the Appwrite Server SDK in one of your favorite languages (https://appwrite.io/docs/sdks).
For migrating you'll have to do two things, migrate your data and replace your Firebase API calls. Appwrite provides both REST and Realtime (WebSocket) APIs that should be replaced with any Firebase calls in your app. You can migrate your Firebase data to Appwrite by using the Appwrite Server SDK in one of your favorite languages (https://appwrite.io/docs/sdks).
Why people want to move from firebase? Any reasons. It's a good db
Google dependency. Like to self-host. Can scale cheaper(?).
> Google dependency
Indeed. To me it seems crazy to use an advertisement agency to host so much of your app. And as a user from same perspective, if I find Firebase is used in your app, then it is an immediate no-go area. No matter how good it looks otherwise in terms of features and UX.
Indeed. To me it seems crazy to use an advertisement agency to host so much of your app. And as a user from same perspective, if I find Firebase is used in your app, then it is an immediate no-go area. No matter how good it looks otherwise in terms of features and UX.
Do you guys have Firebase shim/adapter to easy transition?
Also, please take a look at CapRover, combining that with Appwrite might be a powerful combo (there's overlap).
Also, please take a look at CapRover, combining that with Appwrite might be a powerful combo (there's overlap).
Hey, we don't yet have a Firebase adapter, however it should be very easy to transfer using Firebase admin scripts (using firebase-tools) and Appwrite's Server Side SDK of your choice. If you need help you can always come to our discord https://appwrite.io/discord
Also, yes CapRover looks interesting, thank you for mentioning, we will look into how we can integrate/collaborate.
Also, yes CapRover looks interesting, thank you for mentioning, we will look into how we can integrate/collaborate.
What's the pricing model for cloud.
We’ll share the pricing for Appwrite Cloud shortly, which will be transparent and simple. The open source version of Appwrite will be free, forever.
What is Appwrite ? In simplest terms, Appwrite is an open source Backend As A Service (aka BaaS). Appwrite is an all in one solution with all the essentials you need like Authentication, User Management, Realtime Databases, Webhooks, Storage, Cloud Functions, SDKs for your favourite language and it’s light weight. Appwrite even runs on a Raspberry Pi. Most importantly, Appwrite is self-hosted which means you own your data and prevent any vendor lock-ins.
Talking about Appwrite’s features - Realtime Databases and events ( Recent benchmarks have showed a single server handling 1M+ concurrent connections )
- SDKs for iOS, Android, Flutter, Web ( React, Angular, Vue, Svelte etc.) Python, PHP, Node, Deno, Kotlin and more
- Bring your own Database - Use your choice of SQL or MySQL databases ( MariaDB, MySQL, MongoDB and more )
- Database permissions for finer tuned access control
- Storage API with built in encryption, compression and antivirus
- Bring your own Storage - Use your choice of the local filesystem, DigitalOcean Spaces, S3 or an any other storage provider of your choice
- Cloud functions with support for over 20 runtimes
- Webhooks to connect with 3rd party APIs and services
- User Management and Authentication
- Multiple authentication methods - email, 25+ OAuth providers, JWT, API Keys
- Completely stateless and extensible architecture allowing easy integration with your existing backend
- A Dashboard, CLI and VSCode extensions to manage your server and many more...