firebase-admin-node VS reactfire

Google has an Edge Network, but they push serverless functions like Cloud Run, which is also what version 2 of Firebase Cloud Functions use. Firebase Functions need a Version 3, which is built on the Edge. However, first Firebase, specifically firebase-admin would need to work on the edge. Google, who makes Angular, might then be able to compete better for deployment options. Cold Starts are terrible and should die IMHO, unless you have have specific use cases for them.

There's a lot of different ways to skin this cat, the easiest would be to use a client library like firebase storage to upload the photo directly and you can get an image url from that to use. If you are trying to send it your own API, then you probably want to set up a multipart http request to attach the image and then with your admin storage library of choice to upload the image. I have done the second one before with ktor and firebase admin sdk .

Hi, I've recently gave supabase a shot to as an alternative to firebase because I needed SQL. One thing that I've struggled with from the start is that supabase seems to ignore backends completely.

I don't want to use supabase edge functions, since I want to keep it simple with a single express backend and don't want to be vendor-locked.

In firebase, the Admin SDK https://firebase.google.com/docs/admin/setup solves this, but seems to be missing in supabase. For example, for a simple JWT verification, I had to go to old github issues, rather than finding the answer in the docs. https://github.com/supabase/supabase/issues/491#issuecomment...

IMO, the best supporting runtime for firebase would either be nodejs or flutter. Along with firebase admin, you could technically fullstack JS/TS and have better-than-average support for the firebase ecosystem (e.g. NextJS for frontend/apis, react native for mobile). However, it doesn't mean you can't use .NET with firebase.

Without looking too far into errors other people had, it seemed like it had to do with syncing clocks (what a strange error) - the problem could go away if you reissue a different service account key from the console or sync your local clock(???)

The one thing I was missing for my latest experiment was a reliable way to authenticate users and allow them access to their profile. There are other services that can be easily integrated but they can get quite expensive. Firebase on the other hand has a good free quota; perfect for this use case so I started by installing the Firebase Admin SDK. But alas the admin sdk has some dependencies on nodejs which are not included in the workers/functions runtime. 🤦‍♂️

ReactFire

Are you using Firebase? If not, you probably should. You can call functions (with Auth) from your react app. There's a framework you can use to help: https://github.com/FirebaseExtended/reactfire

I was an early developer at Firebase. I think we made Firebase so easy to use and never spoke on about the technicals that the whole software ecosystem now underestimates the complexity involved. I see various Firebase competitors asserting various "mistakes it makes" without really understanding what it delivers, which is understandable because we never marketed it like that because we spoke only about how it can help you build easier.

The idea that n queries instead of a join is slow is not as true as you would think. Firestore supports streaming and pipelines at its core, and can reuse cache across operations. At the end of the day, the data goes over a narrow network channel. If you can saturate the channel, and don't leave any gaps, what's the performance difference if the data comes from a single query or many that are back-to-back. The data is transferred to the client either way. Both Firebase databases are pipelined, so this "many round trip" argument is not a decent argument if the client can issue the queries without waiting for responses (such as the code in this article).

The other is consistency levels and correctness. I constantly see devs call Firebase an eventually consistent database which is wrong, its causally consistent [1], and this makes a huge difference when trying to do OLTP. The offline capabilities are built on the consistency primitives, and it's the only way it can work. So while this convex article is banging on about "End-to-End Correctness Philosophy", they miss the most important quality of correctness, and if they are not careful, will miss the required engineering, and then be unable to deliver an offline cache over real-time streams. I see this playing out with Supabase, I warned them personally before they got into YCombinator that what they were building was not causally consistent. Since then, they have had to rearchitect their real-time features after shipping them. (I have not reviewed their latest design yet so I have no idea whether they have it right yet).

Many things sucked about Firebase. The bespoke security rules and the lack of views. So Convex is on the money shipping functions on the backend. I think Supabase is shipping competitors' mistakes with row-level security language. Personally, I think Firebase's mistakes can be fixed with the addition of an open-source Firebase server [1], as the clients are already open source and the mistakes are all to do with just the server. The real tech was always in the clients anyway (offline cache, connection management, operation queues).

It will be interesting to see if building expressly for React is a good idea. Firebase shipped many adapters, like https://github.com/FirebaseExtended/reactfire, using the "thin-waist" principle of not over-fitting. But Javascript technology moved from callbacks to async while Firebase was in the field, so the current API is not now idiomatic. But convex is setting itself for even more ecosystem fragility, what if React changes API or falls out of favor? This is a big risk! I hope they can roll with whatever happens!

[1] https://observablehq.com/@tomlarkworthy/redis-backend-1

Since you mentioned you're also using React, we have a React specific library (ReactFire) that also helps out quite a bit.

Use ReactFire! It's our official library for React and Firebase. It has a bunch of useful hooks that probably handle most of the actions you are looking to do.

This is a quick walkthrough of a code example using ReactFire v4 in an application. The application supports login, logout, create an account, and protected routes. We also walk through two approaches for protecting routes since the AuthCheck component that existed in v3 no longer exists in v4 of ReactFire.

FWIW check out ReactFire, it gives you hooks and context for Firebase. Will likely feel more natural than using the vanilla platform-agnostic SDK.

reactfire