8 ms·
Show HN: Open-source Firebase Alternative? It's here
- christyjacob4 4y agoHi there, Appwrite maintainer here 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 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.
- turnsout 4y agoLooks 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.
- vincentge 4y agoI 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 :)
- melony 4y agoDo you plan to support relational models? I cannot use Appwrite because our application absolutely requires a relational database.
- avinassh 4y agoWhat all the features real-time database provides?
- nicksiscoe 4y agoCongrats! What are you focusing on to differentiate yourself from Supabase?
- vincentge 4y agoBoth 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: 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!
- nicoburns 4y ago> 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`.
- kopochameleon 4y agoPrevious Show HN here: https://news.ycombinator.com/item?id=30769044 https://news.ycombinator.com/item?id=30769044 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!"
- christyjacob4 4y agoCompletely agree with you. I have however shared all the new features in a comment here https://news.ycombinator.com/item?id=31421863 https://news.ycombinator.com/item?id=31421863
- mccorrinall 4y agoPlease 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 :)
- _query 4y agoIf you're looking for something like Appwrite or Supabase but with a more end-to-end typesafety approach + optimistic updates, check out Thin Backend https://thin.dev/ https://thin.dev/ (https://github.com/digitallyinduced/thin-backend https://github.com/digitallyinduced/thin-backend) It takes a bit more of a higher level approach to database operations than appwrite, supabase or firebase, which allows us to do things like optimistic updates that are hard to do in other tools. To see some code examples, here's a small example project done with thin-backend: https://github.com/digitallyinduced/thin-backend-todo-app/blob/main/app.tsx https://github.com/digitallyinduced/thin-backend-todo-app/bl... It's running on Vercel here: https://thin-backend-todo-app.vercel.app/ https://thin-backend-todo-app.vercel.app/
- lagrange77 4y agoGood point. Optimistic updates have always been a pain point for backends as services, although it's quite essential for many apps UX.
- _query 4y agoYeah, initially we didn't have this. During beta our main servers were in europe, and while I was in SF I saw what a difference this made to the overall UX of our kind of realtime apps. Everything took like 200ms more :) With the optimistic updates it's now fast everywhere on the world.
- poindi1 4y agoIs it completely open source seems like there is a dependency on ihp-backend? Can someone pls clarify
- _query 4y agoihp-backend was the "old" name before it was called thin backend. You can find the source code here https://github.com/digitallyinduced/thin-backend https://github.com/digitallyinduced/thin-backend and here https://github.com/digitallyinduced/ihp/tree/master/lib/IHP/DataSync https://github.com/digitallyinduced/ihp/tree/master/lib/IHP/... (Thin is based on IHP)
- ushakov 4y agoi think true Firebase alternative should be compatible with Firebase clients, no?
- npteljes 4y agoThat would be a "drop-in replacement", which is indeed a type of alternative. But to be an alternative, it's enough to just provide similar functionality.
- christyjacob4 4y agoExactly..
- lagrange77 4y agoNo.
- nameless912 4y agoI think most people here would tend to disagree for two reasons: 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.
- christyjacob4 4y agoNot necessarily. You can be an alternative to an existing solution in many different ways.
- karimmaassen 4y agoHonest question: does any of you use Firebase and why (not)?
- vincentge 4y agoI 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 ;)
- p2hari 4y agoI do. I develop lot of MVPs for clients and personal projects. 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).
- christyjacob4 4y agoI had a couple of side projects running on Firebase until I discovered the open source alternatives. I can self-host on a $10 droplet which makes the costs very predictable
- arcturus17 4y agoI’ve found their lack of a relational database a huge problem for any project that scales beyond trivial complexity.
- latchkey 4y agoIt is easy enough to connect from firebase functions to a cloudsql instance and the pricing is pretty good for the lowest tier (which is also easily scaled up). That said, might as well just use gcp cloud functions instead.
- simplehuman 4y agoSo, is this firebase API compatible?
- vincentge 4y agoNo, 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. Think of it as an alternative, not a clone :)
- christyjacob4 4y agoNot really. Appwrite focuses more on simplicity and a seamless developer experience and the Firebase API is not one of them
- ramon 4y agoAny plans for Kubernetes compatibility?
- vincentge 4y agoWe're looking into it. We optimistically want to do it. We haven't committed to doing it, because we're prioritizing some other stuff right now :P
- ramon 4y agoIf doing a docker swarm which ports are required? Not clear on installation documentation.
- eldad_fux 4y agoYou just need to open port 80 and 443 for HTTP communication.
- christyjacob4 4y agoyes it would be 80 and 443 for http traffic. And the ports that swarm requires for internal communications https://docs.docker.com/engine/swarm/swarm-tutorial/#open-protocols-and-ports-between-the-hosts https://docs.docker.com/engine/swarm/swarm-tutorial/#open-pr...
- christyjacob4 4y agoYes, official support is in the pipeline. There have been some community helm charts in the past ( which might need to be updated )
- eikaramba 4y agoIMHO these are the 3 open source backend/platform -as-a-service solutions you need to have a eye one: 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)
- christyjacob4 4y agoIsn't Directus a CMS? Doesn't seem to be a backend/platform -as-a-service
- codegeek 4y agoI am a bit confused. How is Strapi (a headless CMS) comparable to Firebase/Supabase/Appwrite ? Aren't they apples and oranges ?
- aaaaaaaaata 4y agoDepends what kind of app you're building, really.
- christyjacob4 4y agoyeap exactly... CMS's are meant for a different audience altogether
- resoluteteeth 4y agoAll 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.
- pvsukale3 4y agoShameless self plug Open source/ proprietary projects similar to Appwrite. https://ossdatabase.com/projects/appwrite https://ossdatabase.com/projects/appwrite
- skrtskrt 4y agoThere are a lot of SEO-spam sites that look a lot like this one that are designed to top the results for searches like "technology 1 vs technology 2". They are all completely useless. 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/replication/ https://docs.redis.com/latest/rs/concepts/high-availability/...
- retrofuturism 4y agoThe current title is pure SEO bait
- tlarkworthy 4y agoMany 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
- _query 4y agoHave 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)
- burggraf 4y agoSupabase developer here. We concentrate on the following core features: 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)
- tessamero 4y agothis is cool
- stephane-klein 4y agohttps://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/
- deleted 4y ago[deleted]
- dang 4y agoYou guys have been breaking these HN guidelines: 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 https://news.ycombinator.com/newsguidelines.html