Make Your Back End Layer as Thin as Possible

While I largely share your broader concerns,

> ensuring that queries that should read only read

seems to be the purview of the DBMS, setting appropriate account permissions. The bit you quoted said "a database user account that has only read access".

This assumes you only deal with non-sensitive data (e.g. user profiles).

Never mind that, how do you prevent denial of service attacks? I can run any allowed query on that database. Including 50 times cross join of the table I can read, sorted by random.

Business logic should not happen at API boundaries (regardless of what kinds of technologies or transport those interface boundaries are facilitating). Interfaces should be a validation and translation layer that receive incoming data, hand off to business logic, receive outgoing data and perform whatever translation and serialization required to satisfy the return/response interface. Business logic should be completely isolated from that responsibility, and ideally transport-agnostic.

In a traditional “MVC” style architecture this would be described as “thin controller”. But that kind of architecture often tightly couples other things that shouldn’t be, because they hide other transport/interface boundaries.

The way I approach this is pretty simple:

1. Interfaces between user input and “programs” of any kind are used for validation, sanitization, deserialization and interface translation. Only. No state changes can occur here. In the language of the article, this is the “thin backend”.

2. Any runtime business logic, using any technology for that runtime, clearly defines its input and output types. This layer is allowed to make local state change as appropriate, but any external side effects are forbidden.

3. If the layer described in #2 needs to communicate with an outside network, system, storage or service layer, recurse to #1. Contracts between these boundaries are only that and imply no implementation details.

4. If you implement #3 in the service providing #2, those responsibilities are explicitly separated.

5. Do business logic. Return data consistent with the business logic’s contract.

6. Rewrap the onion and eventually serialize the result for the outside client according to that layer’s expectation, at whatever interface boundary you’re at.

> That goes for a lot of things — you don’t need to have automated tests as a general practice.

Man, this article is just handing out terrible advice left right and centre

> In the three-tier frontend-backend-database architecture, try to have as thin a middle layer as possible. Or even eliminate the backend layer altogether by directly exposing the database to the frontend.

Wat...

This article reads like a jumbled mess of ideas. But, the above is a total wat...

And it also assumes that your backend doesn't have to consume and tie together several resources or that you need a caching layer and so many other naive assumptions - and I'm not even addressing the security implications.

Take this article with a heavy cup of salt.

To me it just reads like something someone would write because they want full control and does't like working with and/or being dependant on other people/teams.