We’ve launched dozens of applications on Firebase, utilized nearly every facet of the platform, and designed a playbook for scaling gracefully. Suffice it to say, it’s proven an invaluable tool for K-Optional Software. As recently as March 2022, our developers were cheering innovations like Firebase Extensions. Unfortunately, three major developments in the past few months have polluted the developer experience and consequently K-Optional will shift towards alternatives for green projects.

Firebase: the good

The Google-owned platform-as-a-service (PaaS) enables builders to punt on several infrastructural decisions: content-delivery networking, NoSQL database event handlers, and network topology to name a few. True, a bespoke bundle of native services built on AWS / Azure / GCP bests the Firebase suite in pure performance. But when we consider developer hours and maintenance costs, Firebase is often a logical play.

The original Firebase Realtime Database felt fairly revolutionary, especially before the mass acceptance of WebSockets or the emergence of Server-Sent Events. You could write applications in sync with real-time data without heaps of transmission logic. Those who have home-rolled messaging applications with long-polling requests sure appreciated it.

In fact, there are many aspects of Firebase we love:

Firebase: the not so good

On the flip side, there are also quite a few pieces of Firebase that have given me pause: