In 15 Minuten zu pixelgenauen Platzhaltern: „Integrating Lorem Picsum into Canva“ mit Andreas Braumann (Canva Austria GmbH.)

Worum es in dieser Session ging

Unter dem Titel „Integrating Lorem Picsum into Canva“ zeigte Speaker Andreas Braumann von der Canva Austria GmbH., wie man in kurzer Zeit einen Content‑App‑Prototypen für die Canva‑Plattform baut. Sein Ziel: Testbilder mit exakt vorgegebenen Pixelmaßen sowie optionalen Filtern (Blur, Grayscale) direkt aus der Canva‑Suche heraus einfügen – „in 15 Minuten“ als Live‑Coding‑Demo. Als Quelle diente die bekannte Bild‑Placeholder‑Seite, die in der Session als „Lorem Picsum“ bezeichnet wurde; im Code‑Kontext sprach Braumann dabei konkret von picsum.photos/pixum.photos als externer Dienst.

Der Anwendungsfall ist konkret: Wer in einem Design eine Bildfläche auf exakt 100 × 100 Pixel (oder jede andere fest definierte Größe) füllen will, stößt bei klassischen Stock‑Integrationen an eine Grenze – man kann zwar grob nach „quadratisch“, „Hochformat“ oder „Querformat“ filtern, aber nicht auf die exakten Pixel. Genau diese Lücke adressierte der Prototyp: In das Suchfeld der App tragen Nutzerinnen und Nutzer Breite × Höhe sowie optionale Parameter ein, und die App liefert eine Liste passender Bilder – bereits vorgefiltert und in der korrekten Dimension.

Canva Developer Platform: Content, Editing, Publish

Zum Einstieg skizzierte Braumann die Canva‑Developer‑Plattform. Dort lassen sich drei Erweiterungstypen bauen:

• Content‑Extensions: fügen Inhalte in Canva ein (z. B. Bildquellen, die man direkt in Designs ziehen kann). Diese Art entwickelte er live.
• Editing‑Extensions: verändern vorhandene Inhalte (z. B. Blur, Grayscale, etc.).
• Publish‑Extensions: veröffentlichen Inhalte aus Canva heraus auf einer Zielplattform.

Ein Argument für die Plattform hob er explizit hervor: „Du bekommst deine App vor 20 Millionen plus Nutzerinnen und Nutzern.“ Der Weg: App entwickeln, hochladen, durch Canva prüfen lassen – danach ist sie live. Wer eine eigene App „auf der grünen Wiese“ baut, hat diese Reichweite selten; Canva bringt bereits eine große Nutzerbasis mit.

Architektur und Setup: Glitch + Node.js + Express

Für das Live‑Coding nutzte Braumann Glitch. Der Dienst erlaubt es, im Browser einen Node.js‑Stack (Express‑Server) zu editieren und sofort deployed zu sehen: „Sobald du speicherst, startet der Server neu.“ Für schnelles Prototyping ideal – kein manuelles Deployment, keine CI‑Pipelines. Canva empfiehlt Glitch explizit für die Entwicklung. Für den späteren Produktivbetrieb riet er ab: Glitch sei langsam und versetze Apps in den Ruhezustand (Hibernation). Für das Testen der Schnittstelle und der App‑UI ist es jedoch „awesome“.

Als Grundlage verwendete er ein von Canva bereitgestelltes Template für Content‑Extensions und ergänzt darin insbesondere die Request‑Verifikation, die im Template nicht vorkonfiguriert war. Ziel: sicherstellen, dass eingehende Requests tatsächlich von der Canva‑Plattform stammen und nicht von Dritten. Dafür wird ein Secret verwendet, das in den Umgebungsvariablen bei Glitch hinterlegt ist. In der Live‑App zeigte er zudem die Glitch‑Logs – hilfreich, um Fehler während des Codings unmittelbar nachzuvollziehen.

Der Business Case: Pixelgenau statt „Quadrat/Hoch/Quer“

