React team observes that running everything on the client can be costly, aims to fix it with Server Components
- Reference: 1610017267
- News link: https://www.theregister.co.uk/2021/01/07/react_server_components/
- Source link:
Should applications run most of their code on the client, or on the server? It is a never-ending question and the balance tilts one way and then the other as technology advances. Early web applications ran mainly on the server, in part because web browsers only had basic scripting capabilities, often replacing fat native client applications for Windows or Mac. Faster connections, asynchronous JavaScript, and HTML 5 swung the pendulum back towards the client.
[1]
Then came AJAX (Asynchronous JavaScript and XML, and later the fetch API), HTML 5, and lightning-fast JavaScript. Frameworks like React.js and Angular.js made it easier to build richer browser applications, at the expense of some bloat and perhaps [2]uglier HTML (if anyone is looking).
A new trend goes a step further and argues for static websites, built with JavaScript, that call microservices for dynamic content. JAMStack (JavaScript, APIs and Markup) site generators including Gatsby, Hugo, and Next.js create web applications that do not require a web server. Both Gatsby and Next.js use React.js so it is not either/or.
[3]
Facebook senior software engineer Dan Abramov describes the benefits of having some React code run on the server instead of being downloaded to the browser
What could go wrong? In an [4]introduction to React Server Components, Facebook and React Core developer Dan Abramov describes what he calls the waterfall problem. This is an application that requires several different database queries to populate different components. If you grab all the data in one JavaScript fetch – he calls the example function FetchAllTheStuffJustInCase() – it is efficient, but an ugly solution, particularly if at a later date the design changes and not all the data is needed. The alternative, he said, is a separate fetch for each component, which impacts performance.
Server Components, which are in early preview, are a solution. Components with a .server.js file name run on Node.js and perform a fetch on the server, where low latency and proximity to the database server overcome performance issues. Another benefit, said Abramov, is that React libraries used in Server Components are not downloaded to the browser. In his example, he used a 21KB date library to format a date, observing that this is a heavyweight solution but since the library stays on the server, it does not matter. Components with a .client.js file name run in the browser as before. In tests, the team observed a 29 per cent reduction in the size of the bundle of JavaScript pushed to the client, when pages are converted to use Server Components, with greater reductions expected as development continues.
Server Components are not the same as server-side rendering and there are no ugly screen refreshes as users navigate a page, even if the data is re-fetched. "Server Components don't render to HTML," explained Lauren Tan, who works on React Data. "They render to a special format." The framework updates the user interface in the background. It is also possible to have files that can run either on the client or on the server. Where it runs "is determined by what kind of component that is importing that shared component," said Tan. Such components are downloaded on demand when used on the client.
An advantage of Server Components is that the code can access backend resources directly, said Abramov. Sometimes the developer might want to "read data directly, and not have to access any API layer," he said.
New libraries have been added to React to support Server Components, including react-pg for accessing a Postgres database server, react-fs for working with the file system, and react-fetch for calling APIs from the server. These are called React IO libraries.
Are Server Components replacing [5]GraphQL , a runtime and query language used by Facebook and others? "Not really," said Abramov. "At Facebook we use both server components and GraphQL," though he added that the new components might remove the need for GraphQL in some scenarios. Server Components can read GraphQL queries.
[6]
Trying the Server Components demo with Visual Studio Code and Docker
Today many developers combine React.js or other modern JavaScript frameworks with server-side web applications. The advent of React Server Components will mean that React becomes more of a full-stack option. They "provide modern UX with a server-driven mental model," said Abramov.
The technology is still in research and development, Abramov said, and the team is working with the Next.js developers. The recommended way to get started is to download the demo and try it out; developers are discouraged from using it more widely (even though Facebook appears to be doing so). Abramov remarked mysteriously that if coders incorporate the current preview components in production, or teach about them in courses, "it makes it more difficult for us to share our research in the open." Instead, developers are encouraged to read the [7]RFC and add their comments there.
[8]
Early reaction is mixed. "Server Components are a great idea, it will change the game," [9]said one , while another [10]remarked : "I wouldn't trade a fractional increase in performance for the complexity this brings to a project, especially when I have many other levers I can pull before pulling this one." ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_datacentre/servers&sz=300x250%7C300x252%7C300x600&tile=3&c=33X-c@KY9e6T3NCn@6-@voGAAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dtop%26test%3D0
[2] https://www.theregister.com/2020/11/04/bbc_embraces_aws_serverless/
[3] https://regmedia.co.uk/2021/01/06/servercomponents.png
[4] https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
[5] https://graphql.org/
[6] https://regmedia.co.uk/2021/01/06/regdemonote.png
[7] https://github.com/reactjs/rfcs/pull/188
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_datacentre/servers&sz=300x100%7C300x250%7C300x251&tile=4&c=44X-c@KY9e6T3NCn@6-@voGAAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://github.com/reactjs/rfcs/pull/188#issuecomment-749178427
[10] https://github.com/reactjs/rfcs/pull/188#issuecomment-74918818
[11] https://whitepapers.theregister.com/
Lightning fast javascript?
I don't know what you're smoking sonny, but it's seriously messing with your sense of time.
Or maybe you're just too young to remember what native code could be like. (Could be, not necessarily is.)
Re: Lightning fast javascript?
I'm not sure it's JavaScript ( per se ) that's the problem - it's had enough performance work done on it for the purpose it serves. It's the operations on the DOM that take the time - if you were looking at the most efficient way to update a user interface it wouldn't be by applying a stream of incremental changes using a text-based mark-up language that then interacts with a text-based styling system that likely causes a significant amount of re-rendering that's then partially invalidated by the next incremental change.
It would be the same problem with Wasm - which is as near to native code as you're going to get - you still have to call back into the DOM to display the results.
Historically, the focus has always been on getting load off the servers and shifting it to the browser. If you're happy to do the work on the server, then there's an argument for doing all of it and simply sending a stream of GPU operations to the browser to draw the result. I think that's the way we may be headed, even if we're proceeding by a series of apparently random walks.
Re: Lightning fast javascript?
If you're happy to do the work on the server, then there's an argument for doing all of it and simply sending a stream of GPU operations to the browser to draw the result.
Isn't that the "thin client" (X terminal) model again? The pendulum swings...
Server side = not in user control?
The other advantage (to Facebook) is that server side is outside local European legislation protecting the privacy of individual users. This is how they will overcome e.g. the Apple restrictions on device ID tracking.
Re: Server side = not in user control?
I really don't think server side is a way to avoid EU regulations
Re: Server side = not in user control?
Er no.
GDPR and other priv regs don't care where the data sits, just who has control of it and what do they do with it.
Client side or server side is the same.
Re: Server side = not in user control?
They can't bypass regulations, but they can bypass client-side tracking protection, that's true.
Anyway once again they are going to re-invent the wheel and "discover" again what has been know for decades about distributed systems.
am i missing something?
"he calls the example function FetchAllTheStuffJustInCase() – it is efficient, but an ugly solution, particularly if at a later date the design changes and not all the data is needed. The alternative, he said, is a separate fetch for each component, which impacts performance."
erm couldn't you do something like
FetchMeTheStuffIAskFor( ["/api/user","/api/stocklist","/api/basket"], [ params1, params2, params3] ) ?
and an api on the other end which just calls all the apis requested internally and assembles the results?
Re: am i missing something?
You could indeed, but wouldn't it be nice if the server knew what stuff you're going to need and included it already when sending the main page? Saves an extra round trip.
Hell, you could just call this a Hypertext Pre-processor. But to be popular with geeks of a certain vintage you need to make it a recursive acronym: PHP: Hypertext Preprocessor. I reckon I'm onto something here...
Re: am i missing something?
That's how graphql does it, here's the shape of the data i want back and the top level key.
Doesn't really fix the problem of a single call doing lots of disparate jobs though.
Turning UI devs into Full-Stack devs
One language (or framework) to rule the entire stack. This helps balance out resources across front-end and back-end. How many times has a front-end dev's work been delayed because the back-end devs are behind; or vice-versa?
Problem is, this doesn't solve the next level down in the stack. Somebody still needs to manage database changes, server configuration changes, auth model changes, hardware; and all the other weird and wonderful things further down the stack.
Client / server architectures
are like types of customers. Thin clients, thick clients, fat clients, those who think the server should do everything for them and those who think the client should control everything................ you'll meet them all eventually if you stay in the industry long enough.
Server Components are not the same as server-side rendering and there are no ugly screen refreshes as users navigate a page
Server-side rendering doesn't imply screen refreshes like that. SSR is an initial server-side render of React (or equivalent) code into HTML, with all the events etc attached, but still works like React (or equivalent) once it hits the browser. You're thinking of old-school request/response full page refreshes.
Anyone with serious Enterprise development experience knows the expense of transmitting data to a client for processing DWARFS the cost of a complex RPC on the server that can do the IOs close to the databases.
But the internet kids have to learn old technology all over again, because they're in love with the buzzwords and don't realize it has all been done before under different terms with different languages. I've been coding since the 80s; it is surprising how little has really changed when you get to the nuts and bolts of the design issues and caveats involved.
Bzzzz
they're in love with the buzzwords
Sorry, I initially misread this as "they're in love with the buzzsaw". It still fits your comment well.
Back in the day it all ran on the server. The more clients you had, the more resources you needed.
Nowadays a client brings compute capacity with them. If you can design your system to take advantage of that it will scale better.
But of course anyone with serious Enterprise development experience knows that....
So React is moving to an MVC type architecture? I thought it already had that in part with Flux?