* tromgeroffel *

We hebben het voor elkaar!

📣De GraphQL backend draait met Nameko!

Nameko ftw. Flask lost.  

Flask is nu de deur uit. Dus ook geen Graphiql client meer. In ieder geval voorlopig. Maar... onze graphql interface is zojuist zelf een paddo geworden!     * de menigte draait bijna door *    De performance is verbijsterend. Wat eerder bijna 200 a 300 miliseconden duurde, gaat nu tussen de 20 en de 120. Doorgaans... We hebben met 5 man maximaal geprobeerd het ding op de knieën te krijgen, maar dat is mislukt. Api-Umbrella strafte ons af omdat we meer dan 10.000 requests hadden gedaan binnen 1000 seconden. Effectief in ongeveer 5 minuten. Maar hij gaat door. De snelheid voor inloggen, bladeren, nieuwe gebruikers enz is gigantisch verbeterend en de ervaring van de gebruiker met het bladeren door de front-end is een enorm stuk aangenamer... En stabieler.

Al die moeite voor performance?  

Nee.. De performance winst van Nameko boven Flask is voornamelijk een "collateral benefit". De voornaamste reden was dat we toenkomstbestendiger zijn (ivm schaling van de front-end) en dat we microservices nu ècht gebruiken. Al is het er maar één, het is nu wel een microservice in ons microservice platform.  Maar we kunnen nu nog gemakkelijker gebruik maken van microservices, extra diensten rechtstreeks op onze backend, speciaal voor beheer en administratieve toepassingen, zonder dat deze voor de buitenwereld beschikbaar zijn. Een betere beveiliging bestaat niet.    Daarnast is de boel heftig versimpeld en dat is misschien wel het grootste voordeel. Nu is het werken aan functionaliteit weer zo veel gemakkelijker geworden; dat het ineens kan opschieten met die functionaliteit. Verder maken we veel beter gebruik van onze database resources omdat we beter met de verbindingen omgaan. En we zijn van een threading gebaseerde oplossing overgegaan naar een greenthread (eventlet) onderstel. En dat maakt het één en ander ook meer future-proof.    Dus we integreren, versnellen, vereenvoudigen, stabiliseren, doen wat we beloven en maken veel meer mogelijk.    Omdat de graphql servers nu Nameko microservices zijn, melden ze zich bij RabbitMQ. We hoeven dus niet "op zoek" naar waar ze staan. We geven gewoon een bericht aan Rabbit door, en ze komen wel aan bij de graphql-servers. Dus als een item verwijderd of geupdate wordt, kunnen we de notificatie rechtstreeks doorgeven aan de graphql servers, die hun interne buffers nu kunnen aanpassen, zonder dat ze een herstart nodig hebben. Deze functionaliteit moet er nog in, maar het gebrek aan die mogelijkheid was één die uiterst frustreerde.  In het overleden design van de microservices (wat we nu weer langzaam aan gaan integreren) hadden we een probleem met het versturen van events naar GraphQL. Daar hebben we creatieve oplossingen voor bedacht, maar dat is allemaal niet meer nodig.

Supervisor als beheerder van processen  

Nu is supervisor ook écht in gebruik genomen en hebben we de voordelen daarvan al kunnen plukken. Met de komende microservices (wat allemaal processen zijn die moeten worden beheerd) wordt dat alleen nog maar mee.   Al met al was er hier even een 🎂-stemming. Tijd voor functionele voortgang.