I do. If I were to attend a hackathon (which I haven't since 2020), I would use Firebase. It's simple and they sponsor every hackathon I've been to, so I get free credits.
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 ;)
No, we're trying to provide similar functionality, but we're not just cloning it down to the API. We have some of our own philosophy, for better or for worse, about what a good BaaS should look like.
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`.
Side note: I don't know if these were your issues, but Docker for Mac in the last couple of months has drastically improved its memory usage (finally!) as well as its filesystem performance. Obviously nothing will beat running natively, but Docker on the Mac is no longer frustrating.
Yes, we are working on a more native alternative with the likes of a Makefile or some Ansible scripts. However it has not been a major priority since we didn't have many community members ask for it yet.
However, we'd be more than delighted for contributions from the community
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
