DEV Community: dAppling

Poetry in Imagery • Meta Image Generation in Next.js

dAppling — Tue, 22 Aug 2023 18:15:48 +0000

When I stroll through the web without intention, every link, title, and image vies for my attention. With a goal in mind, those same links, titles, and images seem to lack dimension. I struggle to find the information I seek; behind each possible link lacking context, I'm left blind.

Meta tags of a website are a helpful guide. Used to share information about potential content behind a link, these small tags can hold enormous amounts of useful data. As long as they are used correctly, that is. I hope their use is expanded and can help and inspire creators to put more energy into their own site's images.

Essence of Representation

Meta tags provide glimpses into the content without requiring users to visit the page itself. These tags can articulate essential details like the title, description, and intended size of the site. Open Graph tags (og), introduced by Facebook, define a way to share a summary of the content, location data, media information, and more.

The tag for an arbitrary image, og:image, I think has the most potential. These images are not mere visual aids; they are the distilled essence of the web page they represent. A visual haiku. For our app dAppling, I wanted to follow GitHub's lead with a desire to give the user as much information as possible.

By way of example, GitHub's meta images. Explained more in their A framework for building Open Graph images article, the image succinctly and, in my opinion, beautifully explains what you will see before you see it. I love these images. From this little representation, I have been able to quickly gather information and confidently ignore or navigate into the site.

The Alchemist's Wand

Creating these visual haiku is a craft, a magical art. With tools like @vercel/og and Next.js, I started my journey.

A flick of the wrist and a small creation appeared

Each project, tied to a unique gradient, becomes recognizable at a glance. To look under the leaves, here's a gist of the generator. The examples above use different IDs:

top https://www.dappling.network/api/og?id=blog
middle https://www.dappling.network/api/og?id=dog
bottom https://www.dappling.network/api/og?id=bog,

Another gesture of the wand; a motion with emotion. Two new cards materialize. You can see the pretty gradient for each of them is consistent (The ID for the following two are meow).

Our beautiful project card contains a preview at a glance. The deployment card adds two more elements. You can see, without navigating to the site, if your deployment passed or failed. You can get the "verified" badge after someone signs the deployment, attesting its legitimacy.

The Poetry and the Pitfalls • Next.js

Now we come to the unfortunate story. I would love to say these things all worked perfectly, but the real-time creation of these images posed performance challenges. The metaphysical had to meet the physical world of server responses and loading times. You see, when apps like telegram, slack, discord, and the like try to get these images, the data must be created on the fly. This causes a few problems like, how do we get the information for the page on load?

This is solved by getServerSideProps, but also causes the performance hit. In the new app router, the generateImageMetadata function should work nicely. However, when browsing the site normally, one must wait for the metadata to load, even though they are not concerned with the meta image, after all, they're already on the site.

We scaled back, yet the essence remains. The images still capture the spirit, albeit in a more simplistic form.

Learnings and Such

Meta tags are first come first used. That means, if you have multiple meta tags on the page, it'll probably use the first one encountered. This confused me because instead of being able to define site-wide metadata, I had to use Next.js's <Head> element on every page.

<Head>
    <meta ...>
    <meta ...>
</Head>

Having an svg as a meta image will silently fail and ruin your day. Make them png.
Using metadata website checkers do not accurately reflect exactly what will happen on each individual social media platform. They all have their own way to display the images.
- open graph debugger - see if the images work
- meta debugger - view tags in chrome dev tools useful for duplicates
Using local metadata debugging does not accurately reflect the first load of your page. There is a chance the meta tags change as hooks return data. Keep this in mind when using extensions like localhost open graph debugger.
twitter: tags are used by more than just twitter.

The full list of image related tags used:

<meta property="og:url" content={url} />
<meta itemProp="url" content={url} />
<meta itemProp="image" content={imageUrl} />
<meta name="image" content={imageUrl} />
<meta property="og:image" content={imageUrl} />
<meta property="og:image:alt" content="dAppling" />
<meta property="og:image:type" content="image/png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="twitter:image" content={imageUrl} />
<meta property="twitter:image:src" content={imageUrl} />
<meta property="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@dApplingNetwork" />
<meta name="twitter:creator" content="@dApplingNetwork" />
<meta property="twitter:url" content="https://www.dappling.network" />
<meta property="twitter:title" content="..." />
<meta property="twitter:description" content="..." />

