3 ms·
It’s sad to see people invest in things like firebase without understanding my the technology. Right tool for the right job. If you don’t need scale then you d
by endisneigh 4y ago
It’s sad to see people invest in things like firebase without understanding my the technology. Right tool for the right job.
If you don’t need scale then you don’t need firebase. If you need joins, don’t use firebase, etc etc.
If one insist on using a proprietary managed database I’d use Spanner.
- johndfsgdgdfg 4y agoI absolutely agree. Moreover with any Google products you will never know when they will shut it down or hike the prices like they have done countless times.
- endisneigh 4y agoIn my opinion one should refrain from any managed service that can’t be self hosted. Not clear to me why the authors don’t use managed Postgres. Supabase is close enough I suppose. Personally I don’t see what you get with supabase vs an Orm and vanilla managed Postgres.
- moooo99 4y agoThe appeal for firebase is that you can get away without your own backend for quite a while. It's perfectly feasible to consume databases directly from your frontend app without having to deal with a lot of caching or networking concerns, the firebase SDK does that for you. You basically get a complete API layer without having to write a lot of code yourself. It is very similar with stuff like auth handling, which is also tightly integrated into the database offering. This makes development incredibly easy, especially in early stages and if you're starting out as a solo/small scale project. It is even better if you don't have an in depth knowledge about backend development/architecture and just want to build a product. You don't get any of those benefits with a regular managed Postgres offering, at least not that I'm aware of. Supabase comes a lot closer to firebase than a regular managed postgres + ORM offering would but you also get an oepn source project that you could potentially self-host. from what I heard self-hosting Supabase is possible, but a rather complex undertaking. There is some documentation around it, but is definitely a lot more complex than using their hosted offering is.
- danielvaughn 4y agoI’ve been pretty critical of Firebase on HN, perhaps too strongly. My experiences with it have all been the same, it goes like this: Client has a new-ish codebase that was written by relatively inexperienced front end developers. They aren’t confident enough in the backend, and are attracted to Firebase because it lets them write everything from the front end. Then they proceed to create the most convoluted DB model and a spaghetti backend that’s split between the front-end repo and various cloud functions. In practical terms it’s been a nightmare every time, for me personally.
- trefoiled 4y agoIt's amazing just how accurately this describes my exact experience as a FE engineer tasked with creating a newish codebase for a client.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- nicoburns 4y agoIs Firebase even capable of supporting high scale? My experience with it has been that performance is pretty poor when working with large datasets.
- rockwotj 4y agoFirebase is a large suite of products - are you talking about the Realtime Database? The answer is it depends on what "high scale" is. There are parts of the RTDB that didn't scale well when I worked on it (indexes are built in memory on demand so building the initial index is slow), but there are projects that could fix that.
- bootloop 4y agoRealtime Database? No. Firestore however, scales as most GCP services do and is it's in-house built replacement.