Einleitung

In dieser Serie möchte ich den Aufbau meines Flagship Projekts beschreiben und auf die technischen Details bei der Umsetzung eingehen.

In diesem Post geht es um den Stack und aus welchen Bausteinen tempblade besteht.

Aufbau - API

Der Kern von tempblade sind die API und die Bibliotheken. Die API besteht aus einem Hauptserver (api/core) und einem Workerserver (api/worker).
Der Hauptserver bildet alle für das Frontend sowie mögliche Apps nötigen Daten und Aktionen über eine GraphQL API ab, für das Admin Dashboard
habe ich eine dedizierte OpenAPI REST API gebaut. Der Hauptserver ist mit dem Workerserver per Redis verbunden, theoretisch ist es auch möglich
mehrere Workerserver hinzuzuschalten die parallel eingehende Aufträge bearbeiten bzw. Templates rendern.

Aufbau - Bibliotheken

Mir war es von Anfang an wichtig tempblade modular zu gestalten damit es möglichst flexibel einsetzbar ist, und bspw. auch in einer WordPress oder Strapi basierten
Anwendung verwendet werden kann. Möglich wird das durch die unterschiedlichen Bibliotheken die ich gebaut habe.

Insgesamt gibt es derzeit 5 Bibliotheken:

• lib/renderer (Die Renderlogik, hier liegt ebenfalls der Python-Code für die Kommunikation mit bspw. Blender oder Houdini)
• lib/renderer-helpers (Eine Helfer Bibliothek für das Rendern in einem JavaScript/TypeScript Kontext)
• lib/schema-tools (Die Template-Schema Definitionen, inkl. Validierungslogik basierend auf zod und Helfer um neue Schemas zu erstellen)
• lib/common (Geteilte Types, Icons, Farbfunktionen)
• lib/cli (Eine Kommandozeilenanwendung zum rendern und validieren von Schemas/Templates)

Am interessantesten denk ich ist hier die lib/cli, da sie abbildet wie die Nutzung in einem anderen Kontext aussehen könnte, in diesem Fall als Kommandozeilenanwendung.
Derzeit funktioniert sie so dass man in einem Template Ordner den tempblade-render Befehl aufruft und dann interaktiv alle Parameter abgefragt werden. Anschließend wird
das Template gerendert in den angegebenen Ordner. Das ermöglicht das schnelle und einfache testen von Templates.

Alle Bibliotheken sind in TypeScript geschrieben, und verwenden als Compiler Vite.

Implementationdetails

Ein wichtiger Teil beim Design der Architektur war mir einen Workflow zu erlauben der nah an dem eines typischen Motion Designers bleibt, so dass ein verwenden des Shops
ohne Programmierungskentnisse möglich ist. Das spiegelt sich am meisten darin wieder wie die Assets für Templates gespeichert werden. Hier habe ich auf SeaFile gesetzt
anstatt ein typischen Object Storage Service wie z.B. AWS S3 - Der Vorteil liegt darin dass Projektdateien nicht extra hochgeladen werden müssen sondern automatisch
synchronisiert werden, wie bei Dropbox bspw. Für SeaFile habe ich mich entschieden da es selber gehostet werden kann. Die Architektur würde es allerdings auch erlauben später
andere File Storage Provider einzubinden.