Hydrogen: An Early Look at Server Components in the Wild


Shopify's Hydrogen framework has been released with an early version of React's server components. In this talk I will discuss: * What is Hydrogen? * What are server component and how are we using them? * How are they different than client and shared components? * How are server side rendering and server components different? * I'll also show examples in the wild After the talk I hope the attendees will understand the Hydrogen framework and React server components better.



Hello. Hi, everybody. I was not sure. I made so many slides. I had to delete so many to make it a lightning talk. Anyway, I'm here to talk about Hydrogen and an early look at server components. This is me. I work at Shopify. I am part of the maintainers of this framework, which is made for headless storefronts. What's interesting about the framework is that we use React 18, we use server components, and Vita. I want to talk about some of our experiences with server components in the wild. Just for some references, we already have some big merchants using them in production sites. Allbirds, this is merchants that already get billions. This is another one made with Hydrogen, denim tiers, and Atoms. What is curious with Hydrogen is that we give components so that you can build really fast this headless storefront. For example, this one was built with one developer, three months, and in average, it takes around 12 months to do this. I think that's pretty great. They are all with server components in the wild. I wanted to talk about rendering React, how it used to be. At the beginning, we used to just have the components, and then we just bundled all together, and then send it to the browser. The person sees this white screen for a while until everything gets rendered. At some point, we complicated things or made it more interesting, having server-side rendering and hydration. I guess now what happens is we send a server-rendered version of the site, and then the client bundle, and then we hydrate it, and then it becomes interactive, but still kind of awkward. I guess what we would like to have, especially for commerce sites, is something more like this. It opens, and I can buy immediately. That's why we are using React 18. React 18 gives you three components now, the server ones, client, and shared. The client components is what we already do. We use state, and we do these functions, and they get sent to the browser, they get rendered there, except with all the hydration stuff that I talked about, all the magic. The new ones are server components, and these are very interesting because you do the same thing as client components, but the end result is that this is HTML that gets sent directly. The final one is shared components, which is something that could be in the client or in the server as well. But I think the main thing I want to talk about is client and server components because the cool thing about server components is that you don't add anything to the bundle, so you just send HTML directly. The way we use them in Hydrogen is we build them normally like any other component, but we also do queries to the database, and then we put them in the components, and the end result is just send HTML directly to the browser. So why don't we use server components for everything? Because we still need interactivity. If I want to buy a different amount of products, I want to be able to choose that and do a server render because of that is maybe too much. So just some of our learnings has been that as we rolled out server components, not all libraries out there are compatible, so that's one issue that we've had. So sometimes you have to mingle around to try to make them work. A second learning is that as soon as we gave server components to people, they started to do a lot of data fetching. This could take long, and then people are like, OK, is server components supposed to make my site faster but actually slower? But it's because we are data fetching a lot of stuff. So something that Reacting is giving is suspense. So what you would do is wrap this component that's very heavy in suspense, and the result is, for example, in this example, everything is rendered, but that little part that might be a bit heavy gets later rendered and served. They are still hard to debug. When something goes wrong in the server with server components, we don't know how to take a look. There's still not enough tooling around, so that's something where it'd be nice to invest in. But still, the good thing about server components is that encapsulation is really great. I can still do the same as with client components and have something like this and be able to just render things fast and be HTML and use them directly. So I guess the future of headless, I think, is exciting. We are having new things like Edge Workers, where we can have renders really close to the user. So we can do server rendering really fast. And we have now a lot of hosting platforms like Oxygen, which is something that we have in Shopify. And because of that, we are starting to see Lighthouse cores that look like this, even with e-commerce sites that are highly dynamic and could have a lot of intricacies. So conclusion for me is that server rendering will happen more. And yeah, if you want to check it out, you can go to this website, addogen.new, and you can actually play with a demo shop that we did and play with the server components. And we are hiring at Shopify. So yeah, that's it for me. That's all. Thank you.
7 min
21 Oct, 2022

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic