3 Cases where the "Back-end as a service" may fail
The popularity of BaaS (Back-end as a service) is such that many companies nowadays choose to use it, FireBase being one of the most used. The advantages of implementing it are mentioned very often, with time saving development being one of the most outstanding.
However, not all companies or projects are eligible to implement BaaS; and although each case is particular, there are three (3) consequences that usually occur and result in disadvantage in these cases:
BaaS's resources are limited, there are always characteristics in each service plan, if we do not pay attention to the use of the same resources, the price can rise considerably, reaching the point that it can become unsustainable over time. This is the most recurrent problem of the companies or projects that implement this architecture; it would be ideal to have a sustainable plan which ensures that as the mobile or web application grows, it has the ability to become profitable.
There is no total control
Depending on the BaaS used, there is a drawback that arises from its use, and it’s that in some occasions the data isn’t ours, in the case of FireBase for example, the records that we use for user authentication do not export them directly, they are always on the platform and we cannot migrate them to other services. This makes us tied to the platform, we can’t change and can’t always use the data as we want.
The resources in all the plans of a company are usually limited, that is why we can’t always trust in having scalability. Many offer prices according to consumption, but as the price rises, they might have a limited budget for a plan of greater characteristics. This may be subjective for each company, but depending on the expectations and limitations of the context, it isn’t always possible to scale an application. Of course this happens mainly when something really big is developing.
When to choose "Back-end as a service" to develop a web or mobile application?
The main thing to know when using BaaS is to know the limitations of the project, some recommendations are:
Resources don’t exceed budget
Review each service plan and verify if our largest user base or resource consumption does not affect the budget for that project, in other words; if we’re able to pay a higher plan for the consumption.
Creation of a viable minimum product
Much is said in the context of the startups from the speed with which it validates ideas, services like Firebase are very attractive for decreasing the time of development and the money that will be spent (mainly because it´s possible to pay for the amount consumed and not a complete plan).
The creation of an MVP (Minimum Viable Product) aims to validate an idea quickly or to confirm the functionality of an application to operate, and in this case BaaS is very effective, they make prototypes in record time!
The use of a Back-end as a service depends a lot on the project that will be developed. Typically, for business projects its more effective to create their own Back-End, using technologies like Node.JS and MongoDB to create APIs or even others like Hood.ie, which allows to create a selfhosted BaaS, which can allow a greater control on the data. Of course, we must bear in mind that the disadvantages would be the configurations and maintenance of the server, but it is something you would have to face in these cases.