Create Vercel app for onefetch with ASCII preview

[spenserblack]

At the time of creation of this PR, there is absolutely nothing notable, hence why it is starting as a draft. I am creating this before any significant code is contributed so that I can document the steps as I go through them.

Setup

1. Create a Vercel account at vercel.com and link it to GitHub
2. Create a new project
   • set repo to onefetch
   • change the root directory from ./ to vercel/ascii-preview vercel/
   • set the framework preset to Vite
3. Change the domain in project settings(?)
   • My current URL is https://onefetch-spenserblack.vercel.app/

Resolves #696

[spenserblack]

I think I'll end up using TypeScript for this (using Vite as a build tool). Before I set up the preview, @o2sh do you have a preference between vanilla JS, React, Vue.js, Svelte, or anything else? I've used Vue.js and Svelte before (and obviously vanilla JS 😆), but I'm happy to use any tool that you and the team feel most comfortable with.

[spenserblack]

Also, if we ever want other serverless onefetch web services, maybe it makes more sense to make the root directory vercel/ instead, and /ascii-preview can be an endpoint instead.

[codecov-commenter]

Codecov Report

Merging #701 (7b8a2ea) into main (debd453) will increase coverage by 0.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #701      +/-   ##
==========================================
+ Coverage   13.36%   13.53%   +0.17%     
==========================================
  Files          19       19              
  Lines        1160     1145      -15     
==========================================
  Hits          155      155              
+ Misses       1005      990      -15     

Impacted Files	Coverage Δ
src/info/mod.rs	0.00% <0.00%> (ø)
src/info/repo.rs	16.66% <0.00%> (+1.32%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update debd453...7b8a2ea. Read the comment docs.

[o2sh]

This folder may need to be added to the exclude section of the Cargo.toml file.

[o2sh]

Before I set up the preview, @o2sh do you have a preference between vanilla JS, React, Vue.js, Svelte, or anything else?

Why the need of a front end framework/library for a serverless function?

Also, if we ever want other serverless onefetch web services, maybe it makes more sense to make the root directory vercel/ instead, and /ascii-preview can be an endpoint instead.

Aren't Vercel's serverless functions supposed to be placed in the /api directory of the project's root. https://vercel.com/docs/concepts/functions/serverless-functions#deploying-serverless-functions

[spenserblack]

Why the need of a front end framework/library for a serverless function?

For ASCII previews itself, no big reason, just that it might be a bit easier to parse data into a template this way. Also, reactively changing the background from dark to light can be useful. While not impossible without a frontend framework, it's a bit easier, and also more readable for other potential contributors. Though if we decide to use any framework now, this simplifies adding anything else to a serverless web service. For example, #459 (comment) was suggesting moving the wiki to gh-pages, but something very similar can be accomplished using Vercel instead. Though I have no strong feelings, and would be happy to implement this with Vanilla JS (no frameworks/libraries).

Aren't Vercel's serverless functions supposed to be placed in the /api directory of the project's root.

Well, the serverless function don't need to be in /api. For example, github-profile-trophy is basically a single serverless function run with Deno that returns an SVG, and this serverless function exists in the root. E.g. https://github-profile-trophy.vercel.app/?username=o2sh (congrats on the achievements 😆 )

Personally, I'd put machine-readable responses in /api[:/endpoint], and human-readable responses anywhere else. We can split this up into, let's say, /api/languages which serves a JSON-ified version of languages.yaml, and /ascii-preview that fetches and consumes that JSON.

I think I may have been incorrectly using the phrase "serverless function." I was using it as a catch-all for static sites as well. Sorry for the confusion.

[o2sh]

While not impossible without a frontend framework, it's a bit easier, and also more readable for other potential contributors. Though if we decide to use any framework now, this simplifies adding anything else to a serverless web service.

You're right about the need of being future proof.
I'm always anxious about bringing unnecessary complexity to a project. 😩
Concerning your original question - which framework/library to use -, you can pick the one you feel most comfortable with and is most adapted to the feature. I have a small preference for (Svelte + TypeScript) 😉 .

Personally, I'd put machine-readable responses in /api[:/endpoint], and human-readable responses anywhere else. We can split this up into, let's say, /api/languages which serves a JSON-ified version of languages.yaml, and /ascii-preview that fetches and consumes that JSON.

If we're adding folders to the project's root, we should keep it to a minimum. For example, a single folder named tools - or another name that better illustrate our intent - which can then hold as many folders as we consider necessary.

[spenserblack]

If we're adding folders to the project's root, we should keep it to a minimum. For example, a single folder named tools - or another name that better illustrate our intent - which can then hold as many folders as we consider necessary.

Oh yeah, right now I'm planning on putting everything in vercel/, so vercel/api/, vercel/index.html, etc. I think that's what you're saying you want, right?

[spenserblack]

So I may have gone overboard 😆

Preview is at https://onefetch-spenserblack.vercel.app/

[o2sh]

TypeScript is really giving me a hard time with this import 😓

seems like it doesn't want me to import a file that is one level up from its root path 🤔

[spenserblack]

TypeScript is really giving me a hard time with this import

I had that issue too, which is why I caved in and made the YAML -> JSON a build step. TypeScript natively supports importing JSON, but the YAML import is handled by a Vite plugin, so I'm not sure if the TypeScript compiler is aware of that.

I think something like this might be necessary.

// types.d.ts
declare module '*.yaml' {
  const data: Record<string, any>;
  export default data;
}

[spenserblack]

c93ef82 Resolved the type errors for me (running npm run check).

[spenserblack]

🤔 I wonder if running npm run check should be made part of the CI. npm run build would be asserted by Vercel, so that might not be necessary.

[spenserblack]

😢 Looks like nightly had a change that broke the CI.

[o2sh]

I think the PR is ready to be merged 🎉

Maybe we can wait for gitoxide to fix the build issue 🤔 their CI is also failing

[spenserblack]

Since this has been modified by us, we might want to add a comment here just saying so. We don't need to, but it might be helpful for someone stumbling on this.
Sorry, ignore this, I didn't see 0179115 and thought that the colors were changed manually.

[spenserblack]

I think the PR is ready to be merged

I think so, too! I'm fine to wait until the CI is fixed. Thanks for all your work updating the styling, simplifying the logic, etc.!

[spenserblack]

🤔 Maybe we should add vercel/ to CODEOWNERS.

[spenserblack]

Should onefetch.dev be listed as one of the sites using sakura.css?

[o2sh]

Sure! that's a good idea 👍

[spenserblack]

oxalorg/sakura#97