If I were to start over, the process simply is:
start ideating, sketching, and playing with the og playground until you have struck inspiration and want to start migrating to your actual code.
create either a new Next.js project or add the og endpoint to your existing project.
modify the meta tags of your site to include the dynamic url. e.g. https://www.dappling.network/api/og?type=project&id=${projectId}.
test with the tools above
cross your fingers

If you're interested in our exact implementation, the full code can be found in this gist.

The Art of the Web

Meta image generation is both a technical task and an art form. How one can translate the complex into the simple while maintaining beauty. Like a haiku captures a moment, a well-crafted meta image reminds that even in the technical world of web development, there's room for poetry, beauty, and a touch of the metaphysical.

Thank you for your time. If you need help, please reach out to me on telegram.

🙏❤️🌱 What a great day to be alive!

How dAppling uses Filebase

dAppling — Tue, 11 Jul 2023 15:00:26 +0000

At the core of dAppling, we both build code and host the completed app, ensuring a convenient experience for our users and one akin to centralized hosting for their users.

We interact with Filebase in two ways: putting things into the bucket and taking things out of the bucket.

Into the Bucket

In a way, we use 'storage' in the sense popularized by Amazon because Filebase supports s3 APIs to store content. When a build is complete, we generate build artifacts and upload them to Filebase via the API. Once this process completes, we receive a 'receipt' containing the content identifier (CID) or hash of the uploaded content. This CID is stored with the project for use later when content needs to be accessed.

This process is outlined in the following diagram in which a Uniswap developer wants to use dAppling.

Out of the Bucket

When it comes to content access, there are two main methods. Users can either directly access the content via the CID using their local IPFS node or a gateway, or they can use an auto-updating URL created by dAppling. This URL could be an auto-generated link such as garden-daisy.dappling.network, or a custom domain configured by the user, like ipfs.uniswap.org.

An aside of configuring a custom domain

In the first case of accessing the CID directly, the content may or may not be downloaded via Filebase. This is because some other IPFS nodes may have cached the content. However, if the content does not exist, the "pinned" files will be ultimately retrieved at Filebase's nodes.

In the second case, we use Filebase's gateway directly to retrieve the content.

How could this be improved?

Replace the Record Handling

Currently, we use a CDN in front of Filebase's gateway, which also functions as a CDN. This process appears to involve one extra step. But how else could we allow users to use a custom domain that maps to an updatable CID?

I think it might look something like:

Filebase handles DNS records somehow. I know it involves certificate provisioning, which is a bummer. It would be nice to request a domain ipfs.uniswap.org and have it return the records for a user to update.
Filebase allows updating the CID associated with the domain programmatically. So when the Uniswap code is updated, we can update the domain.

Subdomain gateways

As I detailed in my article about IPFS and resource paths, it's crucial to stay as close to the user's development environment as possible. Therefore, we stay away from anything hosted at a "path".

From consensys IPFS security article,

TL;DR: Path-based IPFS gateways have a critical flaw: They effectively disable one of the essential security features of modern browsers: the same-origin policy.

We therefore prefer having the user bring their domain to host, like using ipfs.uniswap.org, or our preview domain like garden-daisy.dappling.network. Because of this, we have sites that will not work on path gateways such as gateway.dappling.network/<CID hash>. We would prefer the gateway support the subdomain version a la <CID hash>.gateway.dappling.network.

It would be ideal if Filebase supported these subdomains as the access is much faster than any other gateway, but meanwhile we will direct our users towards a subdomain version like <CID hash>.ipfs.cf-ipfs.com

How to: IPNS on my Domain?

dAppling — Tue, 11 Jul 2023 13:27:29 +0000

First, why would you want this? IPNS is another way to access content on the IPFS network. Since the link to the content is set on the DNS itself, the attack surface is slightly smaller, as the malicious user would need access at the DNS level to be successful. Also, as it's closer to traditional website access, while also showing the user direct IPFS accessing of the content is happening.

