Using React & Firebase. A Chatroom

Published: 6/19/2024

Introduction

Why build a blog when you already have one? That was the question I asked myself. And then... I built it. Again. So why did I do it? Well, if for nothing else, to learn a different way of implementing web pages and applications. Also, I really wanted to play around with Backend as a Service and chose Firebase as the culprit.

What is this about?

I will discuss how I planned - which in all fairness, wasn't all that much - this project. Why I decided that a blog would be a good fit. Why I chose Firebase. And how I went about doing all that crazy stuff.Let's take a walk.

Tech Stack and the Whys

Obviously, React and Vite are my go-to to scaffolding a frontend application. That was easy. Style was also a no-brainer with Tailwindcss. And for what I was aiming for, the frontend stack was it. I also add Lucide library for icons, but there was no need to over complicate this. The goal was simple, have a website where users can login and post something. Anyone can read what has been posted by users, but only logged in users can post or edit their post. I will talk more about this later. The next piece of the puzzle was the backend. Where to store those posts? How to keep track of users login? I could go the long route and build the backend myself, but I had done it for a task-manager application I built and I would like to avoid the hassle. I also want to experiment building with Firebase. There are other options to experiment with, Supabase and Appwrite are some examples. But I stuck with Firebase.All you need is a Google Console account, and you can start building. Their suite offers many solutions for your backend. For this project I'm using Firebase Firestore which is their database, and also Firebase Authentication to handle users. I'm not going to fully dive into the specifics of the tools I used as this is not the purpose of this posts.

The Blog

Well, the blog itself is actually pretty simple. You have to sign in to be able to post, but you can read whatever anyone posted. There's only the home page and the posts page, so, in terms of complexity, I kept it to the bare minimum. The objective of this exercise was really to see in action how Firebase works and what can I do with it. You can check it and give your opinion if you'd like: LIVE BLOG

The Process

First thing after I have started the project with Vite is to install the necessary dependencies. Now, what was I going to need for this? Well, as I mentioned above, actually very little. Tailwind, lucide, and firebase. I also installed React Router for easy routing solution.I like to break down my projects and apply the component mindset of react to almost everything it makes sense to, although, of course, organizing a project might and certainly changes from person to person and organization to organization. Either way. Here is how I structured my project:This for me helps to keep my code organized and easy to maintain. One thing I started doing recently is to use a Layout. That has helped me a lot in keeping my the design and alignment clean and concise throughout the project. Here it can be a bit of an overkill given the scope of the blog, but, say I decide to scale this, seems like a whole lot is already made easier. I usually like to separate pages as what I imagined as a full change of view, and components as still within the boundaries of the page loaded as the view, if that makes sense. That's why create post is more of a component than a page, in this case. Then again, this can easily be done in a hundred different and yet still functional ways.

Using Context

Learning how to use Context in react is really one of those enlightening moments of development. Of course, understand how state works is a must to fully take advantage of Context and as a somewhat noob, I'm still long ways from being a reliable source of information on how to properly use Context or explain how it works. Part of the journey ah. anyhow.. I did learned a great deal about state and using Context while building this application. And the gist is, while most of your components will have their local states and the occasional parent-to-child prop, in many cases there will be some states that one or more components need and may or may not be a sibling of the same parent, making passing props a bit of a problem, known as prop-drilling. Context provides a way to avert that issue. By creating a Context provider, we then wrap our application, or that parts that matter, with said provider, which well, provides all the necessary states and handlers to the children beneath it on the DOM tree. Again, there's a lot more to unpack about it, and I will talk more about it in a future post. By creating a AuthContext and wrapping my whole <App /> with it I can then access the state and handlers provided by the Context anywhere in the app, without having to pass props around from component to component. With that in mind, I also created a ThemeContext to allow me to apply dark:light mode. Which felt pretty awesome to be honest, one of my first implementations of dark mode.

Firebase Integration

Next was the actual integration with Firebase. And in my opinion, as someone who doesn't have as much experience, it is pretty awesome. I thought it was very easy to understand what was going on and what I needed to do. The steps are very clear and the SDK integration is really simple. Firebase provides you the necessary code to start running. You can then expand on the services you integrate with your app. Again, since I'm using just Firestore and Authentication, it was easy peasy. I will soon post a full tutorial on how to do it.One of my main concerns when using any API service is, of course, the keys, but Firebase is different. The best thing is you are safe to connect it directly on the client, which is what I was looking for, of course. You do have to make sure you secure your project in the Google Console and the firebase rules however. Firebase provides a lot of tools out of the box that makes working with it very clean. I have yet much to discover and am now working on a separate project that makes use of Firebase, maybe I'll talk about it too.

More about the code

With Firebase connected. I had a few more steps to finish on the database. Create a document for the posts and a collection. I placed some dummy text and tried fetching on my frontend. And that was actually simple. This was actually mind blowing for me. Bit of tangent, but I find the experience of navigating through the tools available for development fascinating. Never ceases to impress.The rest of somewhat straight forward, I needed a way for users to create a post, and a way for them to edit. To do that, I first needed to make sure the users are logged in. Using Firebase Google Provider for authentication, I take advantage of their easy-to-use SignIn and SignOut methods as well as keeping track of user state, remember AuthContext. I thought about using email-password as an authentication method, but refrained from doing it for many reasons. To both create and edit posts I check if the user is logged, if not, they are either redirected or, in the case of editing, your simply read the post. That is because I made it so that the PostDetail is also the Edit post. I could and probably should actually just make it a separate component, then again, simplicity is the name of this project.

Testing

Well, this is Achilles's tendon at the moment. I have avoided testing not because I don't like but because I tend to think that whatever it is I'm working on doesn't really need that much testing. I could skip telling you this, but I'm being honest, I have not done unit testing or integration testing as much as I should yet. However, I did make sure to debug as often and as much as possible in production with the good ol' **console.log**.

Deploying

I really like this part. I don't know if it is because it means I'm half-way ready to showcase my work but I do like it. And I say half-way ready because most times, there will be many more deployments before the actual "final" stage production ready product is ready, as of course, there will be bugs. (Even more when you don't properly test)My deployment steps are somewhat simple nowadays. I use, for the most part, the same process. Merge from dev main -> push to github -> link repo on netlify -> configure env variables and build scripts -> deploy. And that is pretty much it. With how netlify works with github, by the most part, your projects will be configured by default to do CI/CD. So all you have to do is push your code to github and netlify will deploy the new build.As that's it. A live website, fully responsive and with Firebase integration. Beautiful. Well done. *pat pat*

Conclusion

My take away as a solo web developer who has a steep mountain to climb is: Using BaaS can be so very helpful and can streamline so much of the process of thinking about how to handle x and y on the backend. Or how to properly authenticate and where to host. So it is definitely a win. However, I do think that, regardless of how much you need backend right now, at least properly learning how those pieces are coming together is also a great skill to have under the belt. I guess the bigger factor is really infrastructure. These services can sometimes provide so much that if your business is small to medium size you might as well use their services rather than setting up your own backend server. There are tradeoffs, as it is to be expected. I honestly can see myself making use of firebase in a number of my future projects. TLDR: Firebase can be a great choice if you want to be able to scale and not have to build the backend yourself.That's it folks! I guess this sums up the process I went while building the "blog". Please check it out and leave a post with your thoughts. Ete-blog

0xd