Make Your Back End Layer as Thin as Possible

This article doesn&#x27;t use the word &quot;permission&quot; or &quot;validation&quot;, which is concerning.<p>The only mention of security hand waves away the idea of access control to a &quot;thin back end&quot;. That&#x27;s the whole point of this post! The details of this are critical!<p>&gt; 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.<p>Without mentioning how this has been solved elsewhere, this is an incredibly reckless piece of advice. For one, it&#x27;s nearly impossible to parse and check an arbitrary SQL query for malicious intent. Besides ensuring that queries that should read <i>only</i> read, you also need to make sure that queries aren&#x27;t designed to intentionally DoS your DB.<p>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?<p>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&#x27;t control what JS folks are running in the browser.<p>There&#x27;s a lot wrong with the ideas presented here.

I get the reasoning behind this, and I agree with some of that. But I don&#x27;t agree with this. For reasons:<p>1. You can&#x27;t trust the front end. Backends <i>must</i> 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&#x27;t do the thing), and the back end (to stop them from the doing the thing).<p>2. There will be multiple front ends. If all your business logic is in the front end, you&#x27;ll have to duplicate it into all of them. Where it will rapidly get out of synch and you&#x27;ll have different behaviours on different clients.<p>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.<p>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).<p>5. There are ways of writing database schemas that allow for rapid change. My favourite is adding a hstore &quot;metadata&quot; field that I can use to create &quot;temporary&quot; fields in the table for experimental features.<p>I&#x27;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.

I strongly disagree with the advice in this article. There are many reasons. I’ll name a few.<p>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.<p>If you do this, any business logic not captured in your backend has to be duplicated in each front end. Imagine needing to write and maintain the same business logic in a JavaScript framework, Java for Android, and Swift for your iOS app.<p>How do you make breaking DB changes if you take on this strategy of API design?<p>In most cases in my professional career, making a choice to have a thin RESTful API that corresponds closely to the DB structure has been a mistake that only time made clear. RPC-like APIs fared much better.<p>This advice may be good for a proof of concept, a prototype, or an early version which stands a good chance of getting rewritten. I would not recommend it for anyone wishing to build a lasting architecture.<p>Don’t take my word for it. Take a look at your favorite famous internet company and look at their API and try to deduce if they follow this advice or not.

Let&#x27;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.<p>Yet, this is what my backend does:<p>* make sure the user is allowed to move that particular card.<p>* update the database.<p>* add an entry to the board&#x27;s activity log.<p>* notify all connected clients listening to events from this board that a change occurred, so they can refresh the UI instantly.<p>* if some users asked to be notified about changes, generate notifications.<p>* if some of these users are offline but still want to be alerted, generate and queue some emails to send.<p>* add an entry in a raw text log for easy debugging.<p>* register the event in some kind of analytics storage for future stats.<p>* if the board is integrated with e.g. Slack, call Slack&#x27;s API.<p>* if some users registered webhooks through my API, trigger those.<p>I&#x27;m so glad my frontend engineers actually do not have to worry about how to do <i>any</i> of that.<p>Edit: format

Don&#x27;t do it! Not if your application is more than a toy.<p>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&#x27;t pass the smell test.

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.

Does the article mention business logic?<p>Even at MVP stage, many backends do quite a bit more than CRUD.<p>This is why I wouldn&#x27;t pick e.g. <a href="https:&#x2F;&#x2F;github.com&#x2F;PostgREST&#x2F;postgrest" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;PostgREST&#x2F;postgrest</a> even when it&#x27;s a perfectly fine (and probably well thought-out) project.

As a former pentester, this makes me happy inside.<p>As a DevSecOps Engineer, I field requests like this from frontend developers all the time. The answer is always no.<p>In this case it would be &quot;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...&quot;

Just don&#x27;t. This is not good advise unless for a toy app. The only time I&#x27;ve seen a direct DB access API useful and even remotely a good idea is to give another internal application or service access - for reporting or metrics data. Definately not for your public facing client apps. - The database may contain a lot more info than the client apps need, you are sending back more data than is needed, which costs money. - Apparently you have no business logic to transform that raw database data? - If you have more than one client, you are likely to end up duplicating some kind of business logic in each client (say a native iOS app, native Android app, web). - Security? I&#x27;m not even gonna start... This whole article smells of someone who has not had a lot of real-world experience. Large application database a full of data that have no place being handed over to a app developer without any context or documentation of the database. It is much better to give back exactly what is needed for a particular view and no more. If you neeed more or differnt data later, you version the API and do a rolling deploy after your clients have been updated.

<i>&gt; You can bypass this whole inefficiency by making the backend a pass-through. That gives you one fewer thing to worry about, which any engineer will welcome.</i><p>Um, yeah, and now you have front end security issues, since all the expressive power that you have just given to your front end engineers is also available to any damned fool who can fire up a browser console.<p>I strongly agree that you should make the distance between the front end and the data as thin as possible, but this article comes at that from the front-end developer perspective.<p>There is another option: make the front end as thin as possible. Eliminate the huge front end framework and go with something closer to the HTML.<p>This keeps the expressiveness on the server side, which is a trusted computing environment, rather than exposing it on the client side, in an untrusted computing environment, where security concerns become much more complicated.

