Over the past few months we’ve been trying hard to make Appwrite as simple to setup and use as possible. Your candid feedback has been crucial in shaping the project and it would be great if you can share some features you’d like to see in the project going forward.
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
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
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 :)
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.
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.
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...
> 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.
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.
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.
> 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?
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.
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 ?
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
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?
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!
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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...
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
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.
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.
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).
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.
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.
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...