Show HN: Open-source Firebase Alternative? It's here
github.com
github.com
Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.
That's not cool and we penalize and eventually ban the accounts, sites, and projects that do it.
From the title "Show HN: Open-source Firebase Alternative? It's here (github.com/appwrite)" was expecting the entirety of Appwrite to be a new project shown here for the first time. Could the title be changed to reflect what's new? Perhaps the title of the GitHub Issue being linked: "Announcing Appwrite 0.14 with 11 Cloud Function Runtimes!"
1) Directus (in my view the best offering of features)
2) Supabase (if you want more performance. the admin ui however can only be used for internal access)
3) Appwrite (works good and has its own advantages. however in my case i would rather go with 1&2)
-Strapi is out since v4 (too many really big showstopers. i was a fanboy since v3 but directus just brings more to the table and is way mature)
-feathers.js (more lightweight, but unfortunately lost its momentum. better alternatives are nowadays available)
Appwrite and supabase make CRUD apps easier to write. It's different. I guess Firebase expanded to being used for everything but it was all about realtime apps originally (ex-Firebase developer here)
I like these apps but I find the positioning weird given their feature set
Database (PostgreSQL with Postgrest for REST)
Auth (GoTrue)
Storage (S3, or local files if self-hosting)
Edge Functions (Deno, deployed across dozens of regions)
Realtime (a lot of new stuff coming up in this space now at Supabase)
Appwrite v0.14 was just released with 4 new cloud function runtimes, 3 new storage adaptors, 3 new OAuth providers, a precision event model, and many quality of life improvements. We’d love to get feedback on improvements and features as we gear towards v1.0 of Appwrite.
TL;DR -> https://github.com/appwrite/appwrite
What is an Appwrite? Appwrite is an open source backend-as-a-service that helps you build secure apps, faster. Appwrite handles authentication, realtime databases, file storage, cloud functions, and more with SDKs for web, mobile, and server side languages.
Here’s everything new in Appwrite v0.14:
Updated Event Model: Trigger webhooks, cloud functions, & realtime events with a more precise event model
New Cloud Function Runtimes: C++, .Net, Kotlin, and Java
New Storage Adaptors: Linode, Backblaze, and Wasabi
New OAuth Providers: Zoom, Okta, Auth0
And a lot more improvements: Async/Await support in Swift runtime, wildcard support for hostnames, toggle user verification from the Appwrite console, and many bugs fixed.
Community feedback and contributions have been a major source of guidance for our project and we’re always looking to improve as we move forward. Tell us your thoughts by opening issues on GitHub, engaging with us here on Reddit, or joining our Discord community.
If you like your experience to be decided for you, use Supabase, especially if you love interacting with a Postgres instance and Deno for your cloud functions.
We try to keep our stack agnostic, hence the 11 function executor, and ever growing list of SDKs. We also allow you to choose your storage adaptor for stuff like Linode, S3, DigitalOcean spaces, Wasabi, and more. We'll eventually give you the option to choose between many DB options, too.
We don't wanna replace your stack, we wanna play nicely with it. You can straight up disable all our services but one, and we're happy to let you enjoy your experience all the same :)
- Appwrite is really focused on a simplistic experience. If you check out our SDK documentation, we try to keep everything dead simple.
- Supabase allows more verbose control over their PostgreSQL instance, i.e. you're actually writing SQL and interacting through a SQL console. This might be your cup of tea. They also use Deno for their cloud function equivalent, which is cool if you love Deno.
I would say Supabase is more opinionated, we try to give more options. Neither is necessarily better, there are pros and cons that you can decide on.
Other than that, Appwrite does some things that I find special.
Appwrite is simple to self-host. Like really simple. Like a single line of Docker command simple:
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
This gives you the full Appwrite experience for local/dev environments and you only need a few more environment variables to be production-ready.
We try to make Appwrite agnostic to your tech stack. You can use or disable any of the services when self-hosting, saving resources on your precious servers. You can integrate with frontend, backend, or both, or just use a single service, like our function runtimes.
We support a ton of SDKs, and we're always adding more. Our vibrant community makes this possible.
We have a lot of languages supported for Appwrite Functions, not just Deno ;) We have lots of storage adaptors you can choose from, or local storage if you want to keep all your data. We will support MANY databases (you can contribute your own, too).
I hope that helps, it really is down to personal preference, developing on the platforms feels very different. Try both!
Is is possible to use Appwrite without Docker? Docker is super-slow on Macs so I tend to run everything natively. With traditional tools (e.g. Postgres, Redis, etc) this is super-easy. I can just `brew install`.
However, we'd be more than delighted for contributions from the community
Open source/ proprietary projects similar to Appwrite.
IMO If you really want to provide value, you have to dig into the actual details of these technologies, not just offer a top-level blurb and category label.
Just look at any Show HN post comments, engineers crave the details when it comes to comparing and choosing technologies.
Example: One thing I have always desired is somewhere to see all the major databases/event stream/persistence technologies and see what kinds of different consistency guarantees, replication, backup, recovery, etc. they each offer.
This goes a bit deep (most datastores have a bunch of different ways to configure and tune them for different consistency levels [1]) and is obviously more effort than the low-effort "this vs that" sites, but I don't see much value in the existing "this vs that" offerings.
[1] https://docs.redis.com/latest/rs/concepts/high-availability/...
1. It is the fastest way to build. Auth, notifications, DB, cloud functions, analytics. You have everything you need.
2. Generous pricing. You will be able to get most of the things done with minimal costs on infra.
3. Dev Friendly: Anybody who comes with firebase alternatives, I always look at the toolset. If you look at Firebase, the CLI is amazing.
On top of this, I simply love their emulators. You can test everything before hitting production. All in all, I simply love firebase. If they are able to get the cloud functions with go runtime it will be so nice. (Right now the option is to use Google cloud functions).
But what I really mean is that it would be cool to have Firebase db access SDKs and realtime capabilities, with a relational, non-proprietary database. If you plug in your CloudSQL or another managed database you don't get that, and have to write everything on your own.
Supabase seems to be going in this direction, and while I haven't tried them yet, I certainly see how it's an attractive proposition.
That said, if I attend today and ignore sponsorships, I'd actually get DigitalOcean market place deployment of Appwrite. I honestly think it's quicker to get started with, and I like owning my data ;)
Think of it as an alternative, not a clone :)
1) Firebase's feature set is vast, which ultimately means that you're going to pull in a much bigger SDK than what an "open source Firebase" can reasonably provide. Half or more of the SDK code you're pulling into your project will do nothing. It's better that competitors are like firebase in spirit but ship their own SDKs to optimize for their use cases.
2) Firebase is still owned by google, which automatically paints a target on its back. We don't know what the long term internal roadmap of Firebase is, regardless of what the GCP bosses might say or how much money it seems to make on paper. Google has sown itself quite willing to kill any project at any time without a lot of clear reasoning as to why, and no one wants to build against an SDK/standard that could vanish tomorrow.
To see some code examples, here's a small example project done with thin-backend: https://github.com/digitallyinduced/thin-backend-todo-app/bl... It's running on Vercel here: https://thin-backend-todo-app.vercel.app/