Der Use Case war von Anfang an klar umrissen. In Canvas integrierten Medienbibliotheken (z. B. Pixel‑Anbieter) fehlt eine Filtermöglichkeit auf „exakt diese Pixelgröße“. Für Design‑Workflows, die pixelperfekte Assets für weitere Tools benötigen, ist das unpraktisch. Braumanns Idee: Eine Content‑App, die genau diese Lücke schließt, mit drei Funktionen:

1. Eingabe benutzerdefinierter Dimensionen im Suchfeld (z. B. „100x100“).
2. Zusätzliche Parameter über das gleiche Suchfeld (z. B. „blur=3“, „grayscale“).
3. Übergabe dieser Parameter an den externen Bilddienst, sodass die Bilder bereits in der gewünschten Variante (geblurred, in Graustufen) zurückkommen.

Er wies darauf hin, dass der verwendete Bilderdienst unabhängig ist („nicht affiliiert mit Canva oder Kaleido“) und dass er hierfür vorab keine Freigabe eingeholt habe – es handle sich um ein Testprojekt.

Endpunkt, Datenaustausch und Plattformkontrakt

Das Canva‑Template bringt die Grundstruktur für Content‑Apps mit. Der zentrale Endpunkt ist ein POST auf „content resources find“ – die Canva‑Plattform ruft ihn auf, wenn die App Inhalte liefern soll. Der Vertrag ist simpel: Der Endpunkt gibt ein Array von Ressourcen (hier: Bilder) zurück.

Im Standard‑Template wird zunächst eine interne Liste mit Bildern einer externen Quelle befüllt und unverändert zurückgegeben. Braumann ersetzte diese Logik und baute die dynamische Generierung der Bilder entsprechend der Suchanfrage auf. Wichtig ist dabei:

• Das Request‑Body enthält eine query (Suchfeldinhalt) und ein limit, das angibt, wie viele Einträge zurückgegeben werden sollen. In seinem Testumfeld waren das konstant 20, die App darf aber theoretisch auch andere Mengen liefern.
• Die Antwort muss das erwartete Format haben: ein Typ (z. B. „image“) sowie Felder wie id, name, Thumbnail‑URL, tatsächliche URL und Content‑Type. Braumann nutzte als Content‑Type „image.jpg“ und setzte aus Einfachheitsgründen Thumbnail‑URL und URL identisch.
• Für Canva ist eine stabile Identifikation wichtig. Deshalb generierte er deterministische URLs auf Basis eines Seeds (dazu gleich mehr) und nutzte den Seed gleichzeitig als id.

Suchsyntax: Maße und Parameter robust parsen

Die App interpretiert das Canva‑Suchfeld als einfachen Mini‑Parser für Maße und Filter:

• Format der Eingabe: „Breite x Höhe, optional weitere Parameter, durch Kommata getrennt“. Beispiel: „200x200, blur=3, grayscale“.
• Parsing‑Schritte: Zuerst wird die query an den Kommata gesplittet. Das erste Fragment enthält immer die Dimensionen; dieses Fragment wird wiederum an „x“ gesplittet, sodass width und height extrahiert werden.
• Defaultwerte: Wird die App frisch geöffnet, kommt gegebenenfalls keine query mit – dann sollten Defaultwerte für Breite und Höhe greifen, damit überhaupt Ergebnisse erscheinen.
• Zusätzliche Parameter: Die restlichen Fragmente werden nicht semantisch validiert, sondern unverändert zu einer Query‑String‑Komponente verbunden (mit & verknüpft). Dadurch lassen sich „blur=…“ oder „grayscale“ direkt an den Bilderdienst durchreichen. Diese Entscheidung spart Implementierungszeit, solange die Ziel‑API die Parameter robust akzeptiert.

Das Ergebnis sind drei Kernelemente für den späteren API‑Call: width, height und eine „parameters“-Zeichenkette, die die restlichen Optionen enthält.

