41–50 of 64 posts
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…
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…
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…
You have multiple different clients querying the same database?
It's a pretty impressive house of cards.
Refactoring (or rather re-designing) this sort of thing while still churning out new features is tricky to say the least.
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…
> 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 different behaviours on different clients.
No, because a) not every startup starts on multiple platforms b) you can always put common behavior into a piece that's reused. This can be a library linked in to multiple frontends, or a backend API. The post says your backend should be as thin AS POSSIBLE. It doesn't say you shouldn't have a backend at all costs, even if that means duplicating code.
> Forcing your UI to use the same entities as your database.
Nothing prevents you from mapping the entities to different ones for your frontend, in cases where you need that.
> The advice in the article strikes me as dangerously sensible-sounding while being mostly wrong.
I don't think you even understood the advice in the first place, as I can see from your misconceptions above.
Earlier quoted context omitted.
While I largely share your broader concerns, > ensuring that queries that should read only read seems to be the purview of the DBMS, setting appropriate account permissions. The bit you quoted said "a database user account that has only read access" .
On MySQL, you can run SLEEP() or BENCHMARK() as a read-only user to your heart's content. You cannot restrict access to these functions, and letting the wide internets play with them will bring your server to its knees by clogging up all connections and hogging up its CPUs.
Earlier quoted context omitted.
While I largely share your broader concerns, > ensuring that queries that should read only read seems to be the purview of the DBMS, setting appropriate account permissions. The bit you quoted said "a database user account that has only read access" .
This assumes you only deal with non-sensitive data (e.g. user profiles). Never mind that, how do you prevent denial of service attacks? I can run any allowed query on that database. Including 50 times cross join of the table I can read, sorted by random.
Not really. You can do row or column level permissions. Details very much depend on your DBMS.
> Never mind that, how do you prevent denial of service attacks?
I have no real answer, and I never suggested that I would. Denial of service attacks (deliberate or accidental) are one piece of the "broader concerns" that I very much share.
In theory, a sufficiently advanced DBMS might be able to assign users quotas, and if your users are stable that may be sufficient for some use cases, but I am skeptical.
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…
> This article doesn't use the word "permission" or "validation"
The article talks about it multiple times: using a database user account with limited privledges, exposing some tables but not others, exposing read but not write access, giving users access only to data they own.
> it's nearly impossible to parse and check an arbitrary SQL query for malicious intent
Which is why the article doesn't propose trying to parse and check queries for malicious intent.
> it now passes the responsibility of query performance to the FE engineer. Are appropriate indexes in place? Does the query make inappropriate JOINs?
No, in the proposal, we have backend engineer(s) to advise and assist frontend engineers. Having appropriate indices and JOINs doesn't mean you have a layer that doesn't add business value. And when it does add value, write it!
> 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.
I don't know if I understood you, but you can just force a refresh in the browser.
> you also need to make sure that queries aren't designed to intentionally DoS your DB.
That's a valid point I didn't think of.
> There's a lot wrong with the ideas presented here.
It's hard to take your criticism seriously when many of your reactions are a result of your own misunderstanding of the proposal.
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…
> 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 POSSIBLE, not to not have a backend layer at all costs even if it means duplicating code.
> How do you make breaking DB changes if you take on this strategy of API design?
You change the frontend!
> This advice may be good for a proof of concept, a prototype, or an early version which stands a good chance of getting rewritten.
Which is why the blog post begins by saying, "Say you've started a startup today"
> I would not recommend it for anyone wishing to build a lasting architecture.
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.
> 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.
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.
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…
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".