GraphQL Galaxy

GraphQL Galaxy 2021

Batteries Included Reimagined - The Revival of GraphQL Yoga

Uri Goldshtein

GraphQL Galaxy 2022

No Code? No Problem! How GraphQL Servers Break and How to Harden Your Resolvers

Thank you for joining us. We're here to talk about graphql. No code. No problem how graphql servers break and how to harden your resolvers. So first introductions, my name is Kevin. I've been here at solo.io now for several years working on kind of a wide variety of projects but relevants what we're talking about today a large champion of our Envoy in graphql and Envoy filter and related projects and we're joined here graciously today with spicy. Yeah, hi. I'm sorry. I'm a software engineer at solo along with Envoy istio and Flagger. I've contributed to multiple open source projects including glue and I'm here talking about graphql as well. I'm one of the engineers leading the graphql and service mesh effort here at solo. And speaking of solo who exactly are. We we are a startup in Cambridge, Massachusetts and we consider ourselves industry leaders in application networking service. Mesh and modern API Gateway Technologies And more recently graphql, but let's continue. So yes, so goals for today. We want to talk about the current state of like graphql servers specifically resolvers. How do you programmatic resolvers fail? How do we fix them? Then? We want to take a concrete look at declarative resolvers how that might work and demo it. Let's just see it in action. So getting right into it the current state of things. I mean, this is a graphical conference. You know, I think we should all be familiar with this but just to recap so on the left here. We have a simple mobile client making a graphql request to a graphql server This Server here is to resolving the request for a payments and planned service. Like they like a phone service. We have three replicas of the payments and three replicas of the plan service cost delineated by the little dotted lines This graphql Server is resolving some fields on the payment service and some on the plan service reconciling that back together via the schema and returning all the data on the on the right here in that singular graphql response. So kind of diving into it. We have a single resolver here. So I just wanted to focus on the planned service. You can see here that it returns just like a standard Json response to our graphql server and I'm the server will know in the execution engine how to you know, put that back into your schema and send the response back up in particular. I'd like to focus on how this is kind of working a little under the covers like I mentioned before we have three replicas of the plan service here. Now when we have three replicas, we're just kind of picking one at random there for load balancing to be concrete. I'll use kubernetes as an example here, but your infrastructure has some kind of equivalent logic somewhere if you're you know, choosing between three services of a replica to meet the scaling demands of your infrastructure in the kubernetes example here the resolver code might look like this you have an HTTP client that tries to make a requests get requests with query parameters to that DNS entry in the kubernetes example you resolve that via DNS to get that peace service on the right on the kubernetes service in that cluster IP is a virtual IP that gets resolved via low balancing to one of these three IPS per pods. The key here being is that we're kind of randomly picking one of these three pods to actually hit. One of these three replicas of the service. So now if we think about server outages Let's Pretend one of those three replicas goes down for whatever reason we could say Hardware failure, you know bug in the code. That's a memory leak deadlock, but I have you What this will mean in practice is that when the graphical server resolves that request, you know, one out of those three replicas will come back with like a request timeout and then the client will see errors the UI will get incomplete data. This is you know, obviously bad and something we want to avoid. So yeah, like I mentioned we want to minimize pain, how can we do this? So looking at example, I know I leaned on on kubernetes before which is this is just to make things concrete. But again, this is just something you're infrastructure probably has in some quick shape or another and you just may not be aware of in here. We're gonna look at what Readiness and liveness probes do again the scenarios that this is trying to resolve there are primarily things like a memory leak deadlock in your code or even just like a hardware failure getting things. We scheduled the Crux of this is that in kubernetes. At least you have a pod you have a process here in this example, we have live in this probe and what it's doing is it makes an HTTP get request to your service at slash health. It waits three seconds before making the first request and most importantly it makes the request every three seconds. And so it's really just polling all the time. And if it starts seeing failures, it knows that your services unhealthy. It doesn't really care. The reason why it just knows that it's unhealthy and it's probably better to restart things, you know, kick the process move it to other hardware. And again, this is the kubernetes way, but this could be done in a variety different ways a watchdog some kind of process monitor, you know infrastrated by puppet and a lot of this is kind of outside of the realm of you know, graphql conference, but this probably exists in some shape or form. So our goal is to minimize pain. Can we do more if you know we have this, you know, polling mechanism every three seconds, but let's think about the scenario. We have an API that's very busy. That's why we have to be replicas. We were receiving thousands of requests. That's pretty slow. It's gonna take us a while to you know, inject those those endpoints and actually serve healthy responses to our client. So that act of polling activism is like Active Health checking. I'm sure we've heard of maybe circuit breaking before but another way we could solve this is with passive Health checking and so kind of a very dumb pseudo code on the left on how this might work just to go through it together is let's just say our resolver code was instrumented with some some knowledge of the IPS and DNS. And so what we could do is, you know, when they the graphical server starts we get all the IPS behind our service. We have all our replicas. Then when we resolve we just pick a random healthy IP and we route to it and if we happen to get in response, that's not okay. Then we eject it. We Market is not healthy and the next time we won't try and we can you know move them back to to healthy after time out. But the Crux of this is if we're receiving thousands of requests per second. We can instruct our server to say hey, if you've got five errors in a row, like stop trying, you know like to serve this endpoint's probably not. Okay. Our resolver can do a lot better be smarter and not send requests to this replica that it knows is probably not going to work. Um, now this code obviously not production ready. You definitely don't want to instrument your resolvers. It's kind of logic but this logic doesn't need to live somewhere. If we want to bring this into our our graphql server. Where do we put it? It could be in some kind of graphql server middleware behind your graphql server. We could try to move parts of it to a DNS server, you know bad for other reasons. We could use a node local proxy another load balancer. It's a lot of options here we can we can dig deeper. Just kind of stepping back. So we looked at circuit breaking here as an example. But the problem here is that graphql is a single endpoint. It's a single server living on on this on the Node that has to be responsible for a lot of responsibilities before, you know, sending requests to Downstream services. So if I'm you know, operating a graphical server and winning resolvers it you know, sometimes I have to instrument them with things like failover concerns circuit breaking like we just talked about a retry policy authorization authentication rate limiting you can see here on the left is kind of our ideal resolver. We want to keep resolvers lights very simple to read and reason about but we we often see resolvers instrumented with things like on the right here. We have checks for authentication, you know to make sure you are allowed to access that back end. But you know, this isn't ideal further some of these concerns that we're talking about like have to be handled on the Node like the hardware. Cell that the graphql server resides on for example, like circuit breaking if we wanted to move this to some other Hardware. We're introducing another point of failure, you know more Network points of failure that's harder to reason about it distribute systems. It's much better if we keep it local. So we mentioned, you know of those options we could look at. Putting another proxy that has this kind of context-aware knowledge on the same Hardware so you can have a graphical server that then wrote to a local proxy in that proxy has that, you know circuit breaking authentication awareness and routes to servers Services behind. Or we could you know kind of shove them together. What if they were one thing? What if we thought of our gradual server as less of a server and more of like a protocol or a layer that exists in our pre-existing proxy or infrastructure? So this is kind of bleeding into the ideas that I had. You know of API Gateway service. Mesh. This is a little bit of kind of like Solo's bread and butter and perhaps newts for a bunch of you, you know, attending a graphql talk but the the real idea here in the left for example is that if you think of requests coming in and out of your your company your network usually you have something at the edge this thing on the edge is called APK Gateway or sometimes behind a load balancer. It's responsible for things like a firewall and you know, presenting, you know leaks of personal data that kind of logic is implemented in a bunch of reverse proxies. For example engine X Envoy proxy ha proxy and then it handles complex routing failover circuit breaking to your back-end Services, whether they're monolithic microservices or Cloud functions or kubernetes clusters. Really. The only point I wanted to make is that you've got reverse proxies and they likely already exist in your infrastructure whether you're aware of them or not likewise that handles what we call North You know into or out of your network traffic on the right. We also have the idea of service. Mesh. This is kind of even more nascent or new but you know, this is using the same similar sets of proxies. So Envoy engine xhaproxy to handle routing between services within your network. So think about like standardized observability metrics tracing as well. As you know, common use cases just encryption everywhere zero trust networking and your infrastructure may have this already and you may already have automatic proxy, you know all next to all your services and without even knowing so we talked a little bit about the problems that we're seeing currently with resolvers and our current deployment model and a lot of graphql servers where you might need to have an proxy in front of a reverse proxy in front of your current graphql server, and we talked about how we can merge the graphical server and the proxy together. And let's talk a little bit about how this works. And what are the benefits of actually doing that? So now that we have our graphql server as part of our proxy we get a lot of benefits that previously came just from having proxies just caching authorization authentication rate limiting web application firewall as well as routing traffic graphql traffic from users to be back in services. You can also have traffic routed securely via TLS to your backend services and have secure communication within your cluster from your proxy your API Gateway your back and services. and we talked a little bit about the fact that we could do this in code or we could also do this as configuration. We chose to do it Morris configuration and here's example of what declarative resolvers look like. So on the left side, we have a resolver. That's a resolving a graphql request by routing by creating a request to a rest upstream and on the right on the right. We have a grpc request being created. So we see a lot of the backbone of what exactly this declarative configuration looks like where we're constructing an upstream request on the left. We see a path field for actually setting the path to the rest Upstream the HTTP method as well as some additional headers. We might want to set on the rest Upstream request. And on the right we see for the grpc request. We have the service name the method name other grpc parameters that are needed to create an upstream request. As well as the actual reference to the Upstream in this case. This could be a kubernetes service a destination an external service or whatnot. And then we have this JQ field. We're gonna get a little more into what exactly JQ is but essentially it's a templing language for allowing us to construct data during runtime from our graphql request into the specific protocol that the Upstream requires in this case. We're constructing the path. Dynamically from the graphql arguments and the query so let's get into a little bit about what JQ actually is and we can frame we can best sort of frame what JQ saws by outlining a problem. And in this case, we have a schema that returns a array of review objects and the review objects have a reviewer and ratings field, but then our Upstream responds back with data that looks like this where we have a bunch of key value Pairs and essentially addictionary that have the reviewer name and the ratings. Now this isn't something that graphql knows how to natively work with the graphql spec does not include this sort of data shape. so we have the problem of having to transform the Upstream data into data that graphql servers can actually recognize And in order to do that, we use JQ, which is an expressive transformation language. And here we're showing that through a series of filters. We are able to transform the Upstream request data or the response data. Into Data that actually is recognized by our graphql schema and our graphql filter. I highly recommend looking more into JQ is it's an extremely powerful language for transforming Json. Thanks psye for jumping in with the concrete example here. Just taking a step back a million foot view of what we're looking to do here is really just reuse existing infrastructure, you know, a lot of in companies already have API gateways or service mesh and already have these reverse proxies implemented, you know, obviously leaning on your CDN for for cash queries and Long Live backing Services passing them through for grpc graphql subscriptions, but really the sentiment is is less is more if we can get away by reusing our infrastructure and and treating graphql is a protocol rather than a separate server altogether, then we can get improved developer experience and reliability. Yeah, so let's look at this in practice. Let's see an actual demo of this working in cluster. So this is our kubernetes cluster environment on the left side. We can see a user interface for interacting with our cluster. And you can see in our cluster. We have a service that's running called Product page. Now. We have project page version 1 and version 2 that's running. Now we want to interact and get a response from these Services via graphql query and we can do that by curling our Ingress Gateway, which is running right here. You can see it's the istio Ingress Gateway and that is running on way if we check out the image. Manifest you can see that's running our Envoy proxy. And within the on-way proxies of graphql filter. So if I send a graphql request, it should look familiar to the envoy proxy. You'll see that we get a response back with the data that we want. Now, let's continue to add a bit of details onto this request. And we get back a response. So just this. Now you might have noticed that some of our requests are actually failing. And it's failing with this rest resolver got response status 503 from the Upstream. Now this means that our graphql filter is not able to communicate with one of our upstreams and this is expected if we actually take a look at the images used in these two different deployments of the product page service. one of the images is actually a non-responsive curl image, which means that if we send any sort of traffic to it, it's not going to respond with any data, but the other image is an actual service our booking for a product page service. provided by istio So what's actually happening here is that our traffic is being implicitly load balanced by kubernetes in between the two back end services for our product page. service So how do we sort of mitigate this Behavior what we can use an outlier detection policy which allows us to essentially take out the unhealthy services from the endpoint pool that the graphql requests are routed to in the Upstream. So what does this outlier detection policy look like? It looks something like this. It says we can apply this outlier detection policy to our services and say that if our services receive at least one consecutive error, we want to remove that cert particular instance of the service from the healthy node pool or the healthy endpoint pool. So let's go ahead and apply this outlier detection policy. We can go ahead and take a look at the policy wait for the status field to be updated, which means that we know that our system is processed it. There we go, and we can see the status field is updated right here that says State accepted. So now what we should see is that we can continue to curl our service. And the second it receives a 503. The bad service the product page V2 will be removed from the healthy endpoint pool. So now the rest of our requests should be completely healthy and you'll see that we're getting back the data that we expect. Now there's one more thing and that's the base injection time. That means how long the endpoint will be ejected from the healthy eaten endpoint pool and that all this says that is that after 60 seconds. The endpoint will be added back in to see if it needs to be circuit broken again, or if the endpoint is healthy again. And so that's how we've made our resolvers very resilient against services in the back end going down. I didn't demonstrate it in this demo, but we can add things like failover retrys and other policies that make our resolvers super resilient. And that was our demo. So on behalf of solar.io and Kevin and I we just wanted to say thank you for having us here at graphql Galaxy. Please join us in our public slack and follow us on Twitter. We're really happy to continue the discussion there and and engage with you guys in the community.

