Fetch image data over the internal ALB (#14)

The satori renderer fetched its payload from the public site, which meant
going out through Cloudflare and needing this lambda's NAT address
allowlisted to get back in. That coupling is what left every image
timing out for four days when bot mitigation was turned on, and it would
do it again the next time the rules are tightened.

/spi is already internal-only - the public ALB fixed-responds it, the
internal one forwards it to Rails - so pointing at internal.exercism.org
keeps the request inside the VPC. No Cloudflare, no round trip out to the
internet and back, no NAT data charges, and nothing to allowlist.

The Chrome path still uses the public site. It's screenshotting a
rendered page rather than reading a payload, so it has no internal
equivalent until profiles are ported too.

Needs exercism/website#9351 deployed first: it moves the payload onto the
existing /spi/solution_image_data endpoint.


Claude-Session: https://claude.ai/code/session_018iQj4EdMfNsWP6NtFTqwUU

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: iHiD

dev/render.js

@@ -16,13 +16,13 @@
 // solution-go-tabs.json is tab-indented Go at indent_size 4. Space-indented
 // tracks look the same whatever indent_size says, so it takes a track that
 // actually ships literal tabs to see that value being honoured.
-//   node dev/render.js --url https://exercism.org/images/solutions/ruby/bob/ihid
+//   node dev/render.js --url https://internal.exercism.org/spi/solution_image_data/ruby/bob/ihid
 //   node dev/render.js --out /tmp/mine.png
 //
-// --url hits the real data endpoint, so it needs the website to be serving
-// /data (exercism/website#9348) and to not be behind a bot challenge. Against
-// production you'll get a Cloudflare challenge unless your IP is allowlisted;
-// point it at localhost:3020 instead.
+// --url takes the data endpoint itself. internal.exercism.org only resolves
+// from inside the VPC, so locally point it at your own Rails:
+//
+//   node dev/render.js --url http://localhost:3020/spi/solution_image_data/ruby/bob/ihid
 
 const fs = require("fs");
 const path = require("path");
@@ -41,11 +41,11 @@ const fixture = flag("fixture", path.join(__dirname, "fixtures", "solution.json"
 async function payload() {
   if (!url) return JSON.parse(fs.readFileSync(fixture, "utf8"));
 
-  const response = await fetch(`${url}/data`);
+  const response = await fetch(url);
   if (!response.ok) {
     throw new Error(
-      `${url}/data returned ${response.status}. ` +
-        "A 403 with a Cloudflare challenge means this IP isn't allowlisted."
+      `${url} returned ${response.status}. ` +
+        "internal.exercism.org only resolves inside the VPC - use your local Rails."
     );
   }
   return response.json();
@@ -59,7 +59,7 @@ async function main() {
 
   const started = Date.now();
   const { generate } = require("../satori_renderer");
-  const { body, contentType } = await generate({ url: url || "fixture://solution" });
+  const { body, contentType } = await generate({ dataUrl: url || "fixture://solution" });
   const elapsed = Date.now() - started;
 
   fs.writeFileSync(out, body);

index.js

@@ -12,6 +12,12 @@ const satoriRenderer = require("./satori_renderer");
 const imagePath = "/tmp/screenshot.jpg";
 const baseUrl = "https://exercism.org";
 
+// The satori renderer fetches its data over the internal ALB rather than the
+// public site, so it never leaves the VPC and doesn't depend on this lambda's
+// NAT address being allowlisted in Cloudflare. The Chrome path still uses the
+// public site: it's screenshotting a rendered page, not reading a payload.
+const internalBaseUrl = process.env.INTERNAL_BASE_URL || "https://internal.exercism.org";
+
 // Generating an image costs a few seconds of headless Chrome at 2GB, so we only
 // ever want to pay for it once per distinct URL. CDN edge caches can't give us
 // that on their own: they're per-PoP, they evict the long tail (most images are
@@ -47,6 +53,7 @@ function rawPathToScreenshotData(rawPath) {
     return {
       kind: "solution",
       url: `${baseUrl}/images/solutions/${track_slug}/${exercise_slug}/${user_handle}`,
+      dataUrl: `${internalBaseUrl}/spi/solution_image_data/${track_slug}/${exercise_slug}/${user_handle}`,
       imageSelector: "#image-content",
       waitForSelector: "#image-content .c-code-pane",
     };

satori_renderer.js

@@ -290,21 +290,24 @@ function card(data) {
   );
 }
 
-async function fetchData(pageUrl) {
-  const url = `${pageUrl}/data`;
-  const response = await fetch(url);
+async function fetchData(dataUrl) {
+  const response = await fetch(dataUrl);
 
   if (!response.ok) {
-    throw new Error(`Fetching ${url} failed with ${response.status}`);
+    throw new Error(`Fetching ${dataUrl} failed with ${response.status}`);
   }
 
   return response.json();
 }
 
-// Takes the same page URL the Chrome path would have navigated to, so the
-// rawPath -> URL mapping stays in one place.
-async function generate({ url }) {
-  const data = await fetchData(url);
+// dataUrl points at the internal ALB, so this never leaves the VPC. Fetching
+// from the public site meant going out through Cloudflare and needing the NAT
+// address allowlisted to get back in - the coupling that left every image
+// timing out for four days when bot mitigation was turned on.
+//
+// Built in index.js so the rawPath -> URL mapping stays in one place.
+async function generate({ dataUrl }) {
+  const data = await fetchData(dataUrl);
 
   const svg = await satori(card(data), { width: WIDTH, fonts: fonts() });
   const png = new Resvg(svg, { fitTo: { mode: "width", value: WIDTH } }).render().asPng();