Devlog: March 8, 2023
I have no idea what I’m doing.
I’ve been working on the ScreenCred website. It’s pretty simple—homepage, privacy policy, changelog, etc. Oh. And I need to dynamically generate go:images for when you share links from the app. Need might be strong, but I really, really, really want that. The problem is, puppeteer—the library I’m using to generate images—needs a bit of memory. That complicates things.
11ty on Netlify
Wanting to try some new things, 11ty with Netlify Builders was my first stop. All the content pages were simple and straightforward. I even made a Netlify Builder to generate the the og:images. But it’s slow. Like 10s slow. See 2023-02-11 devlog.md for more about getting this setup.
Node
My next thought was to offload the og:image generation to another service. I made a simple Node/express server to do this. Then I threw spaghetti at the wall until I ended up with a Dockerfile that I could use to host it on fly.io. I decided to try out fly.io because it’s free. And Docker seems like something I should learn.
This solution actually works pretty well. And if I’m smart, I should probably stick with this.
I am not smart.
Astro
I’ve been wanting to give Astro a try. I saw that they support endpoints with SSR. That got my wheels turning. I could keep everything together. It will pre-render pages like the landing page and privacy policy, but then will use SSR to generate my search pages, with an endpoint to generate og:images. So far, I’ve enjoyed working with Astro. Fits my mental model pretty well.
I got things working locally pretty quickly. Aside from some small issues1, it was smooth.
Then I started on deploying it.
I started with again throwing some Dockerfile spaghetti to try and get things to work with fly.io. I eventually got it working, but for some reason, puppeteer kept running out of memory. Strange because it’s all the same code from my standalone Node server. Possibly because this is using Node 16 instead of 14? I’m not sure. I bumped up the memory on the machine for a few minutes to test, and that worked. Cool. But I don’t want to spend money now and you only get a 256MB machine for free.
I have a Synology in the closet…
After some time figuring out how to export my image to upload to my Synology, I got it running. I’m running Cloudflare tunnels to connect to some services on my Synology, so it was fairly simple to connect to this new Docker container running my Astro Node server.
Then I was getting:
Error: Expected an exported Astro component but received typeof undefined
What? Everything was working, why is it not working?
After a couple hours, I found the issue to be a link in the HTML head to a favicon that did not exist. Removed that, and it all worked. Woof.
Oh wait, an environment variable is not loading. Still haven’t figured this one out. I tried everything I could think of, but Astro (or Vite?) would not pick up the environment variable. I just hardcoded it for now. Maybe I’ll figure it out later.
What Now?
So anyway, that’s where I’m at. Deciding between fly.io and my Synology. I could also throw it up onto my Linode. Or something else entirely. But I don’t want to spend too much/anything since this app will probably make me negative dollar bucks. But I at least feel good that I have options.
I’m thinking Astro with SSR is a better solution that 11ty and builders for me. Because of the nature of the app, I’m guessing most share links will be unique. So I don’t gain a lot by using Netlify builders, which caches the results. In fact, it would probably be slower in most cases because of the time it takes a builder to spin up. So seems like a good fit for SSR. That being the case, I could look into other solutions, but Astro seems to be a great fit. I like the philosophy and I don’t have to learn too many new things to use it. I’ll keep my eyes open though.
I was having some TS import issues, but it was because I forgot a
/*in the path. Classic.↩︎