Backend en API's

Backendsystemen en API's die onder belasting overeind blijven

Wij ontwerpen en bouwen het deel van het product dat niemand ziet tot het stukgaat: API's, datamodellen, authenticatie en de koppelingen die een bedrijf bijeenhouden.

Waar backends gewoonlijk misgaan

Backendproblemen gaan zelden over rauwe snelheid. Ze gaan over een datamodel dat klopte voor de eerste versie en nu drie joins en een subquery vergt om een routinevraag te beantwoorden; over een API die HTTP 200 teruggeeft met een fout in de body, zodat elke client moet raden; over koppelingen die om drie uur 's nachts stil falen en twee weken later via een klachtmelding worden ontdekt.

De kostbare beslissingen vallen vroeg en zijn moeilijk terug te draaien. Hoe het schema is genormaliseerd, waar de grenzen tussen services liggen, hoe authenticatie en autorisatie gescheiden zijn, of de API versiebeheer kent. Het fout hebben is een tijdlang te overleven en dan opeens niet meer.

Wij besteden liever een week aan het datamodel dan een kwartaal aan het migreren ervan.

Wat wij bouwen

API's ontworpen voor hun afnemers

REST of GraphQL, gekozen op basis van de clients die hem gaan gebruiken en niet op voorkeur. Consistente foutafhandeling met juiste statuscodes, paginering die werkt op grote collecties, en versiebeheer dat er staat vΓ³Γ³rdat u het nodig heeft β€” want het achteraf inbouwen terwijl clients live zijn, is pijnlijk.

Datamodellen die de volgende functie overleven

Schemaontwerp met de query's in gedachten die u werkelijk gaat draaien, passende indexering, en migraties die omkeerbaar zijn. Wij zetten relationele, document- of grafendatabases in naar de vorm van de data in plaats van uit gewoonte.

Authenticatie en autorisatie, gescheiden gehouden

Sessie- of tokenauthenticatie volgens de huidige praktijk, en een rechtenmodel dat bij elk verzoek op de server wordt gecontroleerd. Wie u bent verwarren met wat u mag doen, is een van de vaakst voorkomende oorzaken van fouten in toegangscontrole.

Koppelingen die hoorbaar falen

Verbindingen met derden met herhaalpogingen, backoff, idempotentie en een dead-letterafhandeling, plus alarmering zodra iets stilvalt. Een mislukte koppeling hoort iemand op te piepen, niet in stilte op te stapelen.

Achtergrondwerk en planning

Wachtrijen voor alles wat traag, onbetrouwbaar of piekerig is β€” imports, exports, documentgeneratie, meldingen β€” zodat een gebruikersverzoek nooit op een derde partij hoeft te wachten.

Waarneembaarheid vanaf de eerste deploy

Gestructureerde logging, health checks en meetwaarden op de paden die ertoe doen. Een productiestoring diagnosticeren hoort een query te zijn, geen opgravingsexpeditie.

Technologie die wij hiervoor gebruiken

Runtime

  • Node.js
  • Express
  • TypeScript

PHP

  • Laravel
  • PHP

API

  • REST
  • GraphQL
  • OpenAPI
  • Webhooks

Databases

  • MySQL
  • MongoDB
  • Neo4j

Beheer

  • Docker
  • Azure
  • GitHub Actions

Wij kiezen hieruit op basis van wat het project nodig heeft en wat uw team na de overdracht kan onderhouden β€” niet op basis van waar wij het liefst mee werken. Ligt er al een gezonde technische basis, dan werken wij daarbinnen.

Typische opdrachten

Een API voor een mobiele of webclient

De serverkant bouwen van een product waarvan de interface al is ontworpen of al is gebouwd, inclusief de authenticatie en het datamodel eronder.

Een trage database redden

Queryprofilering, indexwerk en schemawijzigingen op een systeem dat zijn oorspronkelijke ontwerp is ontgroeid. Vaak goedkoper en sneller dan de infrastructuuruitbreiding die in plaats daarvan wordt overwogen.

Een monoliet selectief opdelen

De delen van een grote applicatie eruit halen die werkelijk onafhankelijk moeten kunnen schalen of uitrollen β€” en de delen die dat niet hoeven met rust laten, en dat zijn er meestal de meeste.

Systemen verbinden die niet met elkaar praten

Koppelwerk tussen platformen met onverenigbare aannames over identiteit, timing en datavorm. De waarde zit in het netjes afhandelen van de randgevallen.

Vragen die ons hierover worden gesteld

Node.js of Laravel β€” wat moeten we kiezen?

Beide kunnen serieuze productiesystemen draaien, dus de keuze komt meestal neer op context in plaats van benchmarks. Node met TypeScript laat u typen en taal delen met een React-frontend, en past bij realtime en I/O met veel gelijktijdigheid. Laravel geeft u veel structuur uit de doos β€” authenticatie, wachtrijen, planning, een ORM β€” waarmee u bij gangbare bedrijfsapplicaties meestal sneller bij een werkend product bent. De vaardigheden van uw bestaande team horen zwaar te wegen, want onderhoudbaarheid duurt langer dan de bouw.

REST of GraphQL?

REST is eenvoudiger te cachen, eenvoudiger te debuggen en toereikend voor de meeste applicaties. GraphQL verdient zijn extra complexiteit wanneer veel verschillende clients verschillende vormen van dezelfde data nodig hebben, of wanneer mobiele clients te veel heen-en-weerverkeer veroorzaken. GraphQL kiezen voor één webclient voegt meestal werk toe zonder navenant rendement.

Kunt u een bestaande backend verbeteren in plaats van vervangen?

Meestal wel, en dat is normaal gesproken de betere economie. Wij beginnen met profilering en een review, en pakken dan de specifieke knelpunten aan. Volledige herschrijvingen zijn een laatste redmiddel β€” ze duren langer dan iemand schat en leggen het werk aan functionaliteit stil zolang ze lopen.

Verzorgt u hosting en deployment?

Wij richten de deploypijplijn, containerisatie en omgevingen in, en kunnen de infrastructuur doorlopend beheren of met documentatie aan uw team overdragen. De accounts blijven hoe dan ook op uw naam staan.

Hoe gaat u om met beveiliging?

Servervalidatie op elke invoer, geparametriseerde query's, geheimen buiten de repository, scannen van afhankelijkheden in CI, toegang volgens least privilege, en actuele praktijk voor wachtwoordopslag en sessiebeheer. Wij zijn geen pentestbureau; voor systemen met gereguleerde data adviseren wij daarnaast een onafhankelijke beoordeling.

Denkt u aan backend en api's?

Stuur ons het probleem en de beperkingen die u al kent. Wij komen terug met wat wij denken dat het vraagt, een aanpak en een realistische orde van grootte β€” of met de mededeling dat wij hier niet de juiste partij voor zijn.

Begin een gesprek