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.
Please refrain from asking people to upvote your posts. I really love appwrite, and I’m sure it can make it to the frontage without asking users for upvotes :)
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!"
All these platforms expose a kind of data repository with multiple users that is designed to be used as an app backend. The permissions in a "headless CMS" will by default be designed under the assumption that people will be writing articles that will all be shared between/accessible to all users whereas Firebase/Supabase/Appwrite will assume that each user has their own private data, but a lot of the details are in how you configure them for your use case and perhaps they aren't really that different when you think about it.
Many of these competitors are missing: offline persistence, optimistic updates, local cache, push updates, command pipelining and casual consistency. Which is cool but to me this is missing the main point of Firebase which was about making modern, reactive apps simpler to develop.
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
Have you checked out thin.dev? We provide optimistc updates, local cache and realtime is the default for everything (offline persistence has not been the focus as we're not targeting mobile for now)
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.
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.
Looks nice! Just a quick note—when I hear "open source Firebase alternative" I immediately think Supabase. It might be good to call out the factors that differentiate Appwrite from other projects.
I answered above, so look there for a detail response.
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 :)
Both are great products, here's my biased (obviously) way of choosing between them:
- 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:
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!
Really impressed with how easy appwrite was to start up from Docker! (Try doing that from Directus -- they give no help at all for any self hosting.) Can't wait for the GraphQL endpoint to get going! Appwrite isn't as evolved as Directus but I love the open source approach it has, instead of the push towards their cloud offering.
> Appwrite is simple to self-host. Like really simple. Like a single line of Docker command simple
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`.
Readit News
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.
https://news.ycombinator.com/newsguidelines.html
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)
https://javascriptdb.com
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`.