Kevin Dorosh

Sai Ekbote

React Advanced

React Advanced Conference 2022

Zero Bundle Size Server Components

react server components reacts over components is the recent feature introduced with reactating and launched with next year. Today I will be talking about the rendering strategies which is mainly client side rendering and server side rendering. Then I'll talk about the reacts of a components. What are the ax over components how it is different than server side rendering and how we can use them in our application. We will also see the performance benefits of using react server components. Then we'll do everything coding live coding and see everything up and running. Finally, we'll also talk about some challenges that you might come across when you try to use the ax over components in your existing application. A bit about myself. My name is Ashima. I'm a senior for an engineer working in Amsterdam. In my free time. I like to create some front-end videos. So you can reach me out on LinkedIn Twitter. Finally talking about the rendering strategies. So we have client side rendering and server side rendering. In client-side rendering when user requests the website server sends a blank HTML with a script tag with source bundle.js. Browser then downloads the JS file via gets loaded. And a request to send to fetch the data from server. After the data is received from the server the content becomes visible. This approach works great for building High user interactive websites as you can reload the components which have been changed instead of reloading the entire page. However, the problem comes as you ship more and more code to our GS bundle the bundle size increases and browser takes time to download the bundle. Because of which we get delayed FCP. Also with client side rendering there are SEO problems and you're not able to run them on non JavaScript devices. We have another strategy which is server side rendering. In server side rendering when user requests the website this time server sends a fully rendered HTML. But this HTML is static. So what browser does is that pilarly it also downloads JS file? Then the comparison is done between the page which is generated by the browser and the one which is sent from the server. This is what we call hydration. After hydration react takes control and content becomes Interactive. One of the huge benefit we get from SSR is improved FCP because browser does not have to wait for client to generate an HTML and show content to the user. Also, the SEO problem is solved. But one of the problem with SSR is that you can only use server-side rendering on first upload. After that after hydration the app behaves like a normal client side rendered application. Now some of you might say that in next year's you can create multiple routes and on each route. You can use server side rendering. But what happens is that as you switch between those doubts the state of components is not maintained. And this is one of the major difference between server side rendering and react server components. the talking about react server components as the name suggest reacts over components are rendered on the server. Now the end goal for browser is to generate a dome tree. So if you're using client side rendering all the components in a reactome tree are rendered on the server. If you server side rendering all the components are ended on the sub. Sorry, if you use client side rendering all the components are rendered on the client and if you use server side rendering all the components are ended on the server. However, with react server components some of the components are rendered on the server and some of the components are rendered on the client. And when I say the components rendered on the server, it does not mean server-side rendering. Because in server side rendering what happens is that all the components whether it's a server component or a client component everything gets converted into a Roy HTML and send to the client. In fact react server components can be used along with server-side rendering. so what you can do is that when user requests a page for the first time you can use server side rendering and this time server will send HTML. And the next time as you switch between the route. The client can request server component and this time server will send a js6 like object which looks something like this. So now if you look at this clearly, so the response we are getting is some of the client files and some of the server files. So now if you pay attention to the client file, what is sent from the server is only the file reference and the chunks are empty. However with the server file, it's already sent rendered from the server. Now, why would you want to render components on the server? So one of the benefit is that if the component is already on the server, it can access the DB and file system directly which means that it can access the fire. It can access the server resources very quickly, which means that data fetching becomes really fast then using a fetch call from the client. Also server is good in making computations so you can get faster computations and also for the security purposes you can you you can choose to keep the sensitive data on the server. Instead of sending on the client. So the main idea behind RSC is to let server do what it can do the best before handing over things to the browser. So what server is good at is data fetching fast performance. So you can choose to do all the performance related stuff heavy rendering on the server and leave client for the interactivity part. All the code that we do inside the server component. Is not sent to the client bundle. Which is a huge performance benefit because it adds 0 KB to the bundle size. And also we get direct access to DB and the flying and the file system with server components. Now what is sent from the server is rendered server component and the client placeholders. So when tree shaking happens only the server components are refined which means that the state of client components is maintained. Now all of you must be feeling like what is happening, but we will see everything in the coding. Right. Now the server components are still in experimental State and it's only supported in next year's. So if you want to try them out you need to use next chairs. There is a framework created by hydrogen or by a Shopify, which is hydrogen. It uses reacts of a components and feel free to check out the documentation. It's really interesting how they have used server components. Now there are a couple of rules. We need to follow when we need to use the acts of a components. I will just read them out. So firstly you need to save the files with extension Dot server.js and client.js because this tells react that which components are to be rendered on the server and which components are to be rendered on the client. Server components can only pass serialized props to the client components. Which means you cannot pass functions? client components cannot import server components and server components cannot use hooks like you state or any event handlers. You also need to have some configurations to get them started. So you need to install next Canary react RC and reactome RC? Also in your next dot config.js you need to turn on the flag. So a components true. Now, let's create a server component. So what we are going to create today is an email application. It has a list of emails and as you click on any of the email card, it should open the email body. So in our application there are two main components one is the email list. And another one is the email body. So first, let's write the email list component. First I will do is fetch the emails. Now I will go through the emails. And for each email I will display name subject description and date. Now here instead of passing the raw date. I will import a function. And pass the formatted date. now the email is component looks something like this. What I'm going to do to now is that break this component into two components. So one is the container component which will be used for fetching data. And the another one is view component, which will have everything related to The View. So now I've broken this component into two components. Now I will rename the files with DOT server and Dot client JS because I want this server file to be rendered on the server and client file to be rendered on the client. Now I'm going to import email list view component into my server component. Now one thing to not note here is that in the props you can only add those props which can be serialized over the network, which means that you cannot pass any functions to the client component. So this is how what my server file looks like. And since it's rendered on the server, so instead of fetch, we can also read it from the DB. Or did it from the file system directly? To for the more resources. You can check out the blog by then at remote introducing 0 bundle size server components and then you can check out the next GS documentation. And also there is a live next year. Next year's has created an app which you can reference for creating your own application. Now, let's see what we have built so far. So this is our application which is like email cards and as I click on the card, so it opens the email body. Now, let's see what is being sent to the client. So as I click on the second card, so this is What what the response looks like and this is what we saw in the screenshot as well. So it sends the client client files the reference of the file name and this will be used by the client by the browser to generate the client side later on. And then this is the fully rendered server file. So the server is sending something like a jsx like object. Second thing I want to point out here. Is that as you open the webpack? And here we have components and in components, we have email body and email card an email list. So if you notice here that all the files which are sent is the client files and there is no server file so which is like none of the server code is sent to the client bundle. Another thing to notice here. Is that like as I mark it important. So now I will switch between another route. So I'm going to Mark important the second round. So now my route changes, right? So it it has a open email slash two. But the state has maintained so the previous important has been maintained. But if you were using only the next years without react server components, what would happen is that the entire page would refresh so we would have lost this state. So now it's no matter how many routes we changed. All the state is maintained. So now let's talk about some of the challenges we can come across when using server components. So first challenge, is that a client components cannot import server components? And what I mean is that let's suppose we have a client component my client component. And let's try to import a server component. But this does not work. So instead of using it like this, what we can do is use composition so we can pass the server component as children. And this is how we will use it. We can compose the react server component inside the client component. The next challenge you can face is using hooks inside server components because it's rendered on the server. So you cannot use State use effect anything. So make sure whenever you want to use States you divide your components into into client component and server component so you can drop all the states related code into a into client component. And the another biggest challenge is making a third party API call inside server components because as we are making the third party call that the data also needs to be rendered on the server and then you can pass the rendered data into your component using getstatic props if you're using next year's. Now, let's see. Why do we need a framework why we want to use next year's for using reacts of a components. and that is because for reacts of a components, we need configurations at all the levels which is rendering routing and also the bundling And next year is provides all those configurations in-house at the moment and that's why react team has decided to launch react server components with the Frameworks. So this is what our code looks like. I fold a structure. It has every component has a client file and a server file. So we'll have two server files and the two clients files which are rendered on the client. So now we can pretty much say that every front end is a full stack developer. Thank you for attending my talk. You can reach me out on Twitter or LinkedIn and here is the link to the slides. The email application is also on the GitHub GitHub. So, please feel free to check them out.

