Rediscovering Firebase

7.23.24

A little over a year and a half ago, I wrote a blog post exploring BaaS (Backend as a Service) platforms. I chose three popular ones: Google’s Firebase, Supabase, and AWS Amplify. Technology changes so fast these days, but these three are still relevant and top choices for many developers. In the engineering world, AWS is a big deal. Most hosting providers and services typically just use AWS under the hood anyway, so I always thought it made sense to skip the middleman and do it yourself. I have been using AWS services for a long time on professional and personal projects, and I really wanted to like Amplify. Unfortunately, it ultimately proved to be a little frustrating and limiting, so I concluded that using AWS services à la carte is probably the way to go.

I was also attracted to Supabase for a few reasons. It is open source, which is very cool. You can self-host Supabase if you want to. A big one for me was the fact that the database is PostgreSQL. I have traditionally been under the impression that most data is relational and that you should always default to SQL databases. I thought MongoDB and the MERN stack were more or less for the YouTube and bootcamp crowds. Fun fact: working on a professional project using AWS DynamoDB, which is NoSQL, helped me change my tune and open up to NoSQL.

I make no secret of my preference and fondness for Next.js. The Next.js community does seem to have one gigantic sticking point though, that causes endless debates and has spun off tons of third-party applications to try and solve authentication for Next.js applications. Auth.js, or Next-Auth (depends on who you are talking to), is a pretty solid option where you can sort of roll your own auth and use whatever database you want. It can also act as a middleman to other auth services. Auth0 is an awesome option if you can afford it. Clerk is a newer solution that I see being used a lot more in the wild lately. Nobody loves AWS Cognito (looking at you, Amplify). Staying in the loop with the Next.js community, I started noticing people recommending Supabase and Firebase just for their auth systems. Full circle.

I recently had the opportunity to work on a greenfield MVP, and all signs were starting to point to Firebase. Spoiler alert: I am now a big fan of the platform and have even created an open-source boilerplate starter for using Firebase with Next.js. Feel free to check that code out as an example or even fork it and use it for your own project. In addition to the obvious technologies, I also included Zustand for state management and to help with the auth by setting a cookie. In addition to fully fleshed out auth pages, I included protected pages to manage user account data as well as a posts section to demonstrate accessing public data.

Let’s start with the auth because that's how I came back to Firebase in the first place. In order to use Firebase Auth, you need to install the SDK. After a simple npm install and setting environment variables in your firebaseConfig file, you now have access to an extremely reliable and secure authentication system. It uses JWT under the hood, which should be familiar to most devs, but it handles the creation, storage, and refreshing of tokens for you. They offer pre-built UI components for their auth, but you also don’t have to use them, which is awesome. Sometimes trying to customize pre-built auth components can be a big headache. While it’s nice creating and coding with the Firebase SDK for auth, your boss will like it too. This is a Google product, so the user analytics tools available are extremely comprehensive. You can track and monitor specific user engagements, page retention, conversions, create custom audiences, get behavioral insights, feature usage, user flow analysis, real-time custom reports, etc.; all on top of security and monitoring features like fraud detection. Yes, you do end up with some vendor lock-in by using Firebase Auth, but at least you know Google isn’t a startup that won’t be around next summer.

After auth, the next star of the Firebase show is Firestore. Firestore is a serverless, cloud-based NoSQL document database. There is a reason that startups and solo devs love serverless architecture: money (of course). With serverless architecture in general, your costs should only go up once your app's usage is up, so you don’t have to pay for resources you aren’t using yet or may never need. Firestore will automatically scale up and down based on your app's usage.

In addition to the serverless architecture and automatic scaling, Firestore comes out of the gate with real-time data capabilities. This was also a big point of concern with the greenfield MVP because we needed to build a live chat feature. While real-time data can be achieved with most databases, it is usually pretty complex and requires additional resources; for PostgreSQL, you would need message brokers like RabbitMQ or some sort of additional WebSocket server. Firestore uses listeners to monitor changes in data. When a document changes, a snapshot is sent to the client, providing the updated data immediately. This is done using WebSockets, ensuring low-latency updates.

Regarding the live chat feature specifically, we explored some other popular options. There are companies, services, and APIs that help small teams and startups build real-time data apps and tools. I’m going to name-drop a little. Three popular ones are SendBird, PubNub, and Twilio. SendBird lets you get started with 100 MAU (monthly active users) for free and then jumps up to $400 a month for 5k MAU. PubNub gives you 200 MAU for free and then jumps to $100 a month minimum for a pay-as-you-go plan. Twilio also gives 200 MAU for free but then jumps to $0.05 per user up to 5k users and then $0.475 for up to 10k MAU. That's $475 a month for 10k users. An estimate for 10k MAU using a live chat feature built with Firebase is about $15 a month.

The next big feature in the Firebase ecosystem is Storage. Storage is where you store and serve media content like videos and images. I found Firebase Storage to be pretty comparable to AWS S3 Buckets. The same way S3 integrates well with other AWS services like Lambda, RDS, etc., Firebase Storage obviously plays really well with all of the Google varieties. I would say developer experience is quite similar. AWS uses IAM and bucket policies, and Firebase Storage uses security rules. Storage will also automatically scale and has pay-as-you-go pricing. Firebase Storage also leverages Google's global CDN (content delivery network) to deliver files quickly and reliably, regardless of the user's location.

Firebase provides a comprehensive suite of tools that are particularly suited for modern web and mobile application development. Its robust authentication system, real-time database capabilities, and flexible storage solutions make it an awesome choice for developers. The ease of integration with other Firebase services and the cost-effective scaling options just crank the appeal. Whether you're a startup looking to quickly develop an MVP or an established company seeking reliable and scalable backend services, Firebase offers a powerful, user-friendly platform to build upon. If you're interested in trying out Firebase, check out my open-source boilerplate starter for a head start on your next project.