While working through building a front end on a new project, I wanted to decide what my back end architecture would look like. Previous to this project, I had been using custom built APIs and third party libraries to manage my back end. But, I had always wanted to learn more about serverless computing. Being an avid Google user (I love all of their APIs and authenticating users using Google is a dream) I had my sights set on Firebase for a very long time. Now having finished my bootcamp with Flat Iron School, I was looking for a new frontier to explore and create with. So, I did what I always do when looking at a new technology or technique: a SWOT analysis.
For those that don’t know, a SWOT analysis is a chart showing the strengths, weaknesses, opportunities, and threats. This is often focused on a thing like a business or a concept and offers a great way to pragmatically assess something rather than a simple pros and cons analysis. I find these really useful as it helps to research alternative viewpoints and to truly look at a weakness or threat and see if you’re willing to accept it or what can be done to mitigate it. So, let’s see what my SWOT analysis of Firebase showed me.
If you want a quick visual reference for my understanding from my research, please use the above graphic. I’ll be stepping through each of these sectors and explaining briefly the rationale behind each.
I feel these are qualities that help serverless and Firebase stand out and make it an easy choice to use for a back end.
Easy to manage
The tools offered by the CLI and information accessible in the documentation is excellent. Adding in Firestore or Cloud Functions is incredibly simple and can be done at any stage of development. What is even more useful is that you can manage these sections of the codebase in your IDE/ text editor or on Firebase’s tooling online, giving you multiple options to manage your app.
No need to learn a new language
Scales up and down automatically
This in my opinion is one of the main draws to learn serverless as a budding web developer. The server side, or lack thereof, can cause bottlenecks if not optimised correctly. Excessive page loads submitted to a server can cause it to become unusable due to handling multiple requests. From a cyber perspective, it could also be susceptible to the Slow Loris attack or a DoS. Serverless handles this all and ensures a constant up time of our services housed on the platform.
These are aspects I’ve seen can hold Serverless back. These can be navigated to be almost non-existent, but are things to consider when picking up the technology for the first time.
Troubleshooting errors with a serverless app can prove difficult. This is often due to the opaque nature of the back end when using this approach. Many errors just will not make sense unless you are also familiar with the reporting and logging built on the platform. Set up too can also be somewhat difficult if this is your first time using the technology. Firebase, in my opinion, manages this weakness very well by offering great, easy to use tooling with awesome metrics and reporting. You can even utilise A/B testing out of the box!
Opinionated back ends
Firebase specifically has this problem as you are stuck using Cloud Firestore, a NoSQL database. While this leads to Firebase being very similar to a MERN stack, it does mean you lose some granularity of data and the ability to utilise relationships to add loads of context to your database and models a conventional back end API can give. It also limits the accessibility of hooks into 3rd party APIs on some actions. However, Cloud Functions can somewhat circumvent this.
Scaling up and down automatically
No, this isn’t a mistake. I do think that this is both a weakness and a strength for serverless and Firebase. When you lose control of an aspect of any process, you can start to introduce bugs due to the unintended side effects caused. As a junior developer, or someone using serverless for the first time, you may not realise a problem caused by this and start to focus on other areas of your code not understanding that the back end itself is causing issues.
These are qualities serverless and Firebase offer to any developer using them. These offer a great opportunity to truly focus on other aspects of the codebase rather than tasks that could become repetitive or awkward to complete.
When working with serverless tech, deploying your website is fast and oftentimes exceptionally easy. Firebase in particular is incredible. One command. Just one, and your website is up behind a URL that other people can access. It’s equally as easy to pull down too if needed and version updated are handled exceptionally. Truly a great opportunity to work on things and see them happen in real time.
Speaking specifically for Firebase here, I don’t think it has been easier to implement 2FA or provider sign in/up anywhere. With a few changes to settings in the Firebase dev console, you can have an app that allows users to use 2FA with their mobile device and sign in with Google. Then with a Cloud Function to manage the creation of a user document in Firestore, you can have an awesome user authentication experience with absolutely minimal work done on the developer’s side.
Reporting and metrics
I’ve mentioned this a few times and with good reason. One of the main reasons serverless can struggle is troubleshooting. Firebase absolutely does not suffer from this issue. With great tooling accessible to you out of the box, showing you page visits, load times and elements clicked on a page, you can truly optimise all aspects of the user experience.
These are somewhat similar to weaknesses, but they are much more difficult to circumvent. These are often qualities that we have to assume when using serverless and can cause some headaches.
When using serverless, you can find that many of the tools offered to you come part and parcel. With Firebase, this is also true. If you want to make use of the awesome user auth features and excellent front end testing, you will need to build everything inside of the Firebase platform. While this can seem somewhat awkward or annoying, it makes sense. Firebase specifically is a back end as a service style product.
As mentioned previously, cyber attacks are something that web developers need to be aware of and manage on a constant basis. While Firebase is excellent at managing this aspect of our site for us, it can start to miss the ball when vulnerabilities are discovered in packages used. While Node is an awesome technology, it is somewhat vulnerable to security exploits due to the accessibility of source code for these modules. Netlify, for example, connects with the source code on Git. Git then uses dependabot to manage dependencies and ensure they are always up to date. When using Firebase, you don’t have access to this level of package security.
This is one thing with serverless that is unmitigable. Cold starts on functions that have not been used frequently can cause extreme slow downs in the user experience for users that encounter them. To be clear, a cold start is when a serverless function is called for the first time and the environment and Node process, in Firebase’s case, need to be created before the function can run. There are ways to optimise this and reduce the number of cold starts, but this can be somewhat tricky to implement depending on the code already written.
In summary, serverless is a great direction to take a web app if you aren’t sure what your back end is going to look like. The ease of use and speed of development is definitely worth the learning curve when setting up. Firebase specifically has great documentation and a whole host of functionality that allows for the development of great ideas quickly. The concerns to be wary of when using Firebase specifically are the cold starts, lock-in to tooling on Firebase and some opacity in troubleshooting errors when starting out. Otherwise, it’s an easy choice for me as one of my favourite technologies when developing on the web.