Feature: Social Card for shareable insights

[bdougie]

When sharing an insights page on social, we need to generate a social card on demand. Similar to how GitHub powered to social cards.

https://github.blog/2021-06-22-framework-building-open-graph-images/

Figma

Cards needed

• Profile (Share button should get added to profile)
• Insight Pages (related Feature: Share button #686)
• Highlights (waiting on feat: add highlights to user profile page #859)

https://www.figma.com/file/OpVX6WT7dmWqnwRuEvADMF/OpenSauced-%E2%80%94-Insights-(insights.opensauced.pizza)?node-id=6756%3A8597&t=PKXNvKud1Q5bXoAU-0

[chhristopher]

This should definitely be prioritized (mid-high) as the ROI on something like this has the potential to take off.

[getaheaddev]

Here are the figma files for the completed designs

https://www.figma.com/file/OpVX6WT7dmWqnwRuEvADMF/OpenSauced-%E2%80%94-Insights-(insights.opensauced.pizza)?node-id=7000%3A9501&t=a9Q9y1MLgIkB8NMR-1

[Deadreyo]

I'll need guidance on this issue.

Is this a frontend issue, or a backend issue? The github blog associated described making a new backend service to generate the images, so are we going that route, or how are we doing this?

[bdougie]

I'll need guidance on this issue.

Is this a frontend issue, or a backend issue? The github blog associated described making a new backend service to generate the images, so are we going that route, or how are we doing this?

GitHub is not using NextJS. This is a frontend issue, but I'll need you to do the research on this to confirm that (brought this up in the eng sync last week). We have this working in the landing page. As far as guidance, this is working in the landing page open-sauced/landing-page#102.

Feel free to ask @shamimbinnur here or in slack on context on the approach, but the PR should walk through it well. Start with user profiles as the first PR to get the structure down.

insight pages should be approachable based on your previous PR #835 and Highlights will need a Permalink before we can start that - #895

[0-vortex]

I'll need guidance on this issue.

Is this a frontend issue, or a backend issue? The github blog associated described making a new backend service to generate the images, so are we going that route, or how are we doing this?

GitHub is not using NextJS. This is a frontend issue, but I'll need you to do the research on this to confirm that (brought this up in the eng sync last week). We have this working in the landing page. As far as guidance, this is working in the landing page open-sauced/landing-page#102.

Feel free to ask @shamimbinnur here or in slack on context on the approach, but the PR should walk through it well. Start with user profiles as the first PR to get the structure down.

insight pages should be approachable based on your previous PR #835 and Highlights will need a Permalink before we can start that - #895

Unfortunately the technique used in the landing page does not scale to our existing requirements, all the links in this issue use one form of opengraph layout generator and then feed different content to it - that results in an image that requires hosting (on demand generation is a better term) and caching, which will not be handled by the insights project.

There are multiple concerns to this, not necessarily storage and caching related, but how we treat modifications and regenerations of this image. With image regeneration we can then deploy it as a lambda hosted worker, 100k requests per day free or 10m / $5 and unlimited for $50. In this lambda function we don't care what technologies we use to generate the image, just the end result.

Infra decisions here impact the code a lot, but starting a bare bones wasm node server project and generating the image can be done very quickly like one stream / half a day maybe for people doing image generation for the first time (read api for user/highlight, run node script.js to generate image locally), we deploy that and the frontend only gets an "opengraph image URL" endpoint similar to the API ones, drop the link in the head and that's it.

The frontend should only have a social card backend and some endpoints for different opengraph image types (user, highlights), essentially the stuff GitHub doesn't provide. All those links would be static pngs like https://opengraph.opensauced.pizza/highlights/natemoore/{number}.png while everything else is https://github.com/open-sauced/ops-backend/issues related

[shamimbinnur]

@Deadreyo In this case I think we can try the satori library to achieve the on-demand Social Card image.

Since next.js allows server-side rendering, our procedure could be -

1. Write all the code for generating images on getServerSideProps()
2. Fetch the metadata of the insights page.
3. Pass through that metadata to Satori to generate an image.
4. Store the generated image somewhere in the database. Retrieve the URL of the generated image from the database and add it to the HTML meta tag.
5. We can store the metadata of the insights page along with the Social Image so that we can keep track and check before generating the Social Image again for avoiding image regeneration.

It is just a straightforward process, I don't know how much time it will take to generate the image on the server side. It's just a next.js native process, maybe we can find out a better way.

I would love to hear from @bdougie @brandonroberts @0-vortex

[bdougie]

I think @0-vortex laid enough to consider what should be in the final solution. We don't need a custom https://opengraph.opensauced.pizza/server just yet, but I would love to scope up to that out.

I opened the op's issue to explore that more - https://github.com/open-sauced/ops-backend/issues/22

re: What should we ship today?

Satori + getServerSideProps() seems like a viable path to explore today. I assumed this was a Vercel-only service, but that is not the case.

@Deadreyo please proceed with Satori and report back if it is viable.

We don't need to explore Cloudinary since Satori does this part. But, my other suggestion was that we already pay for Cloudinary and follow this approach - How to Generate Personalized Social Media Cards. Again only sharing to reference as an alternative.

[Deadreyo]

4. Store the generated image somewhere in the database. Retrieve the URL of the generated image from the database and add it to the HTML meta tag.
5. We can store the metadata of the insights page along with the Social Image so that we can keep track and check before generating the Social Image again for avoiding image regeneration.

Which database? Is there one that we can use?

[0-vortex]

4. Store the generated image somewhere in the database. Retrieve the URL of the generated image from the database and add it to the HTML meta tag.
5. We can store the metadata of the insights page along with the Social Image so that we can keep track and check before generating the Social Image again for avoiding image regeneration.

Which database? Is there one that we can use?

We are unable to directly connect to the database from the frontend, ever.

All attempts at doing this in the frontend are more effort than doing it in the backend, because at best, the frontend is generating the image in a server function just to send it back to the backend (why not just do it in the backend?) or store it on some 3rd party instead of in our infra.

The https://opengraph.opensauced.pizza/ endpoint was hinting towards the fact that it can be done in another repo rather than https://github.com/open-sauced/api.opensauced.pizza but it still involves a server instance that we own.

[Deadreyo]

@bdougie I do agree with Ted. I think this is a problem that should be addressed in the backend, as the frontend solutions wouldn't be good IMHO. Like for what Ted's explained, if I implement it in the frontend then I would re-create the image on every single request (vs caching on backend), and possibly more issues.

[Deadreyo]

Update: Finished a Proof of Concept experiment with NodeJS & Satori for this issue: https://github.com/Deadreyo/satory-experiment

[bdougie]

With the proof of concept working, what is the next step for getting this to production?

[0-vortex]

With the proof of concept working, what is the next step for getting this to production?

Implement static file/hash checking, on slack we discussed doing static-server-folder-or-bucket/{owner}/{hash}.png similar to github, but this is mostly tied to the image regeneration and data revalidation strategy we want to have for these social cards. We can already consider deploying this on different infras and start building the visuals for them 🍕

[Deadreyo]

Linking the new repo made for this (currently private): https://github.com/open-sauced/opengraph.opensauced.pizza

[bdougie]

Linking the new repo made for this (currently private): https://github.com/open-sauced/opengraph.opensauced.pizza

Do we have a plan on how this new service can be leveraged to generate social cards?

[Deadreyo]

Linking the new repo made for this (currently private): https://github.com/open-sauced/opengraph.opensauced.pizza

Do we have a plan on how this new service can be leveraged to generate social cards?

Yes.

cc @0-vortex can explain it better & more accurate than I can

[0-vortex]

Linking the new repo made for this (currently private): https://github.com/open-sauced/opengraph.opensauced.pizza

Do we have a plan on how this new service can be leveraged to generate social cards?

Yes.

cc @0-vortex can explain it better & more accurate than I can

We are following the same system as https://github.blog/2021-06-22-framework-building-open-graph-images/ with the quirk github enables the hash to regenerate the image as long as it's not a simple number and following the hash - we will do something similar, hashing the "latest" generation (we set a custom minimum update schedule here my suggestion 6-24h) in the database users table as the exact static S3 result, enabling the user information to be up to date whenever anyone generates (in real life access the image), however they cannot spam it.

For this purpose the functional existing social backend had to be split into 3 functions, this PR covers essentially the generation and image UI, functionally ready, just the color improvement but can be done separately. Been slow with upgrading this to the API functionality but that is the plan, on top of this PR, hook the API users module and architecture with added envs for S3 (hosted on digital ocean). Am trying to do this since Tuesday last week in the alpha branch of API, trying to drop that work tomorrow and upgrade the open graph from alpha so it doesn't block any of our other features like reactions.

Personally not happy with the slowdowns I caused here, but the end result will be solid and ship next week 😓

TL;DR: the social generator absolutely needed to be hooked to the database, cross-fetching and creating semi-public routes in the API is IMHO more security concerns than time lost, but feature-wise the time lost would be higher if we don't do this. Other benefits are the same workflow as insights, enabling us to rapidly prototype the other social cards or improve on the user ones for now! 🍕

[nickytonline]

Some hopefully constructive feedback. The font for projects at the bottom looks good, but the font for the name seems a little plain.

Also, it’s not my strong suit, typography, but a different font for the name could make the social card pop more and it'd be nice to make the OpenSauced logo more prominent, or indicate in some other way that this is an OpenSauced property and not a GitHub property.

https://opengraph.opensauced.pizza/v1/users/nickytonline

[0-vortex]

Some hopefully constructive feedback. The font for projects at the bottom looks good, but the font for the name seems a little plain.

Also, it’s not my strong suit, typography, but a different font for the name could make the social card pop more and it'd be nice to make the OpenSauced logo more prominent, or indicate in some other way that this is an OpenSauced property and not a GitHub property.

https://opengraph.opensauced.pizza/v1/users/nickytonline

Applied a couple of fixes, this is the current beta, pending a production release:

It's using all tailwind classes and design configurations from insights

Generated with http://beta.opengraph.opensauced.pizza/v1/users/nickytonline api -> https://opengraph-dev.sfo3.cdn.digitaloceanspaces.com/users/833231.png shareable social card

[Pranav-yadav]

Cross posting from discord:

Hey everyone! bit late here. It looks awesome, especially the visual repo insights at the bottom of the card. 🙌

But, I think cards are looking "bit Empty".

NOTE: I know, I might not be knowing the complete context about this feat.; though few suggestions (with some having future scope).

Suggestions:

It would be awesome to see:

1. a short ~ 1 or 2 lines of bio (from GH profile) in the empty space; with small yet visible font size.
2. The font size of the full name may be decreased a bit.
3. GitHub icon followed by respective @username for better accessibility 😉
4. [1 or 2 other socials, same as above] — again this might need to consider the space that we want fill (shouldn't be overcrowded); with small yet visible font size.
5. For always dark mode users, like me :), all white (light-theme) cards may cause some strain on eyes. How about extra theme param in url?;

theme=dark ==> Card with Dark theme.
keeping light as default. 

6. TBA 😉

What are you views?

[bdougie]

cc @getaheaddev take a look and let us know what you think.

[getaheaddev]

looking now

[github-actions]

🎉 This issue has been resolved in version 1.52.0-beta.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 1.52.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