Backend as a Service (BaaS), is a service model that provides web and mobile app developers with an easy way to quickly setup and deploy their app’s backend. They usually provide services such as databases, authentication, file storage, serverless functions, among others.
Before the rise of BaaS, developers could only resort to custom backends that they would have to build from scratch. This involves setting up the servers and writing the backend software, that should be made robust so that the security and scalability of the application is ensured. Although this promotes better control over the backend, it is time consuming, requires greater expertise and can be more expensive.
Using BaaS, developers can eliminate the complexity presented by custom backends, by offering pre-built services that have been tested by a great number of developers for many different solutions, and it also allows them to quickly integrate them into their applications using APIs.
Merits and demerits of both approaches
Traditional Approach
By employing the traditional approach, developers gain more control over their technology stack, which is a great advantage since each application can have very specific needs that can be addressed by tailoring the backend to perfectly align with those requirements.
Another advantage of using a custom backend is that in the case the backend fails, the developers can be certain that the issue is theirs and theirs alone, effectively eliminating the the uncertainty that comes along with a BaaS solution, which could leave the developers guessing whether the issue is on their side or the side of the service provider, which could consume precious time from the development process on reading up on unofficial community documentation on forums, in case the presented issue was not recognized by the provider.
On the other hand the traditional approach could hinder some developers, since its implementation takes non-trivial time. This is especially important for startups, since most of the time they don’t have a big enough budget to allow for the lengthy development of a traditional backend. Furthermore, maintaining the backend both on the software side as well as the hardware side is a resource intensive task, that could require someone like a system administrator to tackle those issues any time they are presented. If we consider the additional cost of setting up the actual infrastructure, it is clear that a custom backend can prove to be quite expensive.
Backend as a Service
A BaaS solution can serve to solve most of the issues that accompany the traditional approach, but it isn’t without its problems.
First off, using a BaaS, developers can rapidly deploy their backend, since the extensive feature set of most BaaS solutions cover the most common functionalities of contemporary applications. All the developers need to do is to read the documentation provided by each service; which most of the time comes with code snippets for multiple different programming languages. Following the docs can allow the developers to quickly test new features, just by copying and pasting the provided snippets, and tailoring them for their specific needs.
BaaS also tackles the maintenance and infrastructure problem we mentioned for the custom backend, since the resolution of such issues is almost entirely left to the service provider. Some BaaS give developers the option of deploying their backend on their own server using docker, so they could still be required to set up some rudimentary infrastructure for their server. However if the BaaS provider has written detailed documentation on the deployment process, this task becomes almost trivial.
We can see that BaaS is a more inexpensive option since, in most cases, it eliminates the need for someone like a system administrator and does not require the implementation of complex features such as user authentication. Many BaaS provide a no-cost plan, usually allowing for a more limited version of their services, like allowing a smaller amount of requests or providing less storage than the paid plans, which is ideal for the development stage. Even when the developers require more resources, the paid plans would end up costing less than the traditional approach.
However, BaaS can sometimes hinder the development process, in cases where the need for a certain feature arises, which is not supported by the BaaS. In such cases the developer could either choose to drop that feature entirely, or migrate to another BaaS. If the developer chooses to migrate, they can face another issue, where two different BaaS solutions can have completely different implementations. For instance, one BaaS could have an SQL implementation for their database service, when another could use a noSQL approach. If this were the case, the developer would have to convert their entire database to a completely different type, which would in turn require changes in the database schema, and sometimes even require changes to already implemented features. All that can become tedious and time consuming.
Another problem with the BaaS approach can be the lack of detailed documentation. This isn’t a problem for all BaaS solutions, but in some cases the provided documentation may be based on some very particular use case which would force the developer to either comply with the example use case or search third party forums, which can become outdated and waste the developers time. This wouldn’t be the case with the traditional approach, since it allows the developer to tailor each service exactly on their use case.
Conclusion
Ultimately each solution has both advantages and disadvantages that one should take into consideration during the design process. Choosing to use a custom backend could result in the creation of a more robust application that allows the developer to know exactly what is going on with it in case it fails, while sacrificing valuable resources for its implementation and maintenance. Opting into using a BaaS can allow the developer to quickly set up their backend and provide them with peace of mind about its maintenance, but force them into a more strict feature set following the provided services, and cause issues in case they wish to migrate.