There's more information about what's IPNS? as well as a great guide about how resolving DNSLink works, but I'll go over the steps in a very high-level manner here.

The next steps you can try yourself, and you should be able to see Uniswap's Interface at the end.

1️⃣ Get your CID for the site you want to share with users. It will look something like bafybeibngzztaxprxg6w423plup5kihnizu4t4fdcsq73wgqcayvjrxoaq.

You can use dAppling to build your code into a CID.

2️⃣ Go to your DNS provider and add a record to your domain.

Choose the domain you want the users to type in. Usually, the root domain makes sense.
Add a text record with the subdomain of _dnslink and the value set as dnslink=/ipfs/<CID>

TXT _dnslink   dnslink=/ipfs/bafybeibngzztaxprxg6w423plup5kihnizu4t4fdcsq73wgqcayvjrxoaq

If you want a subdomain, e.g. ipfs.example.com, the subdomain used would be _dnslink.ipfs

TXT _dnslink.ipfs dnslink=/ipfs/bafybeibngzztaxprxg6w423plup5kihnizu4t4fdcsq73wgqcayvjrxoaq

3️⃣ After set, you can direct users to the site via IPNS and a gateway. These would be accessible with a gateway, like Cloudflare, using their ipns path using subdomains (recommended):

or using paths (not recommended):

What are the downsides? For one, the record will not be updated if you push changes to your code. This will need to be either automated (if the DNS supports it) or done manually.

We do not currently try updating the IPNS record as we handle the CID resolution automatically when setting up a domain on dAppling, but we think IPNS is an interesting access point, and it's more accessible.

Hosting Static Sites on IPFS

dAppling — Fri, 30 Jun 2023 15:47:26 +0000

Well, I’ll start that IPFS isn’t special. It’s cool, yeah, but the problems faced when deploying sites to IPFS, discounting the potential loading time, and pinning issues, appear in any hosting environment. The root cause lies in how the resources to produce the webpage are accessed. When accessing a site through IPFS, one can think of it as a simple folder in the sense of a folder on one’s computer.

Absolute Paths - /some/examples

Local File System Example

Say you want to view your poker hand calculator web app. This existed on the web before, but you being the pragmatic data-saver, downloaded a local copy to your computer. The site was open source, after all. It’d be wrong to *not* keep an extra copy. Now how do you view it?

Search for the folder. It might be less successful on Windows. a. Realize you don’t remember the name and manually traverse your download folder. You know it’s in there somewhere. b. Ahh, there it is.
Open up the index.html page. Notice in the supposed “web” browser, the file appears as a weird-looking URL, or is it a URI…

And observe the page is… blank?

Well, yes, but that isn’t to say your file system didn’t try. You can see the requests made, and it’s a sea of red.

Why? Well, let’s look closer at a request.

The requested URL looks surprisingly even stranger.

Request URL: file:///_next/static/css/d22f27d70fc00611.css

So where did all of the rest of the URL go? Clearly, in the top bar, you can see

file:///Users/shire/downloads/cool-websites/poker-calc/index.html

The answer lies in how relative and absolute URLs request resources. See, inside the index.html file, our CSS file is requested with a beginning /. This instructs the browser to request a resource with an implicit domain name. Read more on MDN. So great, the CSS file is being requested with an implicit domain name.

<html>
  <head lang="en">
    <meta charset="utf-8" />
    <link
      rel="preload"
      href="/_next/static/css/d22f27d70fc00611.css"
      as="style"
    />
    </head>
</html>

Because there’s no domain name, the browser assumes the resource is at the root of my computer’s hard drive. You fool!

This does not work! Failure.

Domain Hosted Example

So assume our poker app also exists at https://pokercalc.app. When we visit the site, we implicitly request the index.html. That is returned, and, what? Everything looks good. The requests are going through. You look through the network requests again, and they look, normal:

Request URL: https://pokercalc.app/_next/static/css/d22f27d70fc00611.css

