DutchBud: van Laravel API naar Go, OTAP CI en ACC-regressiepoorten

geplaatst in: Uncategorized | 0

Gepubliceerd juli 2026 · Infrastructuurnotities van 3DN

DutchBud is onze persoonlijke bankapp — een Android-client die via een JSON-API met bank.dutchie.org praat. Van “werkt op mijn laptop” naar “werkt op mijn telefoon over WireGuard om 02:00” ging via DNS, OTAP-deploypijplijnen, een bewuste Laravel→Go API-splitsing en een regressietest die elke Acceptatie-release vergelijkt met productie-vormige data. Dit bericht is de rondleiding.

DutchBud-app op een smartphone verbonden met on-premises bankinfrastructuur
DutchBud op de telefoon; de API en OTAP-stack erachter op hardware die wij beheren.

DutchBud end-to-end opzetten

De stack is expres saai — en dat is een compliment:

  • Android-client — Kotlin-app met token-auth tegen /api/*-endpoints.
  • Laravel-webapp — bedient nog steeds de browser-UI, migraties en OTAP-deployscripts in een eigen webroot per omgeving.
  • Go bank-api — productie-JSON-API op gekoppelde applicatieservers als systemd-service; nginx routeert /api/ via HAProxy naar Go, Laravel houdt de rest.
  • Edge-toegang — WireGuard-clients resolven interne namen via onze autoritatieve DNS; bank.dutchie.org bereikt de Thailand-DMZ-front op het privénetwerk.

Vroeg testen op de telefoon bracht een klassieke ops-valstrik aan het licht: een rogue BIND-instance op de gateway die DNS beantwoordde met kapot AAAA-gedrag, zodat WireGuard-resolutie prima leek tot het dat niet meer was. Clients naar de juiste autoritatieve resolver wijzen, de stray service stoppen en port forwarding herstellen bracht voorspelbare resolutie terug. Login-422’s bleken bereikbaarheid, geen foute credentials — zodra DNS en routing eerlijk waren, werkte de app weer.

Ontwikkelbureau 's nachts met Android-telefoon en terminal
Het onglamoureuze deel van mobiel bankieren: DNS, tokens en genoeg koffie voor de API-servicelogs.

Waarom we de API van Laravel naar Go verplaatsten

Laravel is uitstekend voor productsnelheid. Minder uitstekend wanneer elke API-call de volle PHP-framework-bootstraptax betaalt op een pad dat de Android-app tientallen keren per sessie raakt. We maten op dezelfde hosts vóór we committten:

  • Alleen Laravel-framework-bootstrap: ~100 ms vóór uw controller draait.
  • Go GET /api/bank-accounts: ~12 ms op localhost.
  • Go GET /api/payments?page=1: ~150 ms (database-gebonden, niet framework-gebonden).
  • Go POST /api/login: ~280 ms — bcrypt domineert nog; de winst zit elders.

Beslissingscriteria waren praktisch, niet ideologisch:

  1. Latency op warme JSON-paden — rekeningen en lijst-endpoints moeten op mobiel instant aanvoelen.
  2. Geheugenvoetafdruk — een klein Go-binary per node wint van PHP-FPM-pools voor een read-heavy API.
  3. Operationele eenvoud — één statisch binary, gestructureerde logging, configuratie op de API-host.
  4. Laravel houden waar het blinkt — Blade-UI, Eloquent-migraties, bestaande OTAP-playbooks ongewijzigd.
Staafdiagram vergelijking Laravel en Go API-latency op bank-endpoints
Gemeten vergelijking die de splitsing rechtvaardigde: Go op /api/, Laravel op het weboppervlak.

OTAP CI — van dev-push tot productiepoort

De bankapplicatie is onze OTAP-pilot. GitLab CI op een dedicated runner deployt per branch:

  • dev → Ontwikkel, daarna fast-forward tst → Test.
  • Commits moeten Refs #N bevatten; de pipeline post “Ready for Test” op het gekoppelde issue.
  • acc → handmatige Acceptatie-deploy na klantgoedkeuring op Test.
  • master → handmatige Productie.

Deploy is een gehard SSH git-checkout op de applicatiehost: fetch, hard reset naar de pipeline-SHA, rechten herstellen, omgevingssetup waar aanwezig. Geen rsync-mysteries — alleen git-waarheid op elk stage.

Diagram DutchBud OTAP GitLab CI-stages van dev tot regressiecheck
OTAP-flow inclusief de ACC-regressiestages die we op de acc-branch toevoegden.

Regressietesten op echte productievorm

Acceptatie is geen speelgoeddatabase. Na handmatige deploy:acceptatie draait CI:

  1. sync:prod-db-to-acc — kopieer productiedata naar de acceptatiedatabase plus sync van receipt-storage.
  2. migrate:acc — pending Laravel-migraties op ACC.
  3. regression:check — hamer op de live ACC-API en vergelijk met een gecommitte baseline.

De harness staat in de bank-api-repository. Vier scenario’s — login, bank-accounts, budget-posts, payments pagina 1 — elk 20 sequentiële iteraties (~6 seconden totaal). Per scenario leggen we HTTP-status, een shape hash van de JSON-payload (structuur en keys, geen volatile waarden) en p95-latency vast. Initiële baseline na prod-sync: login p95 598 ms, bank-accounts 116 ms, budget-posts 184 ms, payments 178 ms, tegen 58 betalingen en 3 rekeningen.

De check-job faalt de pipeline bij shape-wijziging of p95 boven baseline × tolerantie (1,25× default, 1,5× voor login). Nieuwe baseline na een bewuste API-wijziging? Draai handmatig regression:capture en commit de bijgewerkte baseline in de bank-api-repo. Resultaten komen in het GitLab-joblog — geen externe SaaS nodig.

Diagram ACC-regressieflow van productiedatabasesync tot baseline-vergelijking
Productie-vormige ACC-data → gescripte API-probes → gecommitte baseline-poort.

Wat we leerden

Mobiele apps straffen kleine infrastructuurzonden af. DNS die bijna werkt is erger dan DNS die duidelijk faalt. API-runtimes splitsen is prima wanneer de grens nginx is en het contract JSON. OTAP verdient vertrouwen wanneer Test en Acceptatie mechanisch verschillen — handmatige promotie plus geautomatiseerde regressie op prod-vormige data is dat verschil.

DutchBud is persoonlijke software op professionele rails. De volgende keer dat een groen rekeningenscherm in onder een seconde laadt over WireGuard — dat is Go, PowerDNS, GitLab CI en een baseline-bestand dat zegt: “nog steeds dezelfde vorm als gisteren.”

Vragen over onze infrastructuur of hostingaanpak? Neem contact op.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *