[jpatte]

Let's say my startup makes a product featuring some sort of kanban-like board. The user moves a card from one column to the other. According to this article, the frontend might just need to perform an UPDATE on the right table from the database and that would be it.

Yet, this is what my backend does:

* make sure the user is allowed to move that particular card.

* update the database.

* add an entry to the board's activity log.

* notify all connected clients listening to events from this board that a change occurred, so they can refresh the UI instantly.

* if some users asked to be notified about changes, generate notifications.

* if some of these users are offline but still want to be alerted, generate and queue some emails to send.

* add an entry in a raw text log for easy debugging.

* register the event in some kind of analytics storage for future stats.

* if the board is integrated with e.g. Slack, call Slack's API.

* if some users registered webhooks through my API, trigger those.

I'm so glad my frontend engineers actually do not have to worry about how to do any of that.

Edit: format

[kartickv]

In this case, I wouldn't disagree with you if you were to do it on the backend.

The article says, "build a backend API when it has something to do, not as a pass through to your database."

It doesn't say "never write any backend code".

[jpatte]

The article's subtitle literally says "The best backend is no backend at all". The article gives the impression you have no idea what a backend is supposed to do, except expose some data.

[tdevito]

All very easy to implement with no backend using Firebase.