Make Your Back End Layer as Thin as Possible • Hacker News Board

Re: Make Your Back End Layer as Thin as Possible

#31

Post by pavel_lishin » Sun, Nov 15, 2020, 11:02 PM UTC

eyelidlessness wrote: post #16

vemv wrote: post #10

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.

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 complet…

> 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.)

Re: Make Your Back End Layer as Thin as Possible

#32

Post by pavel_lishin » Sun, Nov 15, 2020, 11:02 PM UTC

I'm not a big fan of GraphQL, but I think that the author would benefit from reading about and using it for awhile. It comes closest to the ideal implementation they're dreaming of, though hooking a GraphQL backend directly to the database would be a tremendously terrible idea.

Re: Make Your Back End Layer as Thin as Possible

#33

Post by hcrean » Sun, Nov 15, 2020, 11:04 PM UTC

As a former pentester, this makes me happy inside.

As a DevSecOps Engineer, I field requests like this from frontend developers all the time. The answer is always no.

In this case it would be "I am sorry that you are not happy with inter-team planning and communication; please raise this with the appropriate project owner at the next scrum meeting. Sadly poor communication can not be allowed to drive well established systems planning and architecture best practices..."

Re: Make Your Back End Layer as Thin as Possible

#34

Post by tdevito » Sun, Nov 15, 2020, 11:22 PM UTC

bastawhiz wrote: post #7

This article doesn't use the word "permission" or "validation", which is concerning. The only mention of security hand waves away the idea of access control to a "thin back end". That's the whole point of this post! The details of this are critical! > you can define an API that takes an SQL query from the client, runs it, and returns the results. This query can be run under a database user account that has only read…

Firebase was recommended in the post, which has built in security rules and auth.

Re: Make Your Back End Layer as Thin as Possible

#35

Post by tdevito » Sun, Nov 15, 2020, 11:26 PM UTC

jpatte wrote: post #26

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 act…

All very easy to implement with no backend using Firebase.

Re: Make Your Back End Layer as Thin as Possible

#36

Post by politelemon » Sun, Nov 15, 2020, 11:27 PM UTC

koliber wrote: post #11

I strongly disagree with the advice in this article. There are many reasons. I’ll name a few. Your DB is likely to contain internal state that has no business being sent to the client. Over time applications change and fields can change meaning, become deprecated, or become dependent on other fields through business logic. If you do this, any business logic not captured in your backend has to be duplicated in each fr…

Op, please listen to the advice given here. If your blog post is a reflection of your startup's production stack, I would be very concerned.

Re: Make Your Back End Layer as Thin as Possible

#37

Post by pavel_lishin » Sun, Nov 15, 2020, 11:31 PM UTC

tdevito wrote: post #34

bastawhiz wrote: post #7

This article doesn't use the word "permission" or "validation", which is concerning. The only mention of security hand waves away the idea of access control to a "thin back end". That's the whole point of this post! The details of this are critical! > you can define an API that takes an SQL query from the client, runs it, and returns the results. This query can be run under a database user account that has only read…

Firebase was recommended in the post, which has built in security rules and auth.

Then the author should really search-and-replace every instance of "database" with "Firebase"; their advice doesn't work very well otherwise.

Re: Make Your Back End Layer as Thin as Possible

#38

Post by eyelidlessness » Sun, Nov 15, 2020, 11:59 PM UTC

pavel_lishin wrote: post #31

eyelidlessness wrote: post #16

Earlier quoted context omitted.

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 complet…

> 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.

Re: Make Your Back End Layer as Thin as Possible

#39

Post by Netcob » Mon, Nov 16, 2020, 12:13 AM UTC

The company I work for did this, basically because the people working there had to crank out features as quickly as possible and had no idea what a "back end" even is.

Fast forward almost a decade, and this approach has generated a huge headache. The database is an incomprehensible mess, there's a whole class of features we cannot implement because of this (lack of) architecture, business logic is all over the place (with a million ways to do the exact same thing), mostly in the clients, performance is bad because every client is doing all sorts of queries all the time, and training a new developer either takes months or doesn't really work out at all - because who wants to read a decade's worth of spaghetti code. I've been working on a way to fix this, but it takes a lot of time and effort. Also management still doesn't understand the concept of "overwhelming technical debt".

The only reason this has even been hanging by a thread for so long is that we only make software where the back-end and the clients are run on-premise in a separate network. Otherwise it would be a security nightmare as well.

This article is basically a set of instructions to get to where we are. It's like saying that traffic lights are unnecessary because if you just floor it through an intersection, you'll get to your destination much faster. And you know what, it might just work the first few times. Until you find out why these things exist in the first place.

Re: Make Your Back End Layer as Thin as Possible

#40

Post by partyboat1586 » Mon, Nov 16, 2020, 12:19 AM UTC

koliber wrote: post #11

I strongly disagree with the advice in this article. There are many reasons. I’ll name a few. Your DB is likely to contain internal state that has no business being sent to the client. Over time applications change and fields can change meaning, become deprecated, or become dependent on other fields through business logic. If you do this, any business logic not captured in your backend has to be duplicated in each fr…

If you use React Native, React and a shared Redux layer you can share all this business logic between iOS, Android and Web. If you make breaking DB changes you still have the REST layer to buffer them. If REST won't cover your breaking changes with data transforms because you are deleting whole tables and restructuring then it's time to refactor the front end as well anyway. I disagree with the front end sending SQL directly but a thin REST layer with a little validation seems ideal to me.