Seit dem Launch von Atlassian Forge im Jahr 2021 haben sich in der Developer-Community einige hartnäckige Missverständnisse festgesetzt. Manche davon stammen aus den frühen Beta-Phasen, andere entstehen durch Vergleiche mit Connect, wobei wichtige Nuancen übersehen werden. In diesem Artikel räumen wir mit zehn Forge-Vorurteilen auf und zeigen Fakten und praktische Beispiele aus der realen App-Entwicklung.
Mythos 1: Forge-Apps sind zu langsam für Enterprise-Anwendungen
Der Mythos: Die Serverless-Architektur von Forge führt zu Cold Starts und unberechenbaren Response-Zeiten, die für produktive Enterprise-Umgebungen nicht akzeptabel sind.
Die Realität: Cold Starts existieren, betreffen aber hauptsächlich Apps mit sehr wenig Traffic. Bei regelmäßiger Nutzung bleiben Functions “warm” und reagieren in Millisekunden.
Hier sind einige konkrete Zahlen:
- Warm Functions: Response Time typischerweise 50-200 Millisekunden
- Cold Start: Zusätzliche ein bis drei Sekunden beim ersten Request nach längerer Inaktivität
- UI Kit: Natives Rendering ohne iframe-Overhead, schneller als Connect
Best Practice: Für zeitkritische Operations können Sie Scheduled Triggers nutzen, um Functions “warmzuhalten”, oder asynchrone Patterns implementieren, bei denen die User nicht auf das Ergebnis warten müssen.
Ein praktisches Beispiel: Apps wie draw.io sind erfolgreich von Connect zu Forge migriert und berichten von einer vergleichbaren oder besseren Performance bei gleichzeitig deutlich reduziertem Wartungsaufwand.
Mythos 2: Die Storage-Limits von Forge machen Enterprise-Apps unmöglich
Der Mythos: Mit nur 128 KiB pro Key und maximal 1 GB Gesamtspeicher pro App kann man keine echten Enterprise-Anwendungen bauen.
Die Realität: Diese Limits beziehen sich auf die native Key-Value Storage API. Für größere Datenmengen gibt es drei etablierte Strategien:
- Intelligente Partitionierung: Durch geschickte Aufteilung der Daten auf mehrere Keys lassen sich auch große Datensätze verwalten. Statt beispielsweise ein riesiges JSON-Objekt zu speichern, werden die Daten in kleinere, logische Einheiten zerlegt.
- Forge SQL (seit 2024): Diese vollständige MySQL-kompatible Datenbank mit unbegrenztem Speicher (kostenpflichtig ab bestimmtem Volumen) ist geeignet für relationale Daten und komplexe Queries.
- Forge Remote: Sie können Ihre eigene Datenbank-Infrastruktur (AWS RDS, Azure SQL, On-Premise) anbinden – bei voller Beibehaltung der Forge-Sicherheitsvorteile im Frontend.
Mythos 3: Mit Forge verliert das Team die Kontrolle über seine App
Der Mythos: Atlassian hostet die App und kann jederzeit Features deaktivieren, die Performance drosseln oder die App gar vom Netz nehmen.
Die Realität: Sie behalten die volle Kontrolle über Ihre App-Logik, die Deployment-Zeitpunkte und alle geschäftlichen Entscheidungen. Atlassian stellt lediglich die sichere Infrastruktur bereit.
Was Sie kontrollieren:
- Alle Deployments erfolgen durch das Entwicklungsteam.
- Sie entscheiden über Versionssprünge und Updates.
- Ihre Geschäftslogik bleibt proprietär.
- Es besteht Zugriff auf Logs und Monitoring-Daten.
Was Atlassian verwaltet:
- Infrastruktur-Updates und Security-Patches
- Skalierung der Serverless-Ressourcen
- Backup der Forge-Storage-Daten
- Compliance-Zertifizierungen (SOC 2, ISO 27001)
Der Vorteil für Ihr Team: Sie sparen sich große Teile des Infrastruktur-Overheads und können sich auf die Produktentwicklung konzentrieren. Statt sich um Server-Updates, Security-Patches, Skalierung und Monitoring zu kümmern, fokussieren Sie sich auf Features.
Mythos 4: Forge ist nur für einfache Apps geeignet
Der Mythos: Im Prinzip erschöpfen sich die Möglichkeiten von Forge auf simple Konfigurationsdialoge und Webhooks.
Die Realität: Zahlreiche komplexe, geschäftskritische Enterprise-Apps laufen produktiv auf Forge:
- draw.io: Vollständiger Diagramm-Editor mit Canvas-Rendering und komplexer Grafik-Engine
- Mria CRM: Komplettes CRM-System innerhalb von Jira mit Customer-Journey-Tracking
- Custom Workflow Engines: Multi-Step-Approval-Prozesse mit State Machines und Eskalationslogik
- BI-Dashboards: Komplexe Datenvisualisierungen mit Echtzeitaktualisierung
Diese verfügbaren Technologien unterstützen Ihr Entwicklungsteam:
- Custom UI mit vollständigem React-Ökosystem
- WebGL und Canvas für grafische Anwendungen
- WebSockets (über Forge Remote)
- Integration externer APIs (OpenAI, Stripe, AWS Services)
- Background Jobs via Async Events und Scheduled Triggers
Limitation, die wirklich existiert: Langlaufende Hintergrundprozesse über 15 Minuten müssen in kleinere Chunks aufgeteilt werden. Das ist aber eine Architektur-Herausforderung, kein Showstopper. Die meisten modernen Cloud-Anwendungen arbeiten ohnehin mit kleineren, asynchronen Tasks.
Mythos 5: UI Kit ist limitiert, Custom UI zu komplex
Der Mythos: Das UI Kit bietet zu wenig Flexibilität, Custom UI ist überkompliziert. Es gibt keinen Mittelweg.
Die Realität: Beide Ansätze haben ihre Berechtigung und lassen sich sogar in derselben App kombinieren.
Einsatzgebiete des UI Kit
Das UI Kit ist sehr gut geeignet für Admin-Konfigurationsseiten, einfache Formulare und Einstellungen, schnelle Prototypen und Apps, die konsistent mit dem Atlassian-Design bleiben sollen.
Vorteile des UI Kit:
- Natives Rendering (kein iframe, bessere Performance)
- Automatische Updates bei Atlassian-Design-Änderungen
- Sehr schnelle Ladezeiten
- Weniger Code, schnellere Entwicklung
- Barrierefreiheit out-of-the-box
Einsatzgebiete von Custom UI
Custom UI eignet sich für Dashboards mit komplexen Visualisierungen, Apps mit eigener Brand-Identität, Integration von Drittanbieter-Bibliotheken und Canvas-basierte Anwendungen wie Diagramme oder Whiteboards.
Vorteile von Custom UI:
- Vollständige Kontrolle über HTML und CSS
- Zugriff auf das gesamte React-Ökosystem
- Custom Styling und Animationen
- Nutzung von NPM-Packages
- Pixel-perfekte Umsetzung von Designs
Hybrid-Ansatz als Königsweg: Sie können das UI Kit für Einstellungen und Admin-Bereiche verwenden und Custom UI für die Hauptanwendung nutzen. So verbinden sie die besten Eigenschaften beider Welten. Ein typisches Beispiel: Konfiguration im UI Kit, Dashboard in Custom UI.
Mythos 6: Debugging in Forge ist unmöglich
Der Mythos: Ohne direkten Server-Zugriff und mit eingeschränktem Logging lassen sich Produktionsfehler nicht diagnostizieren.
Die Realität: Forge bietet umfassende Debugging-Tools, die sich vom traditionellen Server-Debugging zwar unterscheiden, aber oft sogar besser sind.
Diese Werkzeuge stehen Ihnen zur Verfügung:
- Forge Tunnel (während der Entwicklung): Zeigt Logs in Echtzeit direkt im Terminal, während Sie die App im Browser testen. Sie sehen sofort, was in Ihrer Funktion passiert, ohne auf Deployments zu warten.
- Produktions-Logs: Zugriff auf Produktions-Logs aller Installationen (wenn User zustimmen) über die CLI. Sie können Logs in Echtzeit verfolgen oder historische Logs durchsuchen.
- Strukturiertes Logging: Implementieren Sie JSON-basiertes Logging mit Kontextinformationen wie User-IDs, Actions und Timestamps für bessere Filterbarkeit und Analyse.
- Fehler-Tracking: Integrieren Sie externe Services wie Sentry oder Rollbar über Forge Remote für professionelles Error-Tracking mit Stack Traces, User-Kontext und Alarmierung.
Tipps für ein effektives Debugging:
- Implementieren Sie ein strukturiertes JSON-Logging mit aussagekräftigen Feldern.
- Nutzen Sie “try-catch” mit klaren Fehlermeldungen.
- Bauen Sie Health-Check-Endpoints für das Monitoring.
- Fügen Sie Request-IDs für das Request-Tracing hinzu.
- Testen Sie lokal mit Forge Tunnel vor dem Deployment.
Datenschutzaspekt: User können App-Logs deaktivieren. Das ist kein Bug, sondern ein Feature für datenschutzbewusste Enterprise-Kunden. Gute Apps sind so gestaltet, dass sie auch ohne vollständiges Logging funktionieren und debugbar bleiben.
Mythos 7: Forge-Apps können keine externen Services integrieren
Der Mythos: Die Sandbox-Umgebung verhindert die Kommunikation mit externen APIs oder Diensten.
Die Realität: Forge-Apps können problemlos mit externen Services kommunizieren, und zwar sicherer als Connect-Apps, da alle Outbound-Requests über die Forge-Plattform laufen und validiert werden.
Dies sind die verfügbaren Integrationsmethoden:
- Direkte API-Calls für öffentliche APIs: Forge bietet eine Fetch-API, mit der Sie beliebige externe REST-APIs aufrufen können. Die Authentifizierung mit API-Keys, Bearer-Tokens oder anderen Methoden ist möglich.
- OAuth 2.0 für etablierte Services: Forge unterstützt den standardisierten OAuth-Flow für die sichere Drittanbieter-Authentifizierung bei Services wie Google, Microsoft, Salesforce und vielen anderen.
- Webhooks (eingehend): Ihre Forge-App kann Webtrigger bereitstellen, die externe Services aufrufen können. Dieser Weg eignet sich für Integrationen, die von außen Ereignisse pushen müssen.
- Forge Remote für komplexe Szenarien: Für aufwendige Integrationen können Sie eigene Backend-Services mit beliebigen Technologien (Python, Java, Go) betreiben und diese mit Forge verbinden.
Die einzige Einschränkung: Outbound-Requests haben Rate Limits. Bei sehr hohem Volumen nutzen Sie Forge Remote, wo Sie die volle Kontrolle über Request-Patterns haben.
Mythos 8: Die Migration von Connect zu Forge bedeutet komplettes Rewrite
Der Mythos: Das Team muss bestehende Connect-Apps komplett neu schreiben – eine Großinvestition von etlichen Wochen oder Monaten.
Die Realität: Atlassian bietet einen hybriden Ansatz namens “Connect on Forge”, der eine schrittweise Migration ohne “Big-Bang-Umstellungen” ermöglicht.
Der schrittweise Migrationspfad sieht so aus:
- Phase 1: Connect und Forge registrieren – Ihre Connect-App läuft unverändert weiter, wird aber via Forge-Manifest registriert. Es sind keine Code-Änderungen nötig. Sie gewinnen dadurch bereits Vorteile wie automatische Updates ohne Admin-Freigaben.
- Phase 2: Schrittweise Module migrieren – Migrieren Sie einzelne Module (z. B. zuerst Admin-Seiten) zu nativen Forge-Modulen, während andere weiterhin in Connect laufen. Ihre User merken nichts von der Umstellung.
- Phase 3: Vollständige Forge-Migration – Erst wenn alle Module erfolgreich migriert und getestet sind, können Sie das Connect-Backend vollständig abschalten. Es gibt keinen Zeitdruck und keine erzwungenen Deadlines.
Die Vorteile dieses Ansatzes:
- Es findet keine riskante Big-Bang-Migration mit Downtime statt.
- Die User erleben eine nahtlose Transition.
- Sie können jedes Modul vor dem Switch gründlich testen.
- Bei Problemen haben Sie die Möglichkeit zum Rollback.
- Die Entwicklungskosten verteilen sich über einen längeren Zeitraum.
Mythos 9: Forge-Apps kosten ab 2026 ein Vermögen
Der Mythos: Mit dem neuen Consumption-Based Pricing ab Januar 2026 explodieren die Kosten und machen Forge unrentabel.
Die Realität: Für die meisten Apps bleiben die Kosten im großzügigen Free Tier oder sind deutlich niedriger als die Kosten für eine eigene Server-Infrastruktur.
Das kostenfreie Modell umfasst:
- 100.000 Function Invocations pro Monat
- 50 GB Datentransfer
- 10.000 Storage-API-Abfragen
- Forge SQL: 1 GB Datenbank kostenlos
Darüber hinaus gilt ein Pay-per-Use-Ansatz basierend auf dem tatsächlichen Verbrauch. Es entstehen keine monatlichen Fixkosten für ungenutzte Server. Sie zahlen nur, was Sie wirklich nutzen.
Im Vergleich dazu muss das Team bei einer selbst gehosteten Connect-App unter anderem eine AWS-Instanz, eine RDS-Datenbank und Aufwände für Wartung, Updates und Überwachung zahlen.
Es gibt einige hilfreiche Tools zur Kostenkontrolle:
- Cost Estimator in der Developer-Konsole zur Vorabberechnung
- Nutzungs-Dashboard mit Prognosen und Trends
- Alarme bei Erreichen von Schwellenwerten
- Detaillierte Breakdowns nach Function, Storage, Transfer
Optimierungstipp: Invocations sind nicht gleich Requests – eine User-Aktion kann mehrere Invocations auslösen. Optimieren Sie Invocations durch intelligentes Caching und Batching von Requests, wenn nötig. Die allermeisten Apps bleiben weit unter den Free-Tier-Limits.
Mythos 10: Atlassian zwingt alle zu Forge – Connect wird abgeschaltet
Der Mythos: Connect wird Ende 2026 komplett abgeschaltet. Dann müssen alle Apps migriert sein – oder sie verschwinden vom Markt.
Die Realität: Connect wird nicht “abgeschaltet”, sondern geht in einen Maintenance-Modus über. Es gibt kein hartes Abschaltdatum, ab dem Connect-Apps nicht mehr funktionieren.
Die tatsächliche Timeline sieht so aus:
Bis Ende 2026 …
- … werden keine neuen Connect-Apps am Marketplace akzeptiert.
- … funktionieren bestehende Connect-Apps vollständig weiter.
- … stellt Atlassian weiterhin Security-Updates und kritische Patches bereit.
- … werden keine neuen Features für Connect mehr ausgeliefert.
Nach 2026 …
- … laufen Connect-Apps auf unbestimmte Zeit weiter.
- … bietet Atlassian “Connect on Forge” als Hybrid-Lösung an.
- … gibt es keinen Termin für eine erzwungene Migration mit hartem Stichtag.
- … wird die Maintenance fortgeführt.
Was Atlassian empfiehlt: Neue Apps sollten auf Forge entwickelt werden. Bestehende Connect-Apps sollten schrittweise zu Forge migriert werden, wenn es geschäftlich und technisch Sinn ergibt – nicht aber aus Panik.
Es handelt sich hierbei um eine strategische Empfehlung, nicht um ein technisches Ultimatum. Der Hauptgrund für eine Migration sollten die strategischen Vorteile sein (verbesserte Sicherheit, weniger Wartungsaufwand, bessere Integration, Data Residency), nicht die Angst vor einem Shutdown. Dennoch gilt: Wer heute noch neue Connect-Apps entwickelt, sollte sich bewusst sein, dass diese mittelfristig migriert werden müssen. Für Neuentwicklungen ist Forge die zukunftssichere Wahl.
Forge auf Faktenbasis bewerten
Viele Forge-Mythen stammen aus der Beta-Phase oder resultieren aus einem unvollständigen Verständnis der Plattform. Die praktische Realität zeigt: Forge ist eine ausgereifte, produktionsreife Lösung, die für Enterprise-Anwendungen geeignet ist, wenn Ihr Entwicklungsteam die Architektur richtig plant.
Evaluieren Sie Forge anhand Ihrer spezifischen Anforderungen, nicht anhand von Mythen aus der Community. Die meisten Teams, die sich auf Forge einlassen und die Plattform verstehen, entscheiden sich schließlich bewusst für diese Plattform, weil sie technisch und wirtschaftlich die bessere Lösung ist.
Der richtige Ansatz könnte so aussehen: Starten Sie mit einem Proof of Concept für eine kleinere Funktionalität. Testen Sie die Developer Experience, die Performance und die Integration. Sammeln Sie eigene Erfahrungen, statt sich auf Hörensagen zu verlassen. Wahrscheinlich werden Sie positiv überrascht sein.
Gerne unterstützen unsere erfahrenen Fachleute Ihr Team bei der effizienten Umstellung: Senden Sie uns eine Mail oder vereinbaren Sie direkt einen ersten Gesprächstermin!