One of the best ways to increase traffic to your site is to provide high quality social media embeds for your routes. As an example, here is how a lesson from Boolean art looks like. If we shared it on various social media platforms. The first thing that you need for this is the ability to dynamically create images. Fortunately, next year comes with an image response, API, which we've also previously looked at in its own lesson. We have a product website that has different pages for the various products, and if anybody shares one of these product pages on social media, we want to create a high quality preview. We could generate this image from scratch,

but to save us time and give us more creative freedom, it is conventional to use a background image to give us a good starting foundation. You can provide multiple images with different resolutions if you want, but here is a pro tip. The ideal resolution for a preview that works well across all the platforms is 1200 by 6 3 0, so we can keep our lives simple and only generate one image. With this resolution, we place the base background as well as font files within the public folder, and we know that we will be able to access them using the node js file system API, which is something that we also covered in our lesson

on image response. Now, the page that we are going to be generating, the image four currently sits at product slash sku, and since I'm a big fan of colocation, as it helps developers understand the code base a bit better, we create a new route in a sub folder called metadata image, and this new route will no surprise return. The metadata image for this page here is a quick preview of the kind of image responses we want to generate from this route. Now, before we start working on this route file, let's build a few more image response components as they will make a final code look a lot more clean and easy to understand.

The first component that we build is an image response overlay, which is nothing more than a simple sex box div absolutely positioned with top, right, bottom, and left properties. So we build a component that accepts these props. Of course, you could just pass these props to the style attribute on a div yourself, but having well-named components can help people understand your intent and help you maintain your code in the future within the rendering of the component. This is nothing more than a simple div with the style attributes wide in based on the props, this component will allow us

to easily create a safe rendering zone within our background image. Most layouts can easily be broken into rows and columns, so for that purpose, we first create a very simple image response row, which is nothing more than a display flex with sex direction row. And we also take in a gap property that helps us create space between the children. Just like the image response row, we create an image response column, which is pretty much exactly the same. The only difference over here will be that the flex direction will be set to column with these layout components out of the way. Let's also create an image response text component.

This is the simplest component among all of these, and it serves two purposes. First, within an image response, each day of needs to have either display flex or display none. So it keeps us from having to type this style again and again. And the second advantage of this component is that it makes it easy to see when we are placing text on the image, which can help with maintaining the code base and also help with debugging if you ever require it. With these components created within our metadata image route file, we start off by exporting a get handler that gets passed in the pairs based on the route. The first thing that we do is we await these patterns to get the product sku,

and then we fetch the product from the CMS by using this queue from this get handler, we need to return an image response and we start off with a very basic one, which simply renders the metadata background, the image response route and the image response. Full background image are simple components that we build in our image response lesson. The resolution of this image response will be the same as the resolution of the background image, which is 1200 by six 30. And finally, we provide the custom phones, which is also something that you already know. Thanks to the lesson on image response with this skeleton file created, we should be able to see a basic image that has our metadata background.

If we visit this route, the route for this image response is simply the route for a product with metadata dash image added at the end. As you can see, the image is showing up as expected, although it's probably looking better on my screen than on yours because of video compression. The previews that we are creating are static images, so they will look fine in real life unlike their video recording with a base route created. Let's focus in on the rendering of the image response. All that we need to do is to render three simple pieces of text, and for that purpose, we start off with an overlay that gives us the safe area where we can render the content.

It has a header that contains the icon in a title in a simple row, so we bring in the row component and then render the icon followed by the title. The only thing that's left to do is to render the description under this header, and for that purpose we create a new column and then we render the product description into this column. And that's all we need for our metadata image, so let's test it out in the browser to make sure that it's working. As expected and no surprise, we now have a generated image that is ED to the content for that page. Now that we have the ability to create dynamic images for social media, the only thing that's left to do is

to add them to the metadata for our routes using techniques that we learned in our metadata lesson. For this, we jump into the page for our product, and over here we need to export the generate metadata function. This will be passed in the parents as a promised, just like the page component. And from those pairs, we will get the SKU and then fetch the product details from the CMS by using that sku. Now that we have the product details, we need to return the metadata from this function. The first thing that we do is we create an object that contains the image details for the metadata image that we are going to embed in the final result.

For this, we need to provide the URL for the route that will return that image response. And a neat trick over here is that we will use the base URL, which is a concept that we learned in a previous lesson. Now that we have the image details, we will return the metadata starting off with the title and the description that we fetched for the product. Now let's put these image details into action, and for that purpose, there is a standard called open graph, which is supported by most social media platforms. Here we need to provide the title, the description, along with the site name and the image details. Most social media platforms support the open graph meta

tag, however, Twitter is a bit special and it expects to be passed meta tag specific for their platform. Fortunately, the Twitter meta tag are also supported by next JS as a part of its metadata configuration. We just provide the same values under the Twitter key, along with an additional property called card, and the type that corresponds to the standard open graph style expansion is summary large image. Note that there is a lot of duplication over here, and I encourage you to build a utility function that takes just a few properties like the title, description and the image details, and then builds this status structure for you.

With these changes in place, if you visit our product page and then open up the developer tools within the HTML head, you can see the new meta tags being added. A question you should have at this point is how can you test these without having to deploy your site and then manually sharing it on social media to see if they've worked or not. While deploying to a staging environment is something that I would still recommend, however, you can run a local tunnel to expose your dev server to the internet with the generated URL, and this will allow us to test if it's working as expected using our development machine. Before we continue, we need to modify our base URL

to use this generated URL. This is also something that people wouldn't need to do if you were using a preview environment. We can visit the generated URL and verify that the product page is showing, and once we have this URL for the product page, you can use a number of third party services to check if your social previews are working, and I will leave links to a few of these services in the lesson description. And over here you can see what our product page would look like if it was shared on Facebook or it was shared on Twitter. If it works on these two, it'll most likely work on other social media as well.