Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make Your Back End Layer as Thin as Possible

kartick.substack.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Make Your Back End Layer as Thin as Possible

#51

Post by kartickv »

piotrkaminski wrote: post #25

I'm seeing a lot of criticism along the lines of "the trade-offs are not worth it in " or "the article didn't address every detail". Well, yeah -- no advice is universal, and this blog post isn't a 500 page reference book. I think it would be more productive to help the author articulate the trade-offs and forces pushing for and against this architecture. FWIW, Reviewable ( https://reviewable.io ) follows roughly thi…

Author here.

It's good to see a considered response, rather than the typical knee-jerk reactions common on Internet forums including HN.

Re: Make Your Back End Layer as Thin as Possible

#52

Post by kartickv »

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.

Author here.

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

Re: Make Your Back End Layer as Thin as Possible

#53

Post by kartickv »

jacobsimon wrote: post #5

This is generally ok advice but it leaves out an important detail about making backwards compatible changes. If your backend doesn’t do anything, every change to your database will break your client unless they are updated simultaneously every time (impossible for mobile apps) or your client is aware of every backend change (very complex). Not to mention there is some data you simply don’t want to expose to a client…

Author here.

> every change to your database will break your client unless they are updated simultaneously every time (impossible for mobile apps)

You can just put up a UI forcing the user to update. Which is perfectly fine since you won't be making backward-incompatible changes to your database every month. Adding a new column doesn't break existing clients.

> or your client is aware of every backend change (very complex)

You can just put in a build date in your frontend and compare it against the date a breaking change was made. If it's <, refresh.

Re: Make Your Back End Layer as Thin as Possible

#54

Post by kartickv »

Netcob wrote: post #39

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…

Author here.

> Fast forward almost a decade

If your system lasted a decade, that's a success, and any startup that just started would love to be in your shoes.

> management still doesn't understand the concept of "overwhelming technical debt".

That's a problem with your company, not with the suggestion in my post of adding in layers of abstraction when needed rather than ahead of time.

Re: Make Your Back End Layer as Thin as Possible

#55

Post by tcbasche »

kartickv wrote: post #53
jacobsimon wrote: post #5

This is generally ok advice but it leaves out an important detail about making backwards compatible changes. If your backend doesn’t do anything, every change to your database will break your client unless they are updated simultaneously every time (impossible for mobile apps) or your client is aware of every backend change (very complex). Not to mention there is some data you simply don’t want to expose to a client…

Author here. > every change to your database will break your client unless they are updated simultaneously every time (impossible for mobile apps) You can just put up a UI forcing the user to update. Which is perfectly fine since you won't be making backward-incompatible changes to your database every month. Adding a new column doesn't break existing clients. > or your client is aware of every backend change (very co…

> You can just put up a UI forcing the user to update

sounds very user-friendly

Re: Make Your Back End Layer as Thin as Possible

#56

Post by bastawhiz »

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.

The article literally says "Instead, you can define an API that takes an SQL query from the client, runs it, and returns the results," so...

Re: Make Your Back End Layer as Thin as Possible

#57

Post by onei »

kartickv wrote: post #54
Netcob wrote: post #39

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…

Author here. > Fast forward almost a decade If your system lasted a decade, that's a success, and any startup that just started would love to be in your shoes. > management still doesn't understand the concept of "overwhelming technical debt". That's a problem with your company, not with the suggestion in my post of adding in layers of abstraction when needed rather than ahead of time.

I get that you've disagreed with almost every point telling you this is a bad idea, but I think the point is particularly pertinent.

They tried this system, and then realised they painted themselves into a corner. Businesses wants features they can sell to customers, and sometimes fixing technical debt is a luxury. Especially when technical debt hidden to customers.

Adding layers of abstraction when needed might sound like great advice to a startup that needs money ASAP. But down the line when requirements change, maybe those layers of abstraction cost too much time to implement, especially if you're firefighting a dozen other poor choices.

Re: Make Your Back End Layer as Thin as Possible

#58

Post by onei »

kartickv wrote: post #45
marcus_holmes wrote: post #4

I get the reasoning behind this, and I agree with some of that. But I don't agree with this. For reasons: 1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious. Validations must be duplicated in both the UI (to show people that they can't do the thing), and the back end (to stop them from the doing the thing). 2. There will be multiple front ends. If all y…

Author here: > 1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious. This is already taken care of in the proposal, by permitting clients to access only data they own. > 2. There will be multiple front ends. If all your business logic is in the front end, you'll have to duplicate it into all of them. Where it will rapidly get out of synch and you'll have…

> This is already taken care of in the proposal, by permitting clients to access only data they own.

I'm curious how this works. In a database that stores something like an address, how do you prevent someone from slightly changing the query to give them someone else's address stored in the same table. I've heard of giving per-table access, but never per-row.

Re: Make Your Back End Layer as Thin as Possible

#59

Post by marcus_holmes »

kartickv wrote: post #45
marcus_holmes wrote: post #4

I get the reasoning behind this, and I agree with some of that. But I don't agree with this. For reasons: 1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious. Validations must be duplicated in both the UI (to show people that they can't do the thing), and the back end (to stop them from the doing the thing). 2. There will be multiple front ends. If all y…

Author here: > 1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious. This is already taken care of in the proposal, by permitting clients to access only data they own. > 2. There will be multiple front ends. If all your business logic is in the front end, you'll have to duplicate it into all of them. Where it will rapidly get out of synch and you'll have…

> This is already taken care of in the proposal, by permitting clients to access only data they own.

But you don't propose any method for that apart from hand-waving about "database user accounts with read access", which is largely irrelevant unless you're proposing to give every one of your customers a database account and do row-level database security.

Let's talk about a concrete example: A call arrives at the back end to change the user's name to "dickwad".

In a conventional backend, you'd check the session, work out which user that session was logged in as, check that it's the same account as the name that's going to change, and maybe then run a profanity filter, or not.

How would you build your minimal backend to do that? Remember, you don't actually know that this call has come from the front end, it could be sent from curl.

> Nothing prevents you from mapping the entities to different ones for your frontend, in cases where you need that.

True, but that's not mentioned at all in your article, and defeats half the point of it - the front end engineer still has to worry about what the database needs and how to do that mapping when it changes.

> I don't think you even understood the advice in the first place, as I can see from your misconceptions above.

What misconceptions? I understood you (almost) perfectly. It's a well-written article. Still wrong, though.

Re: Make Your Back End Layer as Thin as Possible

#60

Post by jpatte »

kartickv wrote: post #50
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…

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

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.
Post reply on HN