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

1–10 of 64 posts

Re: Make Your Back End Layer as Thin as Possible

#4

Post by marcus_holmes »

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 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 different behaviours on different clients.

3. The entities that make the most sense for storing your data into a database are not the same entities that make the most sense for using in a UI. Forcing your UI to use the same entities as your database will mean more work for both, and often ends up influencing the database design badly.

4. There are ways of writing APIs that allow for rapid change. Uncoupling the storage entities from the display entities is a key step, so you can change things in the database without affecting the front end (and vice versa).

5. There are ways of writing database schemas that allow for rapid change. My favourite is adding a hstore "metadata" field that I can use to create "temporary" fields in the table for experimental features.

I've written a few back ends, and the advice in the article strikes me as dangerously sensible-sounding while being mostly wrong. I can see a newbie product manager buying into this completely and making a huge mess.

Re: Make Your Back End Layer as Thin as Possible

#5

Post by jacobsimon »

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 in most situations, like user emails or hashed passwords.

Re: Make Your Back End Layer as Thin as Possible

#6

Post by sk5t »

Don't do it! Not if your application is more than a toy.

I get the allure of this kind of approach, but the costs in usability and defense against pathological queries (given nontrivial data volumes) are way too heavy to bear for the superficial convenience. And the justifications related to the sorts of problems avoided don't pass the smell test.

Re: Make Your Back End Layer as Thin as Possible

#7

Post by bastawhiz »

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 access, that too only to the friends table. This can accommodate unforeseen uses, like getting the number of friends rather than the actual list. Or if there’s a search box where the user can filter his friends, you can do a LIKE query. Or you can limit the number of friends returned to how many will be displayed in the UI.

Without mentioning how this has been solved elsewhere, this is an incredibly reckless piece of advice. For one, it's nearly impossible to parse and check an arbitrary SQL query for malicious intent. Besides ensuring that queries that should read only read, you also need to make sure that queries aren't designed to intentionally DoS your DB.

And moreover, it now passes the responsibility of query performance to the FE engineer. Are appropriate indexes in place? Does the query make inappropriate JOINs?

And on top of all of that, schema changes now mean that you need to update your front end code. This means guaranteed hard downtime, because you can't control what JS folks are running in the browser.

There's a lot wrong with the ideas presented here.

Re: Make Your Back End Layer as Thin as Possible

#9

Post by underwater »

The conclusion is a bit spotty, but there are some good points in there.

If you have dedicated backend developers and front-end developers — or worse, separate teams — then each and every change becomes painful. Writing bog standard UI and backend code shouldn't require in-depth specialist knowledge, and you can usually collapse those down into a single role.

I also agree that the frontend requirements should drive the shape of the API. If you have a backend team they tend to picture an idealized consumer of their API. They stress over whether the API follows RESTful principles and how to model things out correctly, and version breaking changes so their consumers can have their own update cycle. But when you step back and realise that the API has one, or maybe two, consumers. And it turns out writing some weird, esoteric, heavily coupled endpoint for a specific use case is not so horrible.

Post reply on HN