Why Your Current GraphQL Strategy Is Burning Through Vercel Invocations
If you’re like me, you constantly need to make GraphQL calls to Sitecore to pull specific data from different templates, renderings and pages that are not included in your Layout Services. As you probably already know, Sitecore has a GraphQL endpoint that you can call to obtain any data from Sitecore you’d like.
The default approach to this might be to create a new Next.js Serverless function and call Sitecore directly from your application, either before the page loads with SSR or after using CSR and a fetch statement. This is a good approach if the data you need is only on a minimal amount of pages & isn't needed frequently. However, this is a very inefficient way to pull data if it's something on a plethora of pages; if you're hosting on Vercel each time a serverless function gets called, it adds a Serverless function request to your bill. If the data you need is populous, then you're going to burn through your Vercel plan's allotted Serverless function invocations very quickly.
Luckily, there is an easy way to include your GraphQL calls with the initial data received from Sitecore via the Layout Services!
How to Include GraphQL in Layout Services Response
Each Sitecore Rendering has a dedicated “GraphQL” response box that you can use to make GraphQL calls prior to the Layout Services sending data to your Front End.
However, this box has one major flaw; when GraphQL is present, the Rendering will ONLY return the data that is inside your GraphQL query. This means that any Template data you have included on your Renderings will not be included in this response.
Working around the Limitations of GraphQL in the Layout Services
The workaround is actually pretty simple: We need to create a new rendering, that is dedicated to ONLY returning our GraphQL data, and include that on any of our pages that need our new GraphQL data!
To do this, we are first going to open up the Layout section of the Sitecore Object Explorer tree and navigate to the Renderings folder. Then we will create a new Rendering inside the Feature or Project folder.
Layout → Renderings → Project/Feature
Once we have navigated to the correct folder, we can find an existing Rendering and “Clone” it to create our new GraphQL Rendering.
For this example, I’m going to be pulling custom Toast data from Sitecore and including it on every page in my Sitecore website. Once I’ve created my new rendering, we can open it up in the Object viewer and add our custom GraphQL to the “GraphQL” box.
If you don't have your GraphQL yet, then you can navigate to yourDevelopmentDomain.com/sitecore/api/graph/edge/ui to access the Sitecore GraphQL Playground. This is an open playground that you can use to create test GraphQL queries directly from your Sitecore instance. You just need to include your Sitecore API Key in the following format:
{
“sc_apikey”:”{apiKeyGoesHere}”
}
Once you have created and tested your new GraphQL query, you can return to Sitecore and include it in your new Renderings “GraphQL” box. Here is an example query I used to get my Toast data.
Once you have added your GraphQL query to your new rendering, you need to add the new rendering to any pages you'd like to include the new data in. Since I want to include my Toast Settings data on every page, I'm going to add my new Rendering to my Header Partial Design because it is on all my pages.
Now that you've included your Rendering on the page, you can console.log out the incoming Layout Services data, and find the structure of your GraphQL Response.
Finding the GraphQL data can be a little tricky at first, since it's nested so deeply in the Layout Service's Response. You will want to go fields → data to find your response. Here is what my Layout Service Response looks like with the new GraphQL query included:
Now that our data is being returned to the front-end, I'm going to process it and add it to a custom hook I created for my toast settings. Here is my example code for how I handled my data.
The Importance of Including GraphQL Data in Your Layout Services Response
Hopefully now you understand that this not only has the potential to reduce your Vercel bill, but also improve the overall performance of your website since your users no longer need to wait for your SSR functions to call data or for your CSR Serverless function to return the needed data directly from Sitecore. This is a quick and easy way to improve your XM Cloud websites architecture!
