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