Limit und Seeds: Wiedererkennbare Zufallsbilder

Ein zentrales Detail ist die Stabilität der Bildauswahl. Dienste wie picsum.photos liefern glückliche Zufälle: „Du bekommst zufällige Fotos die ganze Zeit“, so Braumann. Für Canva reicht echter Zufall jedoch nicht – zieht eine Nutzerin ein Bild in ein Design, erwartet die Plattform, dass die Quelle stabil referenzierbar bleibt (etwa wenn später erneut geladen wird). Die Lösung: Ein Seed, der in der URL als Kennung dient und damit ein spezifisches Bild deterministisch auswählbar macht.

Die Implementierung folgt einer einfachen Strategie:

• Aus dem Request‑limit (z. B. 20) wird abgeleitet, wie viele Bilder benötigt werden.
• Für jedes Bild wird ein Seed erzeugt (z. B. über Zufallszahlen). Eine genaue Seed‑Spezifikation verlangt der Bilderdienst nicht – entscheidend ist nur, dass derselbe Seed stets dasselbe Motiv zurückgibt.
• Aus Performance‑Gründen werden die Ressourcen in Parallelität „gebaut“. Im Code bedeutete das: Promises pro Seed anlegen und anschließend mit Promise.all warten, bis alle referenzierten URLs erzeugt sind. Der Vorteil: Die Latenz entsteht einmalig, statt sich seriell zu multiplizieren.

Der Seed erfüllt in der App einen Doppelnutzen: Er wird zum festen Bestandteil der Bild‑URL und gleichzeitig als id im Resource‑Objekt an Canva übergeben.

Die URL zusammenstellen: Seed, Maße, Parameter

Herzstück der Integration ist die URL‑Konstruktion. Braumann beschrieb sie Schritt für Schritt:

• Basis ist das API‑Endpoint des externen Dienstes (picsum.photos/pixum.photos). Für deterministische Bilder wird ein „seed“-Pfad genutzt.
• Danach folgen Breite und Höhe als Pfad‑Segmente – exakt so, wie die Nutzerin sie im Suchfeld eingegeben hat.
• Am Ende hängt die App die zuvor vorbereitete Parameterkette an (z. B. „blur=3&grayscale“). Der Bilderdienst liefert damit bereits vorverarbeitete Bilder.

Die so erzeugte URL wird sowohl als Thumbnail‑URL als auch als eigentliche URL an Canva zurückgemeldet; der Content‑Type ist „image.jpg“. Der Name der Ressource folgt einem einfachen Muster wie „lorem pixum WIDTH x HEIGHT“, sodass Nutzerinnen und Nutzer in der Seitenleiste erkennen, was sie erwartet.

Verifikation und Sicherheit: Nur echte Plattform‑Requests zulassen

Ein Aspekt, den Braumann im Boilerplate ergänzte, war die Signatur‑ bzw. Request‑Verifikation. Die Logik: Der Server validiert, dass die Anfrage tatsächlich von der Canva‑Plattform stammt und dieser App gilt. Dazu nutzt die App ein Secret, das in Glitch als Umgebungsvariable hinterlegt ist. Falls die Prüfung fehlschlägt, wird nicht geantwortet. So verhindert man, dass Dritte den Endpunkt missbrauchen.

In seinem Projekt waren diese Verifikationsroutinen im unteren Teil der Server‑Datei angesiedelt – „Boilerplate“ mit der Aufgabe, Authentizität und Integrität der eingehenden Calls sicherzustellen.

Debugging live: Logs, Tippfehler und schnelle Iteration

Die Demo lief in Echtzeit auf Glitch. Ein Highlight aus Entwicklersicht: Logs sind im Browser sichtbar, sodass Fehler schnell sichtbar werden. Und ja: Es gab einen „Live‑Coding‑Moment“ – ein Tippfehler verursachte einen Fehler in der Antwort. Die Lösung: Fixen, speichern, neu testen. Das stützt die Wahl von Glitch für Prototypen: kürzeste Feedback‑Zyklen, keine langen Deployments.