Aashima Ahuja

Hydrogen: An Early Look at Server Components in the Wild

Hello. Hi everybody. I was not sure I made so many slides. I had to delete so many to make it a lighting talk. Anyway, I'm here to talk about hydrogen and an early look at server components. Um, this is me. I work at Shopify. I am part of the maintainers of this framework, which is made for headless storefronts. And what's interesting about the framework is that we use react 18. We use server components and and beat them. So yeah, I want to talk about some of our experiences with several components in the wild. um and just for some references like we already have some big Merchants using them in production sites all birds like this is a Merchants are already get billions. Yeah, and this is another one made with hydrogen denim tears. And atoms what is curious with hydrogen is that we give components so that you can build really fast this headless storefronts. And for example, this one was built in with one developer three months and in average it takes it around 12 months to to do this. So I think that's pretty great. And yeah, so they are they are all with server components in the wild. I wanted to talk about well rendering react. How it used to be, you know at the beginning we used to just have the components and then we just bundle all together and then send it to the browser and then you know the client the person sees this widescreen for a while until everything gets rendered right at some point. We complicated things or I don't know made it more interesting having, you know service I've rendering and hydration and and I guess now what happens is we send server rendered version of the site and then the client bundle and then we hydrated and then it becomes interactive but still kind of awkward and I guess what we would like to have special for Commerce sites is something more like like this right like it opens and I can buy immediately. It's all right. That's why we're using react 18 react 18 gives you three components now the server ones clients and shared. And well, the client components is what we kind of already do right we use State and we do this. I don't know this functions and they get sent to the browser. They get rendered there except with all the Adoration stuff that I talked about that is, you know, 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. And 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 that I want to talk about this client and server components because the cool thing about several components is that yeah, you don't add anything to the bundle. So you just send HTML directly. And the way we use them in hydrogen is, you know, we build them normally like any other component but we also do queries to the database and then we put them in the in the components and the end result is just send HTML directly to to the browser. Yeah, so why don't we use several components for everything? Because we still need interactivity, you know, if I want to buy a different type amount of products. I want to be able to choose that and you know do a server render because of that is maybe too much. So just some of our learnings has been that well as we rolled out several components not all libraries are 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 several components to people they start to do a lot of that of fetching and this could take long and then people are like, okay, it's several components supposed to make my side faster, but actually slower for this because we are not of fetching a lot of stuff. So something that reacting is giving is suspense. So what you will do is wrap this component that's very heavy in suspense. And the result is for example in this example is the everything is rendered. But that little part that might be a bit heavy gets later render and serve. There are still hard to the book like when something goes wrong in the server with server components. It's still 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. Like I can still do the same as with client components and have like something like this and be able to just render things fast and the HTML and use them directly. So I guess the future of headless. I think it's exciting. We're having new things list like Edge workers where you know, we can have renderers 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 scores are look like this even with e-commerce sites that are you know, highly Dynamic and could have a lot of you know intricacies, right? So conclusion for me is that Sarah rendering will happen more and yeah, if you want to check it out you can go to this website adojain.new and you can actually play with demos shop that we did and play with yeah the cervical components and we are hiring a Shopify. So yeah, that's a that's it for me. that's what

#server components