Automated logo rendering/visualization

[spenserblack]

Summary 💡

Started the conversation here, but my comment was unrelated enough that it should have been a new issue.

Basic idea is that we could have a solution to automate previews of the logos. This can probably be done with a serverless function.

Some things to consider:

• What tool to use for the serverless function. I've used Vercel, but there are plenty of options out there.
• We'll need the languages' color definitions to be available to the serverless function. We can do this in a few ways:
  • Convert the language definitions to a data format (e.g. JSON) so that a serverless function can read it. If we do this we can
    • make a proc macro to parse the JSON in the Rust code
    • use a build binary to generate the Rust code
    • either way we probably wouldn't want to do something that results in runtime JSON parsing
  • Add another binary to the onefetch crate, that will be able to import the language definitions and act as the serverless function
  • Export the language definitions with a minimal library and use a different crate for the serverless function. If we do this, a couple more things to consider (this can be influenced by the serverless utility and how it reacts to repository changes):
    • Should the serverless function be part of a workspace, in the same repo?
    • Should it exist in a different repo? (we probably want it in the same repo to listen for changes and be able to import the latest change from the main onefetch project)
• Does the serverless function render the HTML? It may be more efficient to generate HTML once and serve a static site, but we can dynamically generate HTML per request.
• Do we simply serve HTML, or should we have an API for the language stats? If we have an API, we can use a reactive library to read JSON and generate a preview. The API could be a simple api/language[/:name].

Also if we just generate the HTML once, we can actually just use GH Pages instead of a serverless tool. But one thing I've liked about Vercel is that it creates preview builds for PRs (see motivation).

Motivation 🔦

When reviewing PRs, currently we have to pull down the PR's changes and rebuild the binary to review any added or changed logos. This can be greatly simplified by making previews that are automatically generated, which can allow maintainers to review the logo even if they're not at their main device.

[o2sh]

I am very excited for this new feature 😃
I've been eyeing the onefetch.run domain name for a while now 😅

What tool to use for the serverless function. I've used Vercel, but there are plenty of options out there.

Vercel seems like a good choice (nice UI, good integration w/ GH).

We'll need the languages' color definitions to be available to the serverless function.

What if we had a build.rs that would serialize the content of the define_languages macro at compile time whenever there is a change to the language.rs file?

Does the serverless function render the HTML? It may be more efficient to generate HTML once and serve a static site, but we can dynamically generate HTML per request.

Generating the whole HTML content per request sounds fine to me. Performance isn't paramount for this feature IMO.

Do we simply serve HTML, or should we have an API for the language stats? If we have an API, we can use a reactive library to read JSON and generate a preview.

I am not sure I got this one. I thought the serverless function could be sufficient by directly returning the html content in its body with a Content-Type set to 'text/html'. But, I've never tried it, so I could be wrong.

[spenserblack]

I am not sure I got this one. I thought the serverless function could be sufficient by directly returning the html content in its body with a Content-Type set to 'text/html'. But, I've never tried it, so I could be wrong.

Here's a simple example of a Vercel app with an API (it's basically only an API 😆)
Basically, we can have a serverless "backend" and a frontend that renders the API's response. We may want to do this if

• we ever want another tool that can reference this data from the web (I have no idea what would, just throwing it out there)
• we want to use a routing library like React Router or Vue Router for the frontend. The benefit of this is that reroutes from a view-all / to a specific /:language wouldn't be a new request, and the API response could be cached on the frontend. That could result in less resources utilized by the serverless process, making it easier for us to stay on the free plan 😆

[spenserblack]

Oh, also, if onefetch is getting a domain do we want to set up a FUNDING.yml? onefetch.run looks like it's cheap, but it's not free 😆

[o2sh]

Oh, also, if onefetch is getting a domain do we want to set up a FUNDING.yml? onefetch.run looks like it's cheap, but it's not free 😆

Good point, but if it's just for the domain name, that won't be necessary.

Basically, we can have a serverless "backend" and a frontend that renders the API's response.

This may be too intrusive IMO. If we wish to have this code live in the onefetch repo, its footprint should be kept to a bare minimum which is why I liked the idea of a serverless function.

[spenserblack]

Good points.

TBH I'm thinking making the language definitions JSON might be best, much like how tokei does it. Besides making our language definitions easily readable by a variety of tools, it should make it easier to contribute. Many GitHub users already know JSON, and they won't need to learn our specific macro format. Switching to JSON can be a separate PR from setting up Vercel.

What if we had a build.rs that would serialize the content of the define_languages macro at compile time whenever there is a change to the language.rs file?

I've never actually needed to use a build.rs, so correct me if I'm wrong, but it will always run at compile time, right? So, for example, a user that does cargo install onefetch would have this build.rs run?

[o2sh]

TBH I'm thinking making the language definitions JSON might be best, much like how tokei does it. Besides making our language definitions easily readable by a variety of tools, it should make it easier to contribute. Many GitHub users already know JSON, and they won't need to learn our specific macro format.

I'm sold 👍 and we could go one step further and put the ascii logos in there too. As such we would have in a single file all the languages' metadata, allowing us to remove the *.ascii files in the resources folder.

And yes this should be done first and preferably in a separate PR.

[spenserblack]

🤔 If ascii will be contained in the data file, then perhaps it should be YAML. That has more readable multi-line strings.

[spenserblack]

Dev Notes / Some more thing to consider

• Use Vite as the build tool?
  • Can use either @rollup/plugin-yaml or @modyfi/vite-plugin-yaml to be able to directly import YAML as an ES module
• Switching between a white and a black background can be useful.

[o2sh]

🎉 onefetch.dev 🎉