App in Canva anlegen: Public vs. Team

Zum Abschluss skizzierte Braumann den Weg zur App‑Registrierung in Canva: Über „Developers → Integrations → Create an app“ wird eine neue App angelegt. Eine Besonderheit hob er hervor: „Dieses Grün ist sehr speziell, weil du die Auswahl hier nie wieder ändern kannst.“ Gemeint ist die Grundsatzentscheidung zwischen „Public App“ (wird von Canva reviewed) und „Team App“ (intern im Team nutzbar). Wer öffentlich gehen will, sollte sich früh festlegen – die Review‑Schleife gehört dazu.

Demo‑Flow im Überblick

Wir fassen den Ablauf des Prototyps aus Sicht der Laufzeit zusammen:

1. Nutzer öffnet die Content‑App in Canva.
2. Die Plattform ruft den POST‑Endpunkt „content resources find“ auf und übergibt Body‑Parameter wie query und limit.
3. Die App verifiziert die Anfrage (Signatur/Secret) und parst die query:

• Erstes Segment: „WIDTHxHEIGHT“ → width, height
• Weitere Segmente: unverändert als Parameterkette zusammenfügen
• Falls keine query vorliegt: Default‑Maße setzen

1. Die App generiert für „limit“ Einträge Seeds und konstruiert pro Seed eine deterministische Bild‑URL mit Seed + Breite + Höhe + Parametern.
2. Parallel (Promises) werden die Ressourcenobjekte aufgebaut und an Canva zurückgegeben – mit type=image, id=Seed, Name, Thumbnail‑URL, URL, Content‑Type.
3. Canva zeigt die Resultate in der Seitenleiste, alle Bilder haben exakt die gewünschte Größe und ggf. bereits Blur/Grayscale angewandt.

Was wir als Redaktion gelernt haben

• Einfache, textbasierte Bedienkonzepte sind stark: Das Suchfeld als universeller Parameter‑Eingang spart UI‑Komplexität und erhöht die Geschwindigkeit beim Prototyping. Die Kommastruktur („WIDTHxHEIGHT, blur=3, grayscale“) ist leicht zu merken.
• Plattformkontrakte zuerst verstehen: Der Content‑App‑Endpunkt ist ein POST mit klaren Erwartungen an die Antwort. Wer dieses Format sauber bedient, bekommt schnelle Resultate in der Canva‑UI.
• Stabilität durch Seeds: Zufall ist nutzerfreundlich, aber Plattformen brauchen deterministische Referenzen. Seeds liefern beides – Vielfalt und Wiedererkennbarkeit.
• Verifikation nicht vergessen: Auch im Prototyp lohnt sich die saubere Absicherung der Endpunkte. Ein Secret in den Umgebungsvariablen ist schnell gesetzt und verhindert Missbrauch.
• Glitch für die Bauphase, Cloud für die Produktion: Die Wahl des Werkzeugs passt zum Ziel. Für Live‑Demos und schnelle Iteration ist Glitch unschlagbar; für Performance und Always‑On ist ein anderer Hoster sinnvoll.

Grenzen und Pragmatismus der Umsetzung

Die Demo zielte auf Minimalismus in der Funktionalität:

• Parameter werden nicht semantisch geprüft, sondern direkt durchgereicht. Das ist für Tests und schnelle Ergebnisse ideal, erfordert im Produktivbetrieb aber wahrscheinlich Validierung und Fehlermeldungen.
• Thumbnail‑URL und tatsächliche URL sind gleich – für die meisten Workflows ausreichend, aber man könnte Thumbnails schlanker zurückliefern.
• Default‑Maße wurden erwähnt, aber nicht ausimplementiert gezeigt – in einer ausgereiften App sollte eine sinnvolle Voreinstellung vorhanden sein (z. B. 150 × 150).

