Why I’m dumping Firebase for Web

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.

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.

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

(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/

> at 100k concurrent users

That is a huge number of concurrent users though.