8 ms·
> Imagine if you could just send it the whole “page” worth of JSON. Make an endpoint for /page/a and render the whole JSON for /page/a there. Do this for every
by Y-bar 3y ago
> Imagine if you could just send it the whole “page” worth of JSON. Make an endpoint for /page/a and render the whole JSON for /page/a there. Do this for every page. Don’t force your front-end developers to send a bunch of individual requests to render a complex page. Stop annoying them with contrived limitations. Align yourselves.
Why not just send HTML as a single response at this stage? Sometimes it feels like we are doing web development more complex than it needs to be.
- tylercrompton 3y agoSomething about injecting HTML from an API, even from a controlled server, feels wrong.
- prmph 3y agoBut that’s the point: its not an API, it’s just an app web server. There’s nothing wrong with a web server serving HTML; that’s their whole purpose.
- hakunin 3y agoThe first 3 sentences of the article are implying that the whole thing is written with "if you must" attitude. That said, a lot of companies have front-end teams, and those front-end teams commit years to building React components. So even if you render server-side, this is how you'd put data into those components. I'm a backend dev. I don't like some of what frontend is doing, but you gotta work with people, right?
- shaftoe444 3y ago> Imagine if you could just send it the whole “page” Could have stopped here
- aatd86 3y agoMaybe for separation of concerns between data and UI? The browser is not going to be the only client?
- philderbeast 3y agoyou can have seperation of data and UI and still send the whole page. The vast majority of the time, the browswer is infact going to be the only client. once you reach the point where its not, then build the api to suit the new client rather then trying to build one that does both.
- aatd86 3y agoTrue, you could insert something in the middle, that generates a page depending on the user-agent. But then it requires extra SSR logic. But on the other hand, you can have a iOS or Android based app that depends on the same data. So the browser is not the only client in general, especially nowadays, I think?
- regularfry 3y agoThat's the crux of the question. The BFF approach says that you remove logic from the client and put it in a server-side component. Not that you add extra logic. Then you might find that you need to copy that server-side component sideways for a new client, if the view layer in that client is sufficiently different to what you already have. The browser can be the only client of its BFF API; the mobile apps can either speak to the same API or have their own. Dramatically more important than any theoretical, abstract consideration in deciding whether this can work is what your teams look like. The client team should almost certainly own the BFF API, which has implications for skillsets and maturity.
- aatd86 3y agoThat's only for a react type of application if I'm not mistaken? If so, that doesn't handle the general case (native apps for instance)
- regularfry 3y agoNo, it's for everything.
- JaggerJo 3y agoThis breaks once you need to update parts of the page without reloading everything.
- marginalia_nu 3y agoIn that case you can just parse the DOM clientside and insert it into the page.
- loloquwowndueo 3y agoYou can still return html partials from your endpoints and use htmx to swap content without a full reload :)
- JaggerJo 3y agoyes, but then it’s not one request per page
- loloquwowndueo 3y agoOnly if there’s an update - htmx will encourage you to render full html pages but still gives you the ability to do in-place updates which is what most folks think a JS front end with a json Api backend and client side rendering is needed for.
- halfcat 3y agoHTMX can swap multiple DOM elements from a single HTTP response https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/
- Y-bar 3y agoJS can update the DOM dynamically. Nothing prevents the main response from being served as regular HTML and subsequent XHR request for some parts of a page being JSON or some such data format. In fact I bet that sending server-side rendered HTML is faster than sending a full structured page as JSON which has to be decoded, parsed, and then converted to HTML.
- croes 3y agoI think it's about API as such and not about how to serve the webpage. No matter of JSON or HTML don't built a general purpose API if it's only your frontend.
- littlecranky67 3y agoFeels like the author misses the point of an SPA. If you have website where every "view" is a /page/a etc., SPA might not be the best choice. But in an SPA i can be dynamic, and trigger data retrieval/sending without route changes. A very basic example is if I have a checkbox that allows the user to subscribe to push notifications. On click I sent a xhr request to the backend POST `/subscribe/1234` which registers the subscription. Next time I'll check `/subscriptions` or similar to see if the checbbox is in "checked" state (i.e. we are subscribed). This is basic functionality which requires a concise REST/JSON API, and has nothing todo with your page/route layout à la /page/a, /page/b etc.
- hakunin 3y agoAuthor here. We do this for SPA. The POST can be supported just like you explained. Then you can either reload the "page" to see that the checkbox is checked, because backend will include that as part of the page, or (as an optimization) reload just that checkbox if you created a specialized resource for it. The entire page is still there for you to fetch upon transitions. Among pages, you will still need a few individualized resources sprinkled around for optimizations/reloads/fragment-paginations. The difference between that and a complete API is that they will be entirely design driven. If a table needs paginating, and is built with data from multiple resources, you will not provide 2 resources, and expect front-end to paginate and glue them together. Instead, you provide a complete paginated resource for this table, where data is ready to be displayed as-is.
- littlecranky67 3y agoThat us exactly how stuff worked around 2005. And no, you should not do a full form post just to toggle a checkbox.
- yakshaving_jgt 3y agoWhy not?
- 3y ago
- renegade-otter 3y agoHow did we get to the point where simple and effective server-side pages are either unknown as a way of doing things or are considered to be a technical heresy? Younger developers scoff at us fossils and the olden ways, but this is exactly how this ignorance of classic, tried-and-true, performant patterns results in atrocious complexity and performance, only because "this is how things are done". It HAS to be a BFF, it HAS to be 15 different microservices and 20 different AWS toys, right? There is no other way? Are you sure? It seems like we are talking about the whole industry, but it's largely he Node ecosystem in my experience (which is effectively - the industry). It's not like there is not Rails development being done out there, with nothing but a trusty Postgres database. Ironically, our existing architecture patterns are beginning to resemble J2EE - a bulky, slow, expensive, boiler-plate-laden process where a simple site costs one million dollars and performs like shit.
- LapsangGuzzler 3y agoBecause JavaScript rules web dev and the JS community has pushed so many mainstream ideas that have turned out to be duds. It’s a major echo chamber due to its size relative to other web dev communities. I also partly blame the careerist obsession around always learning new technology, because it’s becoming obvious that a lot of the “new stuff” over the last decade created more problems than solutions. Don’t get me wrong, learning is an important part of the job, but we’ve created a culture of constantly pushing new technology to pad resumes and feed our insecurities around irrelevance instead of solving problems.
- bheadmaster 3y agoIt seems to me that the more people use <thing>, the less evidence of quality of <thing> is required by the people using <thing> - everyone just assumes everyone else knows what they're doing. It becomes something akin to a religion - after all, 2 billion Christians can't be wrong, can they?
- toyg 3y agoEat shit - billions of flies cannot be wrong. (cit.) More seriously: once a bit of tech becomes mainstream, it becomes politically easier to use it. Your manager has not heard of <cool tech>, but he did read about React in some business magazine. So when the choice is between React and bheadmaster's Funky Funkness Framework, he'll go with React.
- deleted 3y ago[deleted]
- SoftTalker 3y agoYeah, this goes back a couple of decades where "page a" was just "page-a.asp" or "page-a.php" and you did everything to do with that page in that file. Simple, and you could mostly make changes to page a without worrying that you'd break other pages. Need page b? Copy page-a.asp to page-b.asp, gut the page-a logic, and put in the page-b logic. Before you get too nostalgic for these simple days, do we rememember why we stopped developing web pages that way?
- Muromec 3y agoBecause you can't have a lot of itneractivity with a nice responsive UI like this if your network has high latency and low bandwidth. So we pushed a lot of logic to the browser. Now it turns out it doesn't scale well, so maybe we should go back to copying page a to page b and calling it a day, same way we came back to static linking once disk space stopped being limiting factor.
- slotrans 3y ago> ...do we rememember why we stopped developing web pages that way? Because we needed an API for our mobile apps, and once we had that, SPAs seemed convenient. It was definitely, absolutely NOT because the page-centric way of building sites didn't work (it does), or because SPAs are better (they aren't).
- oceanplexian 3y agoI’m a systems engineer and SPA’s are a superior architecture to deal with from a delivery POV. It is very difficult to cache a dynamic web app with a CDN. There are ways, like SSI, managing variants, Purging, and so on, but a huge pain. And if you don’t have a sophisticated CDN and are using something like Cloudfront, forget about all those fancy features. SPA? I can serve the whole thing with static files and remove 90% of the traffic from my web server. The API can be served from a different path from the static files. API requests are super tiny and more tolerant to fluctuating network conditions, and you can hide a lot of that with Javascript.
- 3y ago
- Muromec 3y ago>Why not just send HTML as a single response at this stage? Is it time to discover memcache again? I think it's about time.
- fastboy 3y ago[dead]
- madsbuch 3y agoThis is exactly how next.js works. But even more importantly: Why not use GraphQl in this situation? This is exactly what it excels at: 1. The backend can be entity centric, like it does best 2. The frontend can request a page worth of data from diverse entities in a single go.
- wiseowise 3y agoGot to pump CV with frameworks you know? Promotions don’t write themselves. Bonus point: job security. And when you leave who cares what poor shmuck will have to support it?
- barrkel 3y agoBecause you want to paginate. Update the page piecemeal based on an event from another user. Because you want to use the same data on multiple pages, and want to write the authorization and filtering logic once.
- gabereiser 3y agoBecause for the last 10 years, “code schools” and boot camps have taught JavaScript/Typescript with React as “programming” where everything outside of your immediate dom is an api call. One not worth knowing about since it’s “backend”. The reality is SSR has never been a bad idea, we started that way. Now we are seeing reimplementations of it in various forms to “solve the api call hell” that was self induced. Just like the front-end bundle size problem was self induced.