All das ist für ein „15‑Minuten“-Ziel völlig legitim und zeigt die Stärke des Ansatzes: Erst den End‑to‑End‑Flow lauffähig machen, dann Details iterativ verhärten.

Konkrete Schritte zum Nachbauen

Wer dem in der Session gezeigten Weg folgen will, kann sich an dieser Checkliste orientieren:

1. Glitch‑Projekt auf Basis eines Canva Content‑App‑Templates anlegen (Node.js/Express).
2. Secret als Umgebungsvariable setzen; Request‑Verifikation ergänzen (Authentizität der Canva‑Calls sicherstellen).
3. POST‑Endpunkt für „content resources find“ implementieren, der ein Array von Bild‑Ressourcen zurückgibt.
4. query aus dem Request‑Body auslesen, an Kommas trennen; erstes Segment in width/height splitten; restliche Segmente als Parameterkette vorbereiten; ggf. Defaultwerte setzen.
5. limit aus dem Request übernehmen; für jedes Element einen Seed generieren.
6. Pro Seed eine deterministische Bild‑URL konstruieren (seed, width, height, Parameter) und Resource‑Objekte (type=image, id=Seed, Name, URLs, Content‑Type) erzeugen.
7. Ressourcen parallel bauen (Promises) und gesammelt zurücksenden.
8. In Canva eine App anlegen („Create an app“) und entscheiden, ob Public oder Team – nicht änderbar.
9. In der Canva‑UI testen: Suchfeld mit „WIDTHxHEIGHT, blur=…, grayscale“ füllen, Bilder einfügen, Verhalten prüfen.

Fazit: Kleine App, klare Wirkung

„Integrating Lorem Picsum into Canva“ zeigte, wie man mit überschaubarem Aufwand eine echte Lücke im Workflow schließt: exakte Pixelmaße plus einfache Filter – direkt aus der Canva‑Suche, mit deterministischen Bildern via Seed. Für uns als DevJobs.at‑Redaktion war besonders eindrücklich, wie viel man mit einer einzigen, gut designten Suchsyntax erreichen kann und wie klar die Canva‑Developer‑Schnittstelle diesen Flow unterstützt.

Das Projekt war bewusst ein Test – schnell gebaut, live demonstriert, absichtlich pragmatisch. Genau deshalb ist es ein gutes Blaupausen‑Beispiel für alle, die eigene Content‑Extensions entwickeln möchten: erst den Endpunkt sauber sprechen, Eingaben knapp parsen, externe Dienste deterministisch anbinden, dann die App in Canva registrieren und iterativ verfeinern. Wer diesen Pfad geht, hat in kurzer Zeit einen funktionierenden Prototyp – und eine realistische Chance, über die Plattform viele Nutzerinnen und Nutzer zu erreichen.

• 

  

  DALL·E 2: Image generation with visual AI

  David Estévez von kaleido spricht in seinem devjobs.at TechTalk über die Funktionsprinzipien von Visual AIs – und welche neuen Möglichkeiten immer leistungstärkere Tools mit sich bringen.

  Jetzt ansehen
• 

  

  Visual AI Made Simple

  René Koller von kaleido erläutert in seinem devjobs.at TechTalk, wie das Devteam das Konzept von MVC auf MVVC erweitert hat und wie es zum Einsatz kommt.

  Jetzt ansehen
• 

  

  Multiplatform Strategy for the remove.bg Apps

  Andreas Braumann von Kaleido untersucht in seinem devjobs.at TechTalk die Vor- und Nachteile von Flutter und wie man damit alle remove.bg Apps in einer einheitlichen Technologie haben könnte.

  Jetzt ansehen
• 

  

  Software Engineering at kaleido.ai

  Riccardo Porrini von kaleido spricht in seinem devjobs.at TechTalk darüber, wie sich die Devteams während des Wachstums des Unternehmens organisiert haben.

  Jetzt ansehen