firebase-js-sdk

Yes, Firebase also stores refresh tokens client-side [1]. The trade-off that both Firebase and Stytch are managing when we follow this pattern is the following: - You can provide a significantly better developer experience and set-up with this architecture. While there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies by proxying the 3rd party APIs as subdomains, this creates new burdens on the developer for minimal gain considering that a XSS attack vector indicates a severe compromise of the application. - Today, customers that feel strongly about using HTTPOnly session management will opt for a direct integration with our API using one of our back-end client libraries rather than our JS SDK. While we have interest in providing a HTTPOnly solution in the future to interested customers, we’ve decided the default beh

I most vividly recall unit testing, storage emulator, auth. For example: https://github.com/firebase/firebase-js-sdk/issues/5086 > Steps to reproduce: > Step 1: Read the documentation for setting up cloud storage unit tests at: https://firebase.google.com/docs/rules/unit-tests#storage > Step 2: Attempt to write unit tests following the examples in the documentation The reporter describes five problems which will thwart you when you try to write code according to the official documentation. How did these docs ship? Did nobody ever try the sample code and verify that the features worked as advertised? Did nobody write any tests to validate that the features actually worked? Are there no policies in place (e.g. "new features require tests" or perhaps code review) to prevent such mishaps?

Also, you guys were asking about Firefox support so I did a deep dive and we're ready go to but Google Firebase doesn't support the moz-extension URL scheme. Just the chrome-extension scheme. I added a feature request for them to support chrome-extension here: https://github.com/firebase/firebase-js-sdk/issues/4002 I'm going to submit a PR to them to support moz-extension too.

This seems like a pain point easily solved by a niche firebase-to-something-else migration tier. Seems like there's a small but possibly profitable company waiting to be created here: - Gather firebase's "true" API surface/interface, create a model in your typed language of choice. This might be easier/harder depending on how many special features there are... I haven't really seen openapi schemas for firebase, but that would make this really easy. - Make implementations that don't save to firebase (and probably one that does, since it'd be very easy to write and would be a good baseline) - Create a per-version fork of the firebase SDKs (ex. JS[0]) that points at your servers instead of Google's - Offer a cheaper firebase (you could aim at Heroku customers?) - Offer a painless migration from firebase as a feature - ???? - Profit Business

omg, I literally just yesterday started working on a project of the same name. I had written a small ORM for my own firestore usage that I planned on open sourcing. I just looked at this and the fact that it doesn't support transactions is a major dealbreaker. So you do an update on two entities and one fails because of some random network error, now your database is left in an inconsistent state. Not good. Any ORM should, from the start, be written around transactions. The other issue here is how the tests are written. I appreciate tests, but in this case, they are written agains the client sdk, not the admin sdk. I discovered a huge inconsistency between the two API's that I just filed an issue for... which this project doesn't hit, because it doesn't use transactions... https://github.com/firebase/firebase-js-sdk/issues/2112

The backend is almost entirely custom, though many common low-level open-source components are used pervasively. For example, for components written in C++ we use Abseil, Google Test, etc. The SDKs are all open source and make use of other open source components: * Android: https://github.com/firebase/firebase-android-sdk/tree/master/firebase-firestore * iOS: https://github.com/firebase/firebase-ios-sdk/tree/master/Firestore * Web: https://github.com/firebase/firebase-js-sdk/tree/master/packages/firestore For example, the iOS SDK uses LevelDB for local key-value storage and gRPC for communication with the backend.

The firebase web SDK is written in TypeScript: https://github.com/firebase/firebase-js-sdk

Heh, I asked that question. I implemented the solution in a Firebase wrapper and it works great. Anyway, Google is solving this in JS by implementing persistence. https://github.com/firebase/firebase-js-sdk/issues/17