Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Open-source Firebase Alternative? It's here

github.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Show HN: Open-source Firebase Alternative? It's here

#51

Post by christyjacob4 »

codegeek wrote: post #33
eikaramba wrote: post #26

IMHO 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 wa…

I am a bit confused. How is Strapi (a headless CMS) comparable to Firebase/Supabase/Appwrite ? Aren't they apples and oranges ?

yeap exactly... CMS's are meant for a different audience altogether

Re: Show HN: Open-source Firebase Alternative? It's here

#52

Post by [deleted] »

_query wrote: post #10

If 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://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…

[deleted]

Re: Show HN: Open-source Firebase Alternative? It's here

#54

Post by jpcapdevila »

eikaramba wrote: post #26

IMHO 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 wa…

I'm developing an alternative using SQLite, focused on JavaScript developers productivity.

https://javascriptdb.com

Re: Show HN: Open-source Firebase Alternative? It's here

#57

Post by dhritzkiv »

nicoburns wrote: post #17
vincentge wrote: post #5

Earlier quoted context omitted.

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 the…

> 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.

Re: Show HN: Open-source Firebase Alternative? It's here

#58

Post by skrtskrt »

pvsukale3 wrote: post #29

Shameless self plug Open source/ proprietary projects similar to Appwrite. https://ossdatabase.com/projects/appwrite

There 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/...

Re: Show HN: Open-source Firebase Alternative? It's here

#59

Post by dang »

You 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

Re: Show HN: Open-source Firebase Alternative? It's here

#60

Post by resoluteteeth »

codegeek wrote: post #33
eikaramba wrote: post #26

IMHO 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 wa…

I am a bit confused. How is Strapi (a headless CMS) comparable to Firebase/Supabase/Appwrite ? Aren't they apples and oranges ?

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.
Post reply on HN