Except for very simple use cases, serverless platforms in general encourage bad software design patterns.
For example, in this case, if a regular database was used instead of Firebase, "counting the number of supporters" would have been done inside the database using a query. The worst that the developer could have done is forget to index to the relevant column; performance would have been sub-par but still orders of magnitude better than Firebase because the bulk of the data would not leave the database if there was a proper query language. With Firebase, when doing complex calculations, not only does the data have to leave the database, it often reaches end users; the calculations then happen on the front end and this is a huge problem in terms security, performance and even correctness (due to latency and the fact that other users may be making conflicting calculations simultaneously based on slightly outdated data).
Also, based on the article's description of the application, it sounds like it may have exposed potentially sensitive data (about supporters) to all users so it may have introduced a security vulnerability. I would not be surprised if this was the case.
> With Firebase, when doing complex calculations, not only does the data have to leave the database, it often reaches end users
Any time sensitive data reaches untrusted users it is a bad practice, but this needn't be the case on Firebase just because it is serverless.
Firebase cloud functions can be triggered as a response to document saves (or authentications, or a plethora of other things) and run outside userspace, and are available for exactly this sort of work -- keeping the minutiae of upkeep away from the client.
That said, I agree that it's easy to make this kind of mistake with serverless development, but mostly due to lack of existing domain knowledge. It's trivially easy to make similar (or worse) mistakes without a serverless environment by untrained developers, too. It's just a matter of becoming familiar with the toolset, and because serverless tech is newer, fewer are as familiar with them as they are the old things (and there are fewer people to catch those mistakes when they see them.)
Not all databases support counting indexes. This is why counts we’re a bit issue at Parse: mongo didn’t support them and if the count is for an unindexed query, it could be a full table scan on a multi-tenant system. Just as bad, mongo as of 3.0 (last I worked with it heavily) did not ever yield during an index scan so counting large numbers on an indexed query could cause massive problems too.
I recommend the atomic increment operator for counts that both Parse and Firestore offer for this problem.
> Except for very simple use cases, serverless platforms in general encourage bad software design patterns.
> For example, in this case, if a regular database was used instead of Firebase, "counting the number of supporters" would have been done inside the database using a query.
I don't think this is connected to serverless achitecture. You have to write a database query either way. And it would be just as easy to count or retrieve entities one by one with traditional approach.
For example, in this case, if a regular database was used instead of Firebase, "counting the number of supporters" would have been done inside the database using a query. The worst that the developer could have done is forget to index to the relevant column; performance would have been sub-par but still orders of magnitude better than Firebase because the bulk of the data would not leave the database if there was a proper query language. With Firebase, when doing complex calculations, not only does the data have to leave the database, it often reaches end users; the calculations then happen on the front end and this is a huge problem in terms security, performance and even correctness (due to latency and the fact that other users may be making conflicting calculations simultaneously based on slightly outdated data).
Also, based on the article's description of the application, it sounds like it may have exposed potentially sensitive data (about supporters) to all users so it may have introduced a security vulnerability. I would not be surprised if this was the case.