Ahh well, here’s where the implicit domain comes in with absolute URLs. The [pokercalc.app](http://pokercalc.app) has been implicitly added to the request and since the resource is also on the web server, the file is returned.

This works! Success.

Sub-Path Hosted Example

So what’s the big deal? Well, now assume the content, instead of being on https://pokercalc.app, has a summer theme hosted on https://pokercalc.app/summer. The same files will be requested, and the same requests again will be returned.

Even though clearly our top bar shows the correct website

https://pokercalc.app/summer

The request seems to have chopped off the summer path.

Request URL: https://pokercalc.app/_next/static/css/d22f27d70fc00611.css

Yet another victim of the implicit domain.

This does not work! Failure.

Relative Paths - More/examples

To save the day, we have relative paths. Again, more information on MDN. Walking through the same examples again, say we changed the HTML thusly.

<html>
  <head lang="en">
    <meta charset="utf-8" />
    <link
      rel="preload"
-     href="/_next/static/css/d22f27d70fc00611.css"
+     href="_next/static/css/d22f27d70fc00611.css"
      as="style"
    />
    </head>
</html>

Local File System

file:///Users/shire/downloads/cool-websites/poker-calc/_next/static/css/d22f27d70fc00611.css

Domain

https://pokercalc.app/_next/static/css/d22f27d70fc00611.css

Path

https://pokercalc.app/summer/_next/static/css/d22f27d70fc00611.css

And all of those requests are actually successful. Hooray!

These all work! Success.

IPFS

Remember how I said IPFS isn’t much different than a simple folder? Well, it’s a bit more complicated than that. See sites accessed on IPFS can be accessed via their Content Identifier (CID) in different ways.

Native protocol: ipfs://<CID>

Web gateway: https://ipfs.io/ipfs/<CID>

IPNS (web gateway): https://ipfs.io/ipns/<domain name>

Behind our CDN: https://preview-domain.dappling.network

And while all of these would appear to work with relative URLs, there is a catch.

The catch…

So we can’t just throw all of the URLs to relative and call it a day. Well, you can actually get close, and we did just that with a script aptly called replacePaths. Here are the replacements being made in the source code of the websites, and the full code can be found at this gist.

const replaceRules = [
  // Replace all absolute paths with relative paths
  // Replace src="/example" with src="example" and href="/example" with href="example"
  // Replace url("/example") with url("example")
  // Replace src="/example" with src="example"
  // Replace href=\"\/example\" with href=\"example\"
  // Replace href: \"\/example\" with href: \"example\"
  // Replace href: "/example" with href: "example" and path: "/example" with path: "example"
  // Replace all /_next with _next
]

How could this possibly fail? Well, besides modifying the source files with some basic string replacements and hoping for the best, there exists some nuance in NextJs and React routing.

Routing in React

I specifically looked into the NextJs router for this, but the React router should behave similarly. For every link on the page that is clickable, there is a destination. These again are going to be relative or absolute URLs and note that fully qualified domains like https://example.com are also considered absolute URLs. There are also local browser states that are handled with functions like Router.push which change the page content AND modify the URL in the top bar. Lucky for us, these are somewhat easy to think about as they follow the same patterns of relative and absolute URLs.

For example, if we are on the page [pokercalc.app/texas-holdem](http://pokercalc.app/texas-holdem) and we have a button that will push the state to /games, the browser will happily change the bar to pokercalc.app/games. Good, right?

Wrong!

What if we were hosting this on a different path, say pokercalc.app/summer/texas-holdem, and then tried pushing /games? Well since the URL is clearly “absolute”, we get what we expect: pokercalc.app/texas-holdem. No summer theme is to be found. The implicit domain strikes again.

But what about basePath?

`basePath`

Good though, myself from a second ago. The NextJs config option basePath is made specifically for this. It’ll prepend all of the links with the specified basePath. Hooray!

but wait…

Remember how we don’t know **where** our website will be accessed? How are we supposed to choose our basePath at build time? Well, you simply cannot.

There’s a GitHub repo with these things that I failed to find, but the basic idea is to change the code to make the site work wherever it is hosted.

inject a base into the document which will set the actual URL to a node on the document, accessible throughout the app.

const scriptTxt = `
(function () {
  const { pathname } = window.location
  const ipfsMatch = /.*\\b(Qm[1-9A-HJ-NP-Za-km-z]{44,}|b[A-Za-z2-7]{58,}|B[A-Z2-7]{58,}|z[1-9A-HJ-NP-Za-km-z]{48,}|F[0-9A-F]{50,})\\//.exec(pathname)
  const base = document.createElement('base')

  base.href = ipfsMatch ? ipfsMatch[0] : '/'
  document.head.append(base)
})();
`;
// .. 
<Head lang="en">
  <script dangerouslySetInnerHTML={{ __html: scriptTxt }} />
</Head>

Now I don’t know if this is simply a bad way to pass around a variable or if NextJs does something internal with it.

Replace all links with a new component that actually uses the link:

const BaseLink = ({ href, as, ...rest }: LinkProps & BaseLinkProps) => {
  console.log("BaseLink", href, as);
  const [newAs, setNewAs] = useState(as || href);

  useEffect(() => {
    if (newAs.startsWith("/")) {
      let baseURI_as = "." + href;

      if (typeof document !== "undefined") {
        const url = new URL(href, document.baseURI);
        baseURI_as = url.href;
      }

      setNewAs(baseURI_as);
    }
  }, [as, href, newAs]);

  return <Link {...rest} href={href} as={newAs} />;
};

Change how the Router pushes as well. There is a possible solution that admittedly I didn’t follow to fruition. I stopped because I think the internal routing table, I believe Next has a way to map these routes to the javascript to load, but altering that file does not seem to be the approach. This is what I tried anyway, but I think I’m misunderstanding how routing works.

export function basePathPush(path: string, as: string = path, options?: any) {
  let newAs = as;
  if (!newAs.startsWith("http")) {
    newAs = "." + newAs;
    if (typeof document !== "undefined") {
      console.log("basePathPush newAs.startsWith document", path, as);
      newAs = new URL(newAs, document.baseURI).toString();
    }
  }

  return Router.push(path, newAs, options);
}

A Table?

	Absolute Paths	Relative Paths	NextJs Routing
ipfs://	Maybe. Haven’t tested recently	Works for assets	Maybe
https://ipfs.io/ipfs/	Definitely not	Works for assets	Works for some navigation.
https://ipfs.io/ipns/	Definitely not	Works for assets	Works for some navigation.
https://preview-domain.dappling.network	Definitely	Definitely	Definitely

So, clearly, the CDN version works fine, but we should have already known that. We’re hosting a static website through a domain. Absolute paths work how they should, and relative paths work how they were designed. I say designed because when developers are developing there is an implicit assumption of this running from a domain.

Examples

Just to round it out, here are some examples to show what I was telling up there.

The site doesn’t work

There was useEffect on the first load that would cause the app to start off in a bad state.

const FixedYield: NextPage = () => {
  useEffect(() => {
    Router.push("/smart-yield/pools/");
  }, []);

https://cloudflare-ipfs.com/ipfs/bafybeiab75ag4g7qgdhfkkx454y72ubkrgd7jadhk4ipnndkbtpa2cluoy/

Absolute pathing

https://cloudflare-ipfs.com/ipfs/bafybeihje65wpty2ecibevbc7o3nwu7vnbhdn6xua5d5p4ni44fipn6ppe/

Here’s an example that has absolute paths. 404s galore.

Relative pathing

https://cloudflare-ipfs.com/ipfs/bafybeighrlepp5pdmdcxir3zpwl2cjmdb6jma5danb3ex7i76ornmn6mbu/

Here’s an example that replaces absolute paths with relative ones. You’ll see the sub-nav works, but re-writes the URL. The top nav doesn’t work. Not sure why.

Changes

Here is a full preview of my changes. Still doesn’t quite hit the mark but might be a good place to start. Might need access from me to see.

https://github.com/Namaskar-1F64F/barnbridge-v2-frontend/commit/9770763297375d0f6f37f569d9a5679b47a53b55

What did we learn?

I don’t know about you, but I learned IPFS can be thought of as a website accessed on a path on a domain. One needs to consider that the URL will not be known at build time and it seems like the best option right now is just simply shoving the whole situation into a familiar box. By using a domain and serving the IPFS content behind our CDN, we make the websites as the user expects.