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

Re: Make Your Back End Layer as Thin as Possible

#61

Post by Netcob » Mon, Nov 16, 2020, 11:38 AM UTC

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'm not saying they weren't successful. As someone who tends to over-engineer things, I do admire their ability to get a product out quickly - I think for a startup that was probably the right decision!

But that's what I've been missing from your article - more on the distinction between the approaches, and the drawbacks of having a thin back-end layer as the product / company is growing. In the beginning I thought you were talking about how to make your startup more efficient and flexible - basically consciously building some technical debt, having weighed your options.

But if that's not the idea - personally I don't know how to scale with this approach, neither technologically nor in terms of team structure. The thin back end layer could work though if you have a lot of small products that are independent of each other - developed by small teams that can afford to act like early startups. Maybe that's what you meant, but I didn't really get that from the article.

Re: Make Your Back End Layer as Thin as Possible

#62

Post by koliber » Mon, Nov 16, 2020, 1:13 PM UTC

kartickv wrote: post #49

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…

Author here. > Your DB is likely to contain internal state that has no business being sent to the client. Which is why not all tables need to be sent to the client. The post gives an example of exposing the friends table to the client but not others. > If you do this, any business logic not captured in your backend has to be duplicated in each front end. No, the post says to make your backend layer as thin AS POSSIBL…

> Which is why not all tables need to be sent to the client. The post gives an example of exposing the friends table to the client but not others.

What if the "is_active" flag takes on more nuanced meaning over time, as you add "client_activation_status", and over time expand that meaning. All frontend clients of the API need to be aware of such low-level changes. An API acts as an insulation layer.

> No, the post says to make your backend layer as thin AS POSSIBLE, not to not have a backend layer at all costs even if it means duplicating code.

At one point the post says to get rid of it altogether and use SQL, making the architecture 2-layer. If you do have a backend layer, and it does have business logic, that business logic will stand between your DB and the client. This logic will vary in thickness, but in a mature application will be substantial.

> You change the frontend!

How do you force a synchronized iOS app update to all the people who have your app installed?

> Which is why the blog post begins by saying, "Say you've started a startup today"

Fair point. Still, it is not something I would do except in throwaway prototypes or proof-of-concepts.

> In a startup, I wouldn't recommend over-designing on day 1, because that's a good way of not delivering enough business value fast enough and so going bust.

Agreed on this advice. And you need to ask yourself how you will gradually adapt the software you've built so that it can change with the needs, risk profile of your clients, and growth of your company. An approach to API design you describe is fundamental, and it would be difficult to adapt it without scratching it altogether and starting afresh with v2.

> As the blog post says, you shouldn't cargo-cult Google or Amazon. You don't operate at their scale, you don't have as much traffic, you don't have as many teams, and so on. You should what makes sense for you given your company's maturity and where in the product lifecycle you are.

Agree about not cargo-culting. Agree about adjusting approach to company maturity. My experience has showed me that the approach you suggest has too many disadvantages for building any production software.

I wish you best of luck and hope that at the very least I and others on this thread were able to offer another perspective.

Re: Make Your Back End Layer as Thin as Possible

#63

Post by bionhoward » Mon, Nov 16, 2020, 7:40 PM UTC

onei wrote: post #58

kartickv wrote: post #45

Earlier quoted context omitted.

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.

alter table addresses enable row level security;

However this article is insane because of the security nightmare of trusting all incoming queries

Re: Make Your Back End Layer as Thin as Possible

#64

Post by bobbydreamer » Tue, Nov 17, 2020, 7:20 PM UTC

Best performing query is the query that's not executed.

You have discussed multiple ideas that fit for different use cases.

SQL is for transactional type of workload that's where it's best so data returned need to be less. In first part you are talking about not making any changes to the program when a new column is added. Now a days we are talking about column masking. So querying all columns is a no. Otherwise there needn't be a columnar DBs.

Seeing a generalized rest APIs(selecting many Columns than required) are also no but architects are recommending it nowadays. Here unnecessarily you are retreiving lots of data than required and filtering in frontend after retrieval (you have already done the heavy duty work).

Firebase is a special case, UX designer basically dictates the database schema rather than architects or dba. When you hit the node in firebase you retreive all the data in that node. Here there has to be duplication of data as it's designed based on UX no foreign keys or checks. To be efficient if UX changes you will have to change schema. If you are not changing UX but just adding more info or taking out things you can easily add more fields, no disruption.

What you do with firebase cant be doing with RDBMS, adding a column needs to be planned and also theres boyce codd normal form to avoid duplication and repeated groups. Again there is a reason why they had to build firestore when they have firebase.

Also one api call or three api calls again that depends on use case and performance testing. Three separate calls to get data from three separate tables or join table query again it depends in use case.

Don't do this, "Do a SELECT *, iterate over all the columns, and copy them to the JSON that will be sent back to the frontend."

As the data grows you will end up thrashing memory and unnecessary network data transfers.

Basically do work where there is lots of memory.