Show HN: Appwrite – Open-Source and Self Hosted Firebase Alternative
github.com
github.com
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...
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.
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 :)
> 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.
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 :')
Just one question: is there also Postgres support?
(Disclosure: supabase ceo)
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.
> 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
also the project is worth checking out ;)
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
When Supabase Functions are live and Hooks are stable then it will definitely work for the app I'm working on.
(Disclosure CEO of Nhost)
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.
I'll spend some time today improving our self-hosting docs (https://supabase.com/docs/guides/hosting/overview)
We're also happy paying customers! We need on prem to offer our own customers an on-prem solution.
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.
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
:)
- 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.
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.
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...
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.
"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.
> 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.
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.
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 ?
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
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.
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?
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 know it sounds silly to say this, but the polish and content of your website really helps. Very, very impressed.
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.
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?
Does it work out of the box with everything included?
Because I really like only writing business logic.
We're trying to update these old posts as we speak... hopefully we'll get to this soon :') Keep an eye out!
Sorry but "self-host your own BAAS" is an oxymoron.
IMO, developers who chose Firebase do not want to manage servers.
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)
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.
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.
Also, please take a look at CapRover, combining that with Appwrite might be a powerful combo (there's overlap).
Also, yes CapRover looks interesting, thank you for mentioning, we will look into how we can integrate/collaborate.