The proof is in the pudding: werkt de NLX standaard in een gateway uit de markt?

Wat is NLX

NLX is de software waarmee VNG-R en haar stakeholders leren hoe de digikoppeling standaard voor REST profielen er uit zou moeten zien en waarmee een federatieve datalandschap ondersteunt kan worden vwb connectiviteit. We hebben geleerd dat er veel waarde zit in een standaard die meer voorschrijft dan op dit moment het geval is. Door op een uniforme wijze met koppelingen om te gaan, is automatisering mogelijk en ontstaan nieuwe mogelijkheden waarmee de toegevoegde waarde alleen maar toeneemt. Het doel van de software is dus leren hoe de standaard er uit moet zien om vervolgens, niet onbelangrijk, die standaard ook te beschrijven en vast te laten stellen.

Experiment met een bestaande gateway: Tyk

We hebben dit experiment gedaan om gevoel te krijgen bij de toepasbaarheid van de toekomstige standaard voor andere ontwikkelaars. We hebben gekozen voor de open source variant van Tyk omdat deze uitbreidbaar/aanpasbaar is door de mogelijkheid eigen plugins te schrijven die inhaken op de werking van Tyk. Daarnaast is Tyk in Golang geschreven net als NLX en dus geeft de taal geen extra uitdaging voor het team.

Resultaat van het experiment

Het experiment met Tyk is geslaagd zoals in het filmpje te zien is. De setup was een NLX Outway die praat met een Tyk Inway welke vwb NLX gemanaged werd door de NLX management API. We hebben mbv de management UI een toegangsverzoek via de NLX Outway verstuurd naar de Tyk Inway waar deze is goedgekeurd. Die status is opgehaald door de Outway en vervolgens is een data request gedaan via de Tyk Outway waarop een response van de API via de Tyk Inway teruggestuurd is. Een gedetailleerde weergave van de setup is hier te zien.

Leerpunten

Het doorsturen van het management verkeer via de Inway (als proxy) is geen onderdeel van de standaard.

Tijdens het bouwen van de uitbreiding op Tyk werd duidelijk dat de wijze waarop NLX het management verkeer door proxied via de Inway naar de Management API afhankelijk is van de mogelijkheden van de software die gekozen is. IN de NLX software haalt de Inway informatie over een organisatie uit het certificaat en voegt deze informatie als gRPC metadata toe aan het request. Het management verkeer wordt ontvangen door Management API, een gRPC server, die de informatie uit het request haalt. Zonder deze informatie kan de Management API geen verzoeken verwerken. Tyk 'spreekt' geen gRPC maar proxied het verkeer gewoonweg door naar de Management API en kan door de beperkingen van Tyk alleen HTTP headers toevoegen.

We zijn tot de conclusie gekomen dat de betreffende endpoints bij de Inway horen en dat het de keuze is aan de implementatie hoe en waar die endpoints verwerkt worden. De endpoints stonden al bij de Inway beschreven maar we voelden op dit punt het verschil tussen de standaard en de implementatie heel duidelijk en dat is waardevol voor de mindset van het team.

Foutmeldingen, codes en benodigde metadata centraliseren

Tijdens het schrijven van de plugins merkten we dat de wijze waarop we op dit moment omgaan met foutmeldingen in de NLX software beter kan. Het centraliseren van alle error codes, meldingen en ook de velden die per melding toegevoegd moeten worden, helpt bij het beschrijven van de standaard en daarna het implementeren daarvan.

Zelf ook experimenteren?

Wij hebben dit experiment met Tyk gedaan maar uiteraard kan met iedere software eenzelfde proef gedaan worden. Je loopt dan vooraan mee bij de invulling van de standaard en bouwt al in een vroeg stadium kennis op over de impact van de toekomstige standaard. Team NLX ontvangt je bevindingen graag om waar mogelijk te verwerken in de standaard.