4 ms·
"In the olden days, being a backend developer meant that you wrote a long list of functions that mapped to HTTP requests. A post to /item/14 was turned into cre
by nbevans 10y ago
"In the olden days, being a backend developer meant that you wrote a long list of functions that mapped to HTTP requests. A post to /item/14 was turned into createItem( id ) — and we liked it that way."
That's not true at all. A good place to stop reading.
- asimuvPR 10y agoThat part had me read further multiple times. It was hard to understand the point behind the post. Its an obvious advertisement for a product but it could have at least provided a better explanation of why a simple data store may prove to be more effective for applications that are CRUD front ends. Instead, the post tries to sell the benefits of a data store that can be expanded with backend services. Which is funny given the title.
- manyxcxi 10y agoWell they just glossed over the asynchronous processes that had to be kicked off, the analytics that had to be recorded, the instrumentation that was plumbed in, the validity and safety of the request prior to doing anything, the caching layers that need updating, the websocket client updates, and the design of the object model in the first place. But we knew that's what the author meant. /s
- pjmlp 10y agoI agree with the sentiment. As a generalist developer I have worked at all levels of the stack on front-end and back-end, depending on the project and never had a backend stack being "a long list of functions that mapped to HTTP requests". Maybe in the SV world of SPA applications it is like that, but backend is so much richer than that, specially in distributed computing scenarios.