Begrijpen van Forge-aanroepen en statistieken

Hoewel ik al een tijdje weet vanForge, als ik het me goed herinner, werd het rond 2020 geïntroduceerd. Ik begon het pas serieuzer te gebruiken rond januari 2026. Ik schreef over die ervaring in een andereartikel.

Wanneer je voor het eerst het Forge-ecosysteem betreedt, realiseer je je snel iets belangrijks: het bouwen van de app is het gemakkelijke deel. Het begrijpen van deplatformbeperkingen en operationele metricsbepaalt echt of je app betrouwbaar presteert in productie.

En als je apps bouwt die bedoeld zijn voor deAtlassian Marketplace, wordt dit nog belangrijker.

Laten we het hebben over een van de meest misbegrepen onderdelen van Forge:aanroepen en metrics.

Begrijpen van de beperkingen van Forge

Forge is in wezen eenserverless hostingplatformbeheerd door Atlassian. Je backend-logica draait als functies binnen een beheerde runtime-omgeving.

Daarom opereert je app binnen bepaalde limieten, zoals:

• Beperkingen van hostinginfrastructuur

• API-snelheidslimieten

• Limieten voor functiememory

• Beperkingen voor persistente opslag

• Beperkingen voor sleutel-waardeopslag

• SQL-limieten

• Payloadgroottes

• Prestaties en uitvoeringstijd

Deze beperkingen bestaan om eerlijk gebruik en platformstabiliteit voor alle apps te waarborgen.

Vroegtijdig begrip zal je later ernstige hoofdpijn besparen.

Forge Runtime en Infrastructuur

Elke Forge-functie draait binnen een beheerde runtime aangedreven doorNode.js.

Elke aanroep ontvangt:

• 512 MB geheugen standaard

• configureerbaar geheugen tot1 GB per aanroepafhankelijk van de configuratie

Forge voert deze functies uit binnen een veilige cloudinfrastructuur beheerd door Atlassian. Vanuit een ontwikkelaarsperspectief beheer je geen servers, containers of schaling. Forge regelt dat allemaal automatisch. Dat gemak komt echter met limieten waar je omheen moet ontwerpen.

Wat is een Forge-aanroep?

Eenaanroepvindt plaats wanneer Forge een van je app-functies uitvoert.

Voorbeelden zijn:

• UI-acties die een resolver aanroepen

• Webtriggers

• geplande triggers

• evenementluisteraars

• achtergrondwachtrijconsumenten

• functies aangeroepen via "@Forge/bridge"

Elke van deze uitvoeringen telt als eenfunctieaanroep.

Forge registreert deze aanroepen om te monitoren:

• succespercentages

• fouten

• uitvoertijd

• resourceverbruik

Deze statistieken zijn zichtbaar in deOntwikkelaarsconsole.

Het belang van Aanroepen

Forge werkt op eenconsumptiemodel. Atlassian biedt een gratis niveau, maar gebruik daarboven kan extra kosten met zich meebrengen.

Daarom is elke aanroep belangrijk.

Dingen die het gebruik van aanroepen verhogen zijn onder andere:

• achtergrondverwerking van wachtrijen

• herhalingen

• geplande taken

• herhaalde API-aanroepen

• inefficiënte lussen

  
  

Als je app slecht geoptimaliseerd is, kunnen de aanroepentellingen zeer snel stijgen.

Het Forge Metrics Dashboard

Binnen deForge Developer Console, biedt Atlassian een metrics dashboard waar leveranciers de prestaties van de app kunnen volgen.

Je kunt bekijken:

• Aantal aanroepen

• Succespercentage van aanroepen

• Aanroepfouten

• Antwoordtijd van aanroepen

• API-metrics

• gebruiksmatrices (rekenkracht, opslag, logs)

Deze metrics helpen je te begrijpen hoe je app zich gedraagt over alle installaties.

Aanroepmetrics tonen specifiek:

• succesvolle vs. mislukte functie-uitvoeringen

• fouttypes zoals geheugenuitputting of time-outs

• uitvoeringsduur van functies

Voor leveranciers die productie-apps bouwen, is dit dashboard essentieel.

Begrijpen van aanroepfouten

De console groepeert aanroepfouten in categorieën zoals:

• Geheugen vol

• Time-outs

• Onbehandelde uitzonderingen

