Ik ben nu een tijdje diep in Forge en er is een patroon dat ik blijf zien.
Mensen komen Forge binnen met de gedachte:
“Dit is gewoon een andere backend.”
Dat is het niet.
En als je het als zodanig bouwt, zal je app breken op het moment dat het schaalt.
Wat Forge Eigenlijk Is
Forge is niet Connect.
Forge is niet je Node.js server.
Forge is niet je AWS backend.
Forge is:
Een serverless, event-gedreven runtime binnen het ecosysteem van Atlassian
Die onderscheid is belangrijk.
Je host geen infrastructuur.
Je opereert binnen beperkingen door ontwerp.
Bij het bouwen en nadenken over UI, raad ik aan om aangepaste UI te gebruiken (voor elke serieuze app) omdat het voorspelbaar is in wijzigingsbeheer en ruimte heeft voor architectonische plafonds. Een voorbeeld van een productieklare projectstructuur
Aanbevolen Projectstructuur
forge-app/
│
├── manifest.yml # App-definitie (modules, machtigingen)
├── package.json # Backend afhankelijkheden
│
├── src/
│ ├── resolvers/ # Backend logica (functies)
│ │ ├── index.js # Hoofdingang voor resolver
│ │ ├── scheduler.js # Geplande taken
│ │ ├── consumer.js # Queue verwerking
│ │ └── api.js # Externe API-integraties
│ │
│ └── utils/ # Gedeelde logica
│
├── static/
│ └── app/ # Aangepaste UI (React)
│ ├── src/
│ ├── public/
│ └── build/
│
└── README.md
Wat Je Kan Doen
Laten we de ruis weghalen en over de realiteit praten.
1. Bouw Echte Automatiseringssystemen
Geen Jira Automatiseringsregels.
Ik heb het over:
- Geplande workflows
- Multi-stap verwerkingspijplijnen
- Cross-project orkestratie
Gebruik:
- scheduledTrigger
- queue
- consumer
Dit is hoe je eenvoudige maar effectieve apps bouwt.
2. Integreer AI
Er is veel ruis rond “Forge AI” maar dat is een EAP op het moment van schrijven van dit artikel
Wat je daadwerkelijk doet:
- Roep externe API's aan (OpenAI, enz.)
- Verwerk resultaten binnen Forge
Eenvoudig, gecontroleerd, schaalbaar. Echter, wanneer ForgeLLM GA wordt, zou dat een game changer zijn.
3. Gebruik Opslag op de Juiste Manier
Forge geeft je:
- KVS
- SQL
- Object Store (EAP voor nu)
Maar hier is de fout:
Forge-opslag is niet je datawarehouse.
Gebruik het voor:
- Status
- Metadata
- Lichte persistentie
Je bron van waarheid is nog steeds Jira/Confluence.
Waar de meeste apps fout gaan
Ze negeren hoe Forge daadwerkelijk uitvoert.
Alles is:
- Statusloos
- Kortdurend
- Gebeurtenisgestuurd
Toch proberen mensen:
- Lange processen in één functie uit te voeren
- Grote payloads te duwen
- Het te behandelen als Express.js
Zo bereik je snel limieten.
Het patroon dat daadwerkelijk schaalt
Als je iets serieus bouwt, is dit de architectuur:
+-------------------+
| Geplande Trigger |
+-------------------+
|
v
+-------------------+
| Push naar Queue |
+-------------------+
|
v
+-------------------+
| Queue |
+-------------------+
|
v
+-------------------+
| Consument |
| (Asynchrone Processor) |
+-------------------+
|
v
+-------------------+
| Externe API's / |
| Forge Opslag |
+-------------------+
Dit is hoe Forge bedoeld is om te worden gebruikt.
Kritieke Beperking
Forge is geen onbeperkte rekencapaciteit.
Je moet ontwerpen rond:
- Aanroeplimieten
- Snelheidslimieten (Atlassian API's + Forge runtime)
- Uitvoertijdlimieten
- Queue doorvoersnelheidslimieten
Queue Limieten
- Max 50 evenementen per push-batch
- Max ~200 KB per payload
- Ontworpen voor gecontroleerde asynchrone werkbelastingen
Dit is opzettelijk:
Forge handhaaft limieten om de stabiliteit van het platform te beschermen.
Als genegeerd:
Zal je app throttlen, falen of verslechteren onder belasting.
De Mindset Verandering
De grootste ontgrendeling in Forge is dit:
Stop met denken “backend”
Begin met denken “gedistribueerde functies”
Verdeel je logica in:
- Kleine eenheden
- Asynchrone workflows
- Queue-gedreven verwerking
Maak alles:
- Idempotent
- Retry-veilig
- Lichtgewicht
Ik ben nog niet klaar
Forge is krachtig, maar alleen als je het model respecteert.
De meeste mensen doen dat niet.
Ze vechten tegen het platform in plaats van ermee te ontwerpen.
En dat is het verschil tussen:
- Een demo-app
- En een productie-app die door duizenden teams wordt gebruikt
Ik zal dieper ingaan in mijn volgende artikel:
Deel 2: Schaalpatronen
Omdat dat is waar het interessant wordt.