Why I’m dumping Firebase for Web (opens in new tab)

I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard our data manually.

Fuck you Firebase, what a load of bull shit. Implying your database can scale infinitely because we can manually shard our data is like calling McDonalds an all you can eat restaurant because I can keep buying more chicken nuggets.

I've yet to meet anyone who has used Firebase on a large scale project and been happy with it. Firebase is a toy at best, IMO.

I honestly feel a bit bad for the development team at Firebase, they actually built something really cool that has a lot of potential. The problem I have is that someone took this cool project and basically lied to the public about its capabilities.

What are you moving to as an alternative?

http://phoenixframework.org/ actually has a built in websocket layer called channels. (its the inspiration for action cable and django channels) . Unlike deepstream, or socketcluster, it has a longpolling fallback as well as multi node clustering.

Its a shame more people don't realize what a gold mine of a piece of technology it is.

(deepstream employee here) despite its flaws, Firebase has some great ideas, e.g. its permission language that strongly inspired us when building https://deepstreamhub.com/. But there are some aspects, many mentioned by the OP that send us down a different route:

- Serverless is a great goal, but only works for low complexity apps. We've designed deepstream explicitly not to take the server away, but as a layer that sits in between backend and frontend and allows servers and clients to connect and exchange data.

- The same is true for auth. DeepstreamHub comes with similar built in auth and usermanagement functions as Firebase, but more importantly comes with a Webhook auth strategy that forwards any login data and associated connection info (IP, Cookies etc) to a HTTPS endpoint of the users choosing. Depending on the returned status code the connection is either granted or denied. In addition the auth server can also return client specific metadata that's either forwarded to the client upon login or used within permission rules to determine access rights

- Querying. This has so far not been a strongpoint of deepstream either, but we'll soon be releasing a blazingly fast realtime graphql implementation to address this. More details here: https://deepstreamhub.com/blog/deepstream-3.0-release/

Has anyone here used gun extensively? https://github.com/amark/gun it seems to position itself as a competitor to firebase, and wouldn't have many of the issues mentioned in the OP

I stopped using firebase DB about a year back. Now I prefer:

1) API backend using Google Cloud Endpoints deployed in GKE. Still using firebase Auth.

2) React SPA served from firebase hosting. Using FirebaseAuthUI

One thing I continue to be astonished about is how difficult it remains to build a real apps (ssl, auth, persistence, packaging, deployment) as a one person team.

Firebase taught me, for a B2B2C kind of app:

1) Relational databases are more flexible: you model your data according to the actual "relations" between them, instead of how you want to query them. This makes it easier to add new views/queries to your application.

2) Joins are necessary

3) In a very short time, you need complex authentication logic and it is very hard to do it without looking at the requested (and related) data directly. Best way to do this is a good-old rdbms + server app

4) Moving more logic from servers to clients forces you to be more careful about client versions, duplicate logic among different clients (iOS, Android, Web, Dashboard)

Nothing beats Django and the Django Rest Framework. In my opinion, it's easier to code a RESTful API in Django than to configure a 3rd party service.

I loathe Googles various scaling limits.

"You need to ask a Google person to scale further, but hey we're Google and we do everything we possibly can to avoid human contact." Bleh.

> You can’t easily add claims (groups, roles, feature toggles, etc.) to user’s json web token, meaning you have to create and supplement each authentication with a call to the Real-time database.

What? I use claims in JWT with firebase and it works like a charm.

There is a way to cache data in memory.. I don't know why this isn't documented:

https://stackoverflow.com/questions/38423277/does-firebase-c...

I love Firebase, I think it's a great tool. I actually gave a talk about Firebase when I was an intern at Google in 2015. I've liked it for a while. I think it's a simple model that actually lets you build most things very quickly and in a fun way (since it's all real-time).

Here's my response to some of your points

Only easy if you implement FirebaseAuthUI, which has a UI that is out of context and intolerable if you care about UX. Phone verification for example (albeit free, requires ugly ReCaptcha) and the AccountChooser (albeit great concept) opens in a completely Google design.

To me this is a completely acceptable security requirement. IIRC the account chooser has other related elements including accepting permissions and TBH I think there's good reason that there's a standard UX for auth stuff. It is a lot easier to just tell people, "Only trust things on google.ca, and the UI should look like Google too", etc.

