I'm currently considering Firebase for prototyping, and would love to know your thoughts on it if you:
- currently use it in a production setting
- considered it but ultimately went with a different solution
- had used it in the past but later migrated away from it
Thank you!
I think Firebase is a great product, however, the more I build web apps, the more I think Rails and other back-end frameworks are the way to go for most projects. Faster loading time, fewer updates to stay up to date with the cutting edge, fewer difficult bugs, faster time to market.
Read here for a more convincing rundown of the hidden costs of an SPA:
I guess IH is also a SPA. I remember Allen mentioning it in a comment.
I agree 100% and my first years as a professional dev were basically spent dealing with jQuery, then Backbone, and then React.
I think a lot of indies choose complex architectures and complex dev ops setups because they're thinking in terms of what makes sense for large companies who employ dozens or hundreds of people.
I'm using Firebase in my app. Overall I'm satisfied except one issue with Functions: cold start is ridiculously slow, and people often experience timeouts (I'm only using functions for purchase verification, so naturally those don't run very frequently and almost every start is a cold start). That's something to keep in mind if you're gonna rely a lot on HTTP functions.
Oh good point. How big of a delay have you been seeing with the cold start? And how soon does it fall back to cold start after last invocation?
I'm wondering if you could run a cron job somewhere that just periodically invokes your functions to keep them alive.
Oof, I get timeouts, so I guess sometimes it passes above 10 seconds or something! There are many articles and StackOverflow questions for the search "firebase functions slow", some offering some tips on how to reduce that time (e.g. this one by Colt McAnlis). I don't think there's specific period when it falls back (some say, 30 minutes or something), but yeah, running a timed trigger is an approach some people resort to. Also, seems like Firestore is often regarded as the culprit: people complain that accessing
admin.firestore()
takes most of that cold boot time.Overall — Firebase is not really reliable if you want to host all your project as Node.js (Functions) app; you may want to use App Engine for that. But if you use static hosting, the database directly, and functions only for special cases, you’ll probably be fine.
And yes, people totally use cron jobs or even some 3rd party services that would send a HTTP request to your functions endpoint.
Currently use in production. I posted here: https://www.indiehackers.com/mnmlst/post/a38b74df8b
Thanks Paul! Reading it now. I like that it delves into code snippets/examples and does a detailed comparison between competing solutions.
It is great, but it can get expensive really quickly once you have some users.
So for prototyping purpose is great.
I used firebase way back in the day before they were acquired. I did briefly consider it for a project last year but then I realized that its main selling point of soft real-time subscriptions is something that is directly in the sweet spot of the Erlang VM, which my language of choice, Elixir, uses. The web framework I use, Phoenix, already includes channels and has presence features built in, too.
Ultimately, I found no need to add another external dependency that would just increase price, decrease performance and put me at the whims of Google changing whatever it wants to about the api, the pricing or pretty much anything at any time.
One other datapoint: IH uses Firebase, and of the sites I use regularly, it's by far the slowest and most prone to caching and async bugs.
I have a live mobile app https://scenario-game.com using Firestore for everything with another one shortly launching. I love it!
Only downfall is you can't request a list of documents by a specific list of ids. Theres an issue raised for it but it doesn't look like it'll be solved soon so if that's a blocker for you then you might need to think about spiking out your use cases for it.
This game is great haha. I play hard questions with my friends all the time with a slight variation: how much money would it take us to do something (something gross, or embarrassing). Anyways. That is indeed something I'll have to watch out for. Do I request all documents and filter on client side then? Do you have any strategies for dealing with this if your list of documents gets prohibitively large?
Haha thanks for the kind words.
Sorry saw a type in my comment so edited it (you can't request a list of documents by specific ids). You can request one single document by id though. So I effectively request a Promise.all for my page size. Yes it's horrible, I make 10 individual requests for a paginated response of 10 documents.
It was nearly a deal breaker for me but the functionality I require it for is not a primary feature (i.e. view the list of posts that I have upvoted) and Firestore charges per document read and not per request (the deprecated Firebase DB charges per request / data payload size though as far as I remember).
Hope that helps. I really do love it despite all that
Well, I guess it all depends on your requirements.
Have been using it for authentication, real-time database and monitoring all related with mobile apps, and it works like a charm.
I knew since the beginning that I would never reach their free tier, but it's something you should consider while scaling.
I use Firebase in production for https://blindvalet.com and love it.
I use it for authentication as well as the real-time database. My application is for managing live poker tournaments so the real-time data synchronization is huge for me. Most tournaments have one or more computers connected to big screens to display the clock, and the tournament staff will use tablets or phones to control the clock, manage seating, eliminate players, etc. The data sync works great.
I also use Storage and Functions and have used the Hosting in the past. I'm a big Firebase fan. If you want to chat more, don't hesitate to message me.
Your application is very well made! The UI/UX is very well thought out. I like the transitions and ease of use.
Questions:
Thanks for the kind words!
I've used it to build habit-tracker.space I was quite happy about it overall. I would definitely use it again.