Files
espresso_frame/server/render-service/server.js
T
tfaour 644fdefa66
Build and push server image / build-and-push (push) Failing after 1m10s
Add whiteboard frame mode (Nextcloud Whiteboard / Excalidraw over WebDAV)
New third mode alongside photos/calendar: fetches a .whiteboard file
over plain WebDAV (Basic auth -- generic, not Nextcloud-specific) and
renders it via a small Node.js sidecar using Excalidraw's own real
export code (@excalidraw/utils + @resvg/resvg-js, no headless browser),
since a .whiteboard file turns out to be Excalidraw scene JSON, not an
image. The sidecar runs as a second process inside this same container
(Dockerfile installs Node, start.sh backgrounds it before exec'ing
uvicorn) rather than a separate docker-compose service -- lightweight,
stateless, reachable only at 127.0.0.1 from the Python process, nothing
worth independently scaling.

The rendered PNG is treated exactly like a photo from there on --
composed/quantized through the existing image_pipeline (letterboxed,
never cropped) rather than a second parallel rendering pipeline.

WebDAV credentials support the common "it's actually the same Nextcloud
account as my CalDAV" case (an explicit opt-in checkbox, not silently
inferred) while still working with any WebDAV server generically.
Frame-level source (URL + owning account) follows the same owner-
controls-their-own-data permission split as calendar sources and the
week view's task list: only the account owner can point a frame at it,
anyone linked can clear it.

Honest limitation: this environment has no Node.js/npm, so
render-service/ is written carefully against each library's documented
API (verified via the npm registry, including transitive dependency
licenses after the CalDAV/AGPL surprise earlier this session) but has
never actually been executed. First real docker build is the first
true test -- see render-service/README.md.
2026-07-23 17:02:08 -04:00

100 lines
4.2 KiB
JavaScript

// Local render sidecar for whiteboard frame mode: turns Excalidraw scene
// JSON (the format Nextcloud Whiteboard's .whiteboard files use --
// {"elements", "appState", "files"}, see app/webdav_client.py) into a
// PNG, using the real Excalidraw export code rather than a hand-rolled
// reimplementation of its element types/styling/fonts. That's the whole
// reason this exists as Node rather than more Python: @excalidraw/utils
// IS the renderer real whiteboards are drawn with, so this reproduces
// whatever a user actually sees in their whiteboard exactly, and never
// drifts out of sync with new element types as Excalidraw adds them.
//
// Runs as a second process inside the main Python server's own
// container (see ../Dockerfile installing Node, and ../start.sh
// launching this in the background before exec'ing uvicorn) -- not a
// separate deployment, no independent scaling/restart needs, so one
// container is simpler than a second docker-compose service. Bound to
// 127.0.0.1 only: reachable from the Python process in the same
// container, never from outside it, so there's no auth on top of that
// -- the network boundary IS the access control here.
//
// No headless browser (Puppeteer/Playwright) -- jsdom provides just
// enough of a browser-like global environment for @excalidraw/utils'
// internal DOM calls (e.g. text measurement) to work, and
// @resvg/resvg-js (a native Rust SVG rasterizer, no browser process)
// turns the resulting SVG into the actual PNG.
const { JSDOM } = require('jsdom');
// @excalidraw/utils touches `window`/`document` globals even though
// exportToSvg's own return value doesn't depend on a live page -- these
// have to exist before the package is required, not just before it's
// called.
const dom = new JSDOM('<!DOCTYPE html><html><body></body></html>');
global.window = dom.window;
global.document = dom.window.document;
global.navigator = dom.window.navigator;
const express = require('express');
const { exportToSvg } = require('@excalidraw/utils');
const { Resvg } = require('@resvg/resvg-js');
const PORT = process.env.RENDER_SERVICE_PORT || 3001;
const HOST = '127.0.0.1';
// A whiteboard scene is normally tiny (KB, not MB) -- this is a sanity
// cap against something going wrong upstream, not a real expected size.
const MAX_BODY_BYTES = 25 * 1024 * 1024;
const app = express();
app.use(express.json({ limit: MAX_BODY_BYTES }));
app.get('/health', (req, res) => {
res.json({ status: 'ok' });
});
app.post('/render', async (req, res) => {
const { elements, appState, files, width, height } = req.body || {};
if (!Array.isArray(elements)) {
res.status(400).json({ error: 'elements must be an array (a parsed .whiteboard/Excalidraw scene)' });
return;
}
try {
const svg = await exportToSvg({
elements,
appState: appState || {},
files: files || {},
exportPadding: 20,
});
// Depending on the installed version, exportToSvg resolves to either
// an SVGSVGElement (needs serializing) or already a string -- handle
// both rather than assume, since this isn't runtime-tested against a
// live install in this environment (no Node available to verify
// during development, see the server README's whiteboard mode notes).
const svgString = typeof svg === 'string' ? svg : svg.outerHTML;
const targetWidth = Number(width) || undefined;
const resvg = new Resvg(svgString, {
fitTo: targetWidth ? { mode: 'width', value: targetWidth } : { mode: 'original' },
background: 'rgba(255, 255, 255, 1)',
font: {
// No bundled Excalidraw font assets (Virgil/Cascadia) in v1 --
// text renders in whatever fonts fontconfig finds in the image
// (see ../Dockerfile's fonts-dejavu-core), not pixel-identical
// to the browser editor's handwriting-style font. Good enough
// for "what does the board say", not a design-fidelity tool.
loadSystemFonts: true,
},
});
const pngBuffer = resvg.render().asPng();
res.set('Content-Type', 'image/png');
res.send(pngBuffer);
} catch (err) {
console.error('Whiteboard render failed:', err);
res.status(500).json({ error: String((err && err.message) || err) });
}
});
app.listen(PORT, HOST, () => {
console.log(`whiteboard-render listening on ${HOST}:${PORT}`);
});