Social plugins change all the time and to use the most up to date (like this awesome “Continue as {{Name}}” button) you have to implement the providers’ own JavaScript and other necessities and do a lot of work to make them work together.

You have to do this using Web too. Firebase doesn't make it harder.

You can’t easily add claims (groups, roles, feature toggles, etc.) to user’s json web token, meaning you have to create and supplement each authentication with a call to the Real-time database.

I actually like this feature request. I see it more like something that Firebase could add, but if they are trying to make it fit in with their db, it is kind of an unprecedented feature afaik, so I don't really expect it.

Querying on anything beside a simple key lookup is a pain in the bum. Somewhere, someone understands how indexing, pagination and multi-filtering works but I’ve given up. Don’t forget you do all of this client-side (JavaScript).

Indexing happens on the server side. It's actually extremely powerful. You just have to start with the question: What data do I want to show to the user when it's done? You make the entity ids of that data the value of an object in FB. Then you set up a listener that

1. Listens to all other relevant parts of the tree in real-time 2. Does some calculation on the values it retrieves 3. Saves a new key [ computed_value : entity_id ]

Then, you simply query for the top x keys, getting your entity ids, and in your UI you just instantiate your component to load the data for the entity in its own query real-time. It is fast enough to build nice UI's, that's why people win hackathons with it.

Firebase returns data as “snapshot”, a very weird, encoded structure that is not easily iterative. You have to navigate between forEach, snapshot.key and snapshot.val() to get what you want. I thought that’s the whole point of using JSON.

Snapshots are for things like user profiles where you actually just want to get the object at the given path (i.e. want to retrieve {"name":"mluggy7"} from /users/1).

If you want to iterate things, you should be using the `on` query: https://firebase.google.com/docs/reference/js/firebase.datab...

The way it works is that it it treats an object like an array of data, where the order of the array is the order of the keys in the object. It calls your callback if data is added to the array, moved around in the array, deleted from the array, or changed (but kept in the same position). You can use these callbacks to manage some internal array state where you're holding components that are initialized with the data items.

Write errors are a pain to debug, even with debugging enabled ends up as JavaScript “permission denied” with no way knowing. You have to run your payload against the simulator to get the firebase rule line you had tripped on.

You only have to learn this once :p

There’s no easy way to cache data, especially fragments that requires high computation. Why would a call to the same unchanged node by the same user not return from cache?

Not sure what you mean by computation, and I'm not sure why you'd need caching since the protocol just sends diffs of what has changed. The real-time db is the cache. You do your computations and save them in the real-time db. You can make it O(1) to search an object in both keys and values using indices, JS doesn't even really have that data structure.

REST interface will not use the signed-in user’s credential. You have to pass it as a token (which is just weird, especially if you planned to build a simple CRUD on top of firebase serverless REST paths)

You have to have a token, the firebase API has a token too but it manages it internally. If you use a Firebase REST SDK (of which there are many for many languages) then it will probably manage the token for you and just give you API methods to call for REST functions.

Firebase-admin is ignoring your database validation rules, who’s idea is that I have no clue but it caused me much grief.

Not sure what you mean here. You might be talking about an actual issue.

Cloud functions seems cool but I haven't used it so I can't comment.

