Hacker News Reader

Comment by vemv | Hacker News Reader

Does the article mention business logic?

Even at MVP stage, many backends do quite a bit more than CRUD.

This is why I wouldn't pick e.g. https://github.com/PostgREST/postgrest even when it's a perfectly fine (and probably well thought-out) project.

View on HN

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.

While I don't disagree with your remarks, I'm curious whom you're educating here and why; parent post makes no statements about controller/view/service/repository responsibilities, only that something very often needs to exist between frontend and backend to mediate, filter, enrich, and so on.

My response was that the implied place for business logic in the article (the layer behind the “thin backend”) is pretty clear, and that the response above mine seemed to suggest that the “somewhere” a business logic belongs is the “backend”, which at least using the article’s definitions and delineations that’s the worst place to put it.

> Business logic should not happen at API boundaries

You're right, but the original post seems to believe there are only three layers: frontend, API, database. They haven't left any place for business logic at all, except maybe in the way the front-end would write the SQL queries. (Which I think is a terrible approach.)

You’re right too. And ultimately it moves the business logic to the frontend, and likely causes that layer to accrue the separations of concern most of us associate with “backend”. It has to live somewhere.

Author here.

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

Reply on news.ycombinator.com