• Verouderd gebruik van runtime

  
  

Als je functie om een van deze redenen faalt, verschijnt de fout in het metrics dashboard.

Dit stelt je in staat om snel problematische functies over installaties te identificeren.

Begrijpen van Latentiepercentielen

Forge-metrics tonen ooklatentiepercentielen, die laten zien hoe snel je functies worden uitgevoerd.

Deze worden meestal weergegeven als:

P50 - Mediaan Reactietijd

P50 vertegenwoordigt demediaan uitvoeringstijd.

Dit betekent:

50% van alle functie-aanroepen zijn voltooidsneller dan deze 165ms.

Deze metric vertegenwoordigt detypische prestatiesvan je app.

Voor Forge-apps:

• <150 msis doorgaans uitstekend.

P95 - Zware Uitvoeringsrange

P95 betekent:

95% van alle aanroepen zijn voltooidbinnen een bepaalde tijd.

Slechts 5% van de verzoeken duurt langer.

Hogere P95-waarden duiden meestal op:

• zwaardere database- of opslaglezingen

• grote gegevensverwerking

• complexe API-interacties

P99 - Slechtste Geval Prestaties

P99 vertegenwoordigt delangzaamste uitvoeringen.

Slechts 1% van de verzoeken is langzamer dan deze waarde.

Deze komen vaak voor tijdens:

• koude starts

• grote payloadverwerking

• vertragingen van externe API's

• herhalingen of zware berekeningen

Wanneer Prestaties een Probleem Worden

Als algemene richtlijn voor Forge-apps:

Prestaties kunnen onderzoek vereisen wanneer:

• P50 > 500 ms

• P95 > 2 seconden

• P99 > 5 seconden

Wanneer deze cijfers consistent toenemen, betekent dit meestal dat de app heeft:

• inefficiënte logica

• overmatige API-aanroepen

• zware verwerking binnen een enkele functie

Hoe herhalingen de aanroepkosten kunnen beïnvloeden

Een van de gemakkelijkste manieren om per ongeluk het gebruik van aanroepen te verhogen, is doorherhaallogica.

Bijvoorbeeld, als je een wachtrijconsument hebt die taken verwerkt en er iets mislukt, kan Forge die taak automatisch opnieuw proberen, afhankelijk van je architectuur.

Zonder waarborgen kunnen herhalingen herhaaldelijk plaatsvinden.

Als een taak grote datasets verwerkt, bijvoorbeeld een JQL-query die duizenden problemen retourneert; kan elke herhaling extra functie-aanroepen activeren. Na verloop van tijd kan dit het computgebruik aanzienlijk verhogen.

Een eenvoudig defensief patroon is het beperken van het aantal herhalingspogingen.

Voorbeeld:

const jobId = event.jobId;
const retryContext = event?.retryContext;

if (retryContext?.retryCount > 2) {
// the logic to handle retries
await jira.cancelJob(jobId);
}


Dit voorkomt ongecontroleerde herhalingen en beschermt zowel de prestaties als de aanroepkosten.

Waarom leveranciers regelmatig statistieken moeten monitoren

Statistieken zijn niet alleen diagnostische hulpmiddelen.

Ze zijn een van de beste manieren omje app-architectuur te verbeteren.

Met het Forge-statistieken dashboard kun je detecteren:

• prestatie regressies

• API-flessenhalzen

• inefficiënte queries

• problemen met koude starts

• schaalproblemen

Je kunt statistieken ook filteren op:

• omgeving

• site-installatie

• tijdspanne

• functiehandler

Dit maakt het mogelijk om de prestaties over meerdere klanten te volgen.

Conclusie

Forge verwijdert veel operationele complexiteit voor ontwikkelaars. Je beheert geen servers, schaling of infrastructuur.

Maar dat betekent niet dat infrastructuurproblemen verdwijnen.

Begripvan aanroepen, statistieken en platformlimietenis cruciaal als je wilt dat je app betrouwbaar schaalt.

Het Forge-statistieken dashboard is een van de krachtigste tools die beschikbaar zijn voor leveranciers. Correct gebruikt, stelt het je in staat om problemen vroegtijdig te identificeren, je functies te optimaliseren en een veel betrouwbaardere ervaring aan je klanten te bieden.

En als je Marketplace-apps bouwt, is betrouwbaarheid geen optie, het is een vereiste.