tempblade — Architecture — 1/10

Introduction

In this series I want to walk through the architecture of my flagship project and dig into the technical details behind it.

This post is about the stack and the building blocks tempblade consists of.

Architecture — API

At the core of tempblade are the API and the libraries. The API is split into a main server (api/core) and a worker server (api/worker).
The main server exposes all the data and actions the frontend and any apps need over a GraphQL API; for the admin dashboard
I built a dedicated OpenAPI REST API. The main server connects to the worker server via Redis — in principle it would also be possible
to add multiple worker servers that process incoming jobs and render templates in parallel.

Architecture — Libraries

It was important to me from the start to keep tempblade modular so it can be reused flexibly — for example dropped into a WordPress or Strapi-based
application. That's made possible through the different libraries I built.

There are currently 5 libraries in total:

• lib/renderer (the rendering logic — also home to the Python code that talks to e.g. Blender or Houdini)
• lib/renderer-helpers (a helper library for rendering inside a JavaScript/TypeScript context)
• lib/schema-tools (the template-schema definitions, including zod-based validation logic and helpers for authoring new schemas)
• lib/common (shared types, icons, colour utilities)
• lib/cli (a command-line application for rendering and validating schemas/templates)

I think the most interesting one here is lib/cli, since it shows what use in a different context can look like — in this case as a command-line application.
It currently works like this: inside a template directory you run the tempblade-render command and it interactively prompts for every parameter. After that
the template is rendered into the specified directory. That makes testing templates fast and easy.

All libraries are written in TypeScript and use Vite as the compiler.

Implementation details

An important part of the architecture design for me was enabling a workflow that stays close to that of a typical motion designer, so that using the shop
is possible without any programming knowledge. That shows up most clearly in how assets for templates are stored. I chose SeaFile here
instead of a typical object storage service like AWS S3 — the advantage is that project files don't need to be uploaded separately; they're automatically
synced, like Dropbox for example. I went with SeaFile because it can be self-hosted. The architecture would, however, also allow other
file storage providers to be plugged in later on.