Support Open Graph metadata

[galrito]

Hello, this post was initially written on feedback.azure.com, but since this is the official channel for feedback on Azure Static Web Apps, I'll post it here as well.

I've been using and loving Azure Static Web Apps since its announcement. Recently, however, I came across a requirement that I believe is quite common: adding Open Graph meta tags on the HTML.

As you know, Open Graph tags are a way to describe to social networks the contents of a URL to have a seamless experience in the social networks' platforms. In some cases, especially if the content you want to describe is dynamic, this poses a problem for frontend frameworks, such as Blazor Web Assembly and React.

Using the example of opening a blog post at https://www.example.com/posts/1, what a social network will see is the HTML of "index.html", because a frontend framework requires JavaScript to work in order to present the correct post details page, resulting in an HTML without the proper Open Graph tags.

With the way Azure Static Web Apps currently stands, we can almost have this working this way:

1) User visits https://www.example.com/posts/1 2) Configure a redirect on hosts.json from "/posts/1" to "/api/posts/1" 3) The posts service on "/api/posts", grabs the contents of index.html and the contents of the post with the ID 1 and injects all the Open Graph metadata on the HTML. Then serves the contents of index.html with the injected HTML. 4) The frontend framework loads through the contents of index.html (still on the URL "/api/posts/1") and redirects through JavaScript to "/posts/1" to present the post itself.

Since "index.html" is presented with the correct Open Graph tags, a social network can have all the required information to create that seamless experience to the user.

I said we could almost have this working because the problem lies in point two above. This could be solved if routes.json allows us to have patterns for the redirects to the API, like so:

{
   "route": "/posts/{postId}",
   "serve": "/api/posts/{postId}",
   "statusCode": 301
}

Another way to solve this, which would even be better, is to allow us to define proxies in routes.json. That way, we could even get rid of point four above.

Sorry for the long post. Thank you.

[miwebst]

Hey @galrito! Thanks for reaching out, we will take a look at trying to unblock you on this. As for the comment on proxies do you just mean going from /posts/{postId} -> /api/posts/{postId} without redirecting?

[galrito]

Hello @miwebst. Yes, exactly. Similar to what we have on Azure Functions.