&gt; In the three-tier frontend-backend-database architecture, try to have as thin a middle layer as possible. Or even eliminate the backend layer altogether by directly exposing the database to the frontend.<p>Wat...<p>This article reads like a jumbled mess of ideas. But, the above is a total wat...<p>And it also assumes that your backend doesn&#x27;t have to consume and tie together several resources or that you need a caching layer and so many other naive assumptions - and I&#x27;m not even addressing the security implications.<p>Take this article with a heavy cup of salt.<p>To me it just reads like something someone would write because they want full control and does&#x27;t like working with and&#x2F;or being dependant on other people&#x2F;teams.

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 &quot;back end&quot; even is.<p>Fast forward almost a decade, and this approach has generated a huge headache. The database is an incomprehensible mess, there&#x27;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&#x27;t really work out at all - because who wants to read a decade&#x27;s worth of spaghetti code. I&#x27;ve been working on a way to fix this, but it takes a lot of time and effort. Also management still doesn&#x27;t understand the concept of &quot;overwhelming technical debt&quot;.<p>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.<p>This article is basically a set of instructions to get to where we are. It&#x27;s like saying that traffic lights are unnecessary because if you just floor it through an intersection, you&#x27;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.

The thinner your backend, the thicker your frontend. I much prefer writing in backend languages (e.g. python) than in frontend languages (e.g. javascript).<p>And as someone else pointed out, you can&#x27;t enforce security on the frontend.<p>The line is getting blurrier between front and back these days with new frameworks, e.g. React. Personally, I&#x27;m not ready to move away from mature languages generating HTML on the backend, even though it means giving up some interactivity on the frontend.

The main issue seems to be improper communication and process between the frontend&#x2F;backend devs. The informal solution is to agree on something like a swagger doc. The proposed solution is to expose all the fields. I&#x27;d be careful on this as unwanted fields could be unecessarily exposed. A workaround addition to this is to make a blacklist filter of fields to not expose before sending and send everything else as a passthrough.

Best performing query is the query that&#x27;s not executed.<p>You have discussed multiple ideas that fit for different use cases.<p>SQL is for transactional type of workload that&#x27;s where it&#x27;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&#x27;t be a columnar DBs.<p>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).<p>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&#x27;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.<p>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.<p>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.<p>Don&#x27;t do this, &quot;Do a SELECT *, iterate over all the columns, and copy them to the JSON that will be sent back to the frontend.&quot;<p>As the data grows you will end up thrashing memory and unnecessary network data transfers.<p>Basically do work where there is lots of memory.

The conclusion is a bit spotty, but there are some good points in there.<p>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&#x27;t require in-depth specialist knowledge, and you can usually collapse those down into a single role.<p>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.

I&#x27;m seeing a lot of criticism along the lines of &quot;the trade-offs are not worth it in &lt;context&gt;&quot; or &quot;the article didn&#x27;t address every detail&quot;. Well, yeah -- no advice is universal, and this blog post isn&#x27;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.<p>FWIW, Reviewable (<a href="https:&#x2F;&#x2F;reviewable.io" rel="nofollow">https:&#x2F;&#x2F;reviewable.io</a>) follows roughly this design and, after 6 years, it&#x27;s still a fine system to develop in. It runs on top of Firebase RTDB which takes care of the security rules; if anything, I feel better having all the security rules articulated in one central location (the schema) rather than spread throughout the backend. Communication between client and backend also flows through the database (with very few exceptions), which lets the backend get away with an easy to scale queue-based design.<p>There are downsides, of course. As many posters alluded to, changing the schema gets tricky. It basically must remain backwards compatible for at least a few releases so as not to inconvenience the users, and some kinds of changes are just not feasible. And yeah, how the client wants to fetch data does affect the schema as well, though in practice I haven&#x27;t found the impact to be too bad. Also, Reviewable has only one (browser) client, so I don&#x27;t need to worry about duplicating logic -- I probably wouldn&#x27;t pick this architecture if multiple clients were a requirement. Putting much of the business logic in a client-side model layer integrated with the database structure actually works out really nicely, though I still struggle with how to efficiently share some of the logic with server-side code.<p>Overall, I&#x27;m satisfied with how things worked out and would definitely consider using a similar architecture again in the right circumstances. The article is right on the money that if you&#x27;re just getting started on your MVP it&#x27;s worth thinking about a thin- or no-backend approach.

Sounds like a huge security risk waiting to happen.

Absolutely terrible advice!

I think the problem this is trying to solve is a poorly defined interface from the backend. It&#x27;s not to everyone&#x27;s taste but openapi&#x2F;swagger solves that problem. The hypothetical conversation around the missing property is resolved simply by specifying what the API returns - if it&#x27;s not in the spec then it&#x27;s not going to come back.<p>Alternatively, it speaks of a dysfunctional dynamic between front-end and back-end developers, but no amount of technical solution fixes that.

I&#x27;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&#x27;re dreaming of, though hooking a GraphQL backend directly to the database would be a tremendously terrible idea.

No thank you.

&gt; That goes for a lot of things — you don’t need to have automated tests as a general practice.<p>Man, this article is just handing out terrible advice left right and centre