21–30 of 64 posts
Alternatively, it speaks of a dysfunctional dynamic between front-end and back-end developers, but no amount of technical solution fixes that.
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.
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.
Solution: Don't use MySQL
> 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. Wat... This article reads like a jumbled mess of ideas. But, the above is a total wat... And it also assumes that your backend doesn't have to consume and tie together several resources or that you need a caching l…
FWIW, Reviewable (https://reviewable.io) follows roughly this design and, after 6 years, it'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.
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't found the impact to be too bad. Also, Reviewable has only one (browser) client, so I don't need to worry about duplicating logic -- I probably wouldn'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.
Overall, I'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're just getting started on your MVP it's worth thinking about a thin- or no-backend approach.
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 activity log.
* notify all connected clients listening to events from this board that a change occurred, so they can refresh the UI instantly.
* if some users asked to be notified about changes, generate notifications.
* if some of these users are offline but still want to be alerted, generate and queue some emails to send.
* add an entry in a raw text log for easy debugging.
* register the event in some kind of analytics storage for future stats.
* if the board is integrated with e.g. Slack, call Slack's API.
* if some users registered webhooks through my API, trigger those.
I'm so glad my frontend engineers actually do not have to worry about how to do any of that.
Edit: format
Earlier quoted context omitted.
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.
Solution: Don't use MySQL
Does the article mention business logic? Even at MVP stage, many backends do quite a bit more than CRUD. This is why I wouldn't pick e.g. https://github.com/PostgREST/postgrest even when it's a perfectly fine (and probably well thought-out) project.
Business logic should not happen at API boundaries (regardless of what kinds of technologies or transport those interface boundaries are facilitating). Interfaces should be a validation and translation layer that receive incoming data, hand off to business logic, receive outgoing data and perform whatever translation and serialization required to satisfy the return/response interface. Business logic should be complet…
Earlier quoted context omitted.
Business logic should not happen at API boundaries (regardless of what kinds of technologies or transport those interface boundaries are facilitating). Interfaces should be a validation and translation layer that receive incoming data, hand off to business logic, receive outgoing data and perform whatever translation and serialization required to satisfy the return/response interface. Business logic should be complet…
While I don't disagree with your remarks, I'm curious whom you're educating here and why; parent post makes no statements about controller/view/service/repository responsibilities, only that something very often needs to exist between frontend and backend to mediate, filter, enrich, and so on.