(I've talked about Firebase on HN previously, for example [1]. I started using it at Hackathons in 2013-2015)

[1]: https://news.ycombinator.com/item?id=12117522

I have clients with apps that are pushing the boundaries of Firebase. I have strongly suggested the move to Azure or Amazon "serverless" - Azure Functions or Amazon Lambda. I get strong pushback due to "cost and complexity" concerns. I respond that of course "real" development and operations is going to be more complex and expensive than the "toy" proof-of-concept they build with Firebase. But this has been an issue in my career for decades - users get hooked on on RAD tools (Rapid Application Development) and are then shocked that adding "10% more features" will add 1000% to the cost.

I never actually deployed this, so I don't know how it would have worked with lots of users, but when I was writing a game that required "secret sauce" my plan was to have a "server" connect as a privileged user- clients would submit their proposed moves to a write-only queue that was only readable to the "server" which would do a rules-check and update the game state as necessary.

How do GraphQL subscriptions compare for providing realtime functionality?

I'm one of the developers on Cloud Functions for Firebase and would be happy to answer any questions you have. I'll try to keep my responses to my product alone since I think other team members are more qualified to answer those.

Your feedback is both fair and something we're diligently working to fix. In response to each of these points:

1. [Local testing only works for HTTPS]. For better or worse, our product is built in layers. There's the core Cloud Functions product and the "for Firebase" add-ons. You can already see some public changes we've made to the core Cloud Functions emulator that include some support for event-handling Cloud Functions as well as improvers in debugger support. We definitely want better "in house" support and are in the user testing stages of some generational leaps in local testability with the Firebase toolchain. You can reach me at my handle at google.com if you'd like to be considered for some of the user testing.

2. [Debugging feels like a murder mystery]. Yes, this is another thing we are working on. Cloud Functions integrates with Stackdriver Debugging[1]. There are very real issues with the integration today. TL;DR: If you have a steady stream of requests, it will work. If not, the ephemeral instances won't be alive/unthrottled long enough to fetch watchpoints. This is a huge concern to many of us within Google and we're working hard to improve the way it works.

3. [No cron jobs]. Again, a huge feature request and a high priority. You don't need to use your own machine; you can use GAE's free tier to kick off cron jobs for you[2]. Still, a more tightly integrated solution is obviously ideal and is coming.

Closing: We take these issues very seriously. I'm sorry we don't have the solution to your problems today, though all three line up with active development on the team. We are focused on delivering infrastructure required for mature apps with high volume and mission critical traffic. Keep an eye out for our product as it crosses into generally available and beyond.

[1]: https://cloud.google.com/debugger [2]: https://github.com/firebase/functions-cron

When marketing interacts with engineering, it never ends well. And serious engineering tech homepage should advertize sincerely the limits and tradeoffs of its tech. That's how engineers work, and it's something sales people will never understand. We trust techs and people because they explain the limits, not in spite of it.

There's no free lunch. Whenever you pick a technology, understand what are the downsides. If you don't see any, then you probably don't know enough. Nosql is cool, unless you start needing transactions or database level data integrity checks ( hints : you always end up needing it at some point). Cloud hosting is cool, until you realize it's way more expensive for your needs, and that network is going to cost you a fortune. Serverless is great, but then what are you going to do to ensure business rules are exactly the same for all your clients, at all times, etc. etc.

I.. walked the same road, but 2 years ago :(

Here's an alternative I found: https://deepstreamhub.com/open-source/

It works really good. You will like it. Full control + easy interface. Got me started really quickly.

I used with Firebase a while ago, it was quite pleasant to use initially.

I think that all these SaaS/BaaS services do speed up development initially but they slow things down in the long run. I had the same issue with Amazon Elastic Transcoder (for videos) and SNS; once you need to split out different environments (development, staging, production) and then scale to support more regions and start splitting up jobs into more streams; it can get really difficult to the point that you wish you were running your own service instead.

Some years I was on a team that needed to remove a Firebase dependency.

We were using Firebase for simple read-only queries and our dataset wasn't changing much, so statically served nested JSON files/folders were a great substitute.

In case it helps anyone else out, here's the script that automated the creation of those files from a Firebase data dump: https://github.com/zackbrown/firebasic

I'm surprised that nobody has mentioned yet how slow Firebase can be. Especially updates via the REST API can take upwards of 1 second. And that is for a really small database of a couple MB at most (and the updated value itself being a tiny string).

I really don't know what they are doing, it seems they have made all the wrong decisions engineering-wise. I sincerely hope some team at Google is really busy right now rewriting everything.

Firebase documentation is very lacking and their support is slow but it is an amazing product. The problem is when people try to use it generally for anything and everything.

Firebase is not meant to be a backend for any Web app. It is a special tool for specific problems. If you just use it without evaluating if it is a good fit for your problem then you'll certainly run into a wall.

I'm fine in general with Firebase, but feel like its overhyped. It's nice to get little cloud functions, onWrite database hooks, and somewhat realtime data, but if a competitor rose up and took at stab at frequently noted pain points, they could probably grab market share pretty easily.

My pain points:

Cloud functions debugger = -1.

Can't tell you how much fretting I have dealt with using async.each and some buffer overflows or some other low level Node.js error that never makes it to the debugger. And the debugger isn't a plaintext log. It's a tacky UI where each line is an element, the "logs" are 600px high, and whenever you scroll a little you lose your spot on longer JSON logs.

I also strongly, strongly dislike how easy it is to accidentally delete data from storage. That red X icon is wayyy to easy to accidentally click and daily backups only don't give you wiggle room to recover on heavily used apps. This makes it sadly difficult to use their database view to present quick things to others without building a UX for it.

Let's not talk about how setting a field to `new Date()` just loses the value entirely instead of throwing an error or defaulting to ServerTime.

A great blog post.

I feel that Firebase has a lot of services - and one should seriously consider what you are getting for the cost too.

Firebase Authentication - Basically free. You can pay for something like Auth0 and use the Firebase Admin SDK to add Firebase Users on authentication through Auth0 then let that service be your source of truth. Alternatively, you can spin up your own auth service on a firebase function using Passport.js and, again, roll your own solution.

Firebase Hosting - Pretty solid. Nothing crazy great and nothing crazy bad. Easy to deploy and host static files to the edges.

Firebase Database - What firebase needs is a proper NoSQL, but you can get that in the Google Cloud Services. As a Real-time layer for clients, it is pretty good. Not so great if your corporation is on AWS. But, there are options (like deepstream.io) that might require a bit more setup work. How long until every cloud provider has a real-time data layer offering though? Firebase won't hold this space forever.

Firebase Functions - Now, there are a number of comparisons around the functions vs AWS, Azure, etc.. Functions are what they are and they all perform better/worse in various ways. Deploying Firebase Functions is WAY easier than spinning up Lambdas. That said, The Serverless framework makes that much easier too... Serverless actually supports many cloud providers.

If you want to have a real-time app, Firebase, Deepstream, SocketCluster, etc... None of those should probably be your "core" database anyway. They are all great data-sync solutions.

I think that people using Firebase should be aware of growth paths and if they think they will need a feature, build for it. Abstract your code so you can move away from Firebase or extend it with other services. Treat the Firebase Database as the handy real-time layer, but consider storing your data in a proper database elsewhere.

Remember, you can do a complex query in another database and then use the ID results to point the client to Firebase records to sync to (for instance). This, of course, applies to other solutions too. Heck, Deepstream provides RPC calls so you can make those queries then subscribe to your results (if you need real-time results).

Really love Firebase for prototypes, really agree with many of these points that it is not for use in production work.

I'm using (for amy.ac a math tutoring platform) Firebase now since about 10 month and I'm quite happy with it (now). After about ~3 month I became pretty tired of it since I came from a SQL background and I had no way of dealing with fancy queries. At this stage I almost switched to Deepstream (Sorry deepstream but non of your examples worked, so no Deepstream for me. Also I need todo my own load balancing, etc.).

Why I still use firebase has 2 major reasons. 1) Cloud Functions 2) Using Firebase-DB as my model and never query anythings from firebase. 3) I really don't want to touch docker/aws/load balancing/etc.

In my case, the client simply listens/writes to a particular model (DB-path). A cloud function will wake up, manipulate the model and falls a sleep.

That pretty much means, every view-model a user can see is pre-calculated and stored in the DB.

Most of the database concerns have been addressed in other blog posts etc. If you need relational data, don't use firebase. Period. Where you need "anything beside a simple key lookup" for the majority of your queries, go elsewhere. That's the first rule of Firebase.

The second rule of Firebase is structure your data and populate it in a way that makes it simple to fetch with a simple key lookup.

Not one mention of Horizon by RethinkDB? :D

The stack he describes at the end is pretty similar to mine (only Python instead of Node and PostgreSQL instead of MySQL); although I actually don't have a problem with firebase.

In the server-less section you stated:

> "You are forced to do everything client-side"... "including your SECRET SAUCE"

How I see it is the "static content" (which I assume is a SPA) shouldn't contain anything more than the conditional logic to decide when something should be rendered or retrieved from/ sent to the server.

If the "SECRET SAUCE" you are referring to is the conditional logic, then you shouldn't worry as this can already be derived purely from interaction with the UI.

It sounds like the company is growing up. Firebase is great for simple use cases but has too many limitations for most cases.

Ah the tech cycle of short-sightedness going from an advantage to a disadvantage.

So far, I have no complain using Firebase Cloud Messaging for push notification.