Frameworkless Python

Bij West Consulting zijn we altijd op zoek naar innovatieve IT-oplossingen voor onze klanten. Deze keer ligt er een vraagstuk van een klant om een applicatie te ontwikkelen die facturen uitleest en wegschrijft in registratiesysteem Odoo. Een zeer belangrijk proces binnen de organisatie van de klant. Stan Guldemond, software developer bij West Consulting, gaat op zoek naar het best passende proces en een oplossing om deze applicatie te ontwikkelen. Hij onderzoekt hierbij ook of er beter een framework of frameworkless applicatie gemaakt moet worden.

Ontwikkelen van applicatie met Python

In het proces bekeek Stan in eerste instantie samen met de klant de grote lijnen binnen de applicatie. Hierna onderzocht hij stap voor stap de details om te bekijken wat er precies moest gebeuren, wanneer en waarom. Na het zorgvuldig uittekenen van deze processen, ging hij aan de slag met het ontwikkelen van de applicatie.

Stan: “We kozen voor Python omdat de huidige scripts hierin zijn geschreven en de klant hier goed bekend mee is. Ik programmeer zelf ook graag met Python. Tijdens het bestuderen van de processen kwam er niet zo snel een framework naar boven wat hier goed op aansloot. De gevraagde functionaliteit was heel specifiek en paste niet direct binnen bijvoorbeeld Django of FastAPI. Ik besloot daarom geen framework te gebruiken, maar om een frameworkless applicatie te bouwen.”

Python Packages

Op basis van de functionaliteiten bekeek Stan welke Python Packages erbij pasten. “Er moesten in dit geval e-mails worden uitgelezen uit een e-mail account. Het eerste wat ik deed is via een zoekmachine zoeken op termen als reading e-mail python. De voorbeelden en artikelen gaf me informatie over het uitlezen in Python en dat er bijvoorbeeld veel gebruik gemaakt werd van IMAPClient. Vervolgens zocht ik op PyPI (de standaard repository voor Python Packages) wat ik over IMAPClient kon vinden. Naast het zoeken naar de meest recente release was ook het beoordelen van de kwaliteit van de documentatie belangrijk. Nadat ik zeker wist dat het een stabiel project was, kon ik aan de slag met het schrijven van throw away code.”

Throw away code en verzamelen

Stan schreef de throw away code in een apart project en leerde hierbij vooral de API van een package te begrijpen. “Deze code base werd gaandeweg een verzameling van allerlei probeersels. Nadat ik de API begreep, kon ik beginnen met het schrijven van een productiecode in het hoofdproject.”

Op deze manier ging Stan voor elke functionaliteit op zoek naar een geschikte package. “Soms was ik al bekend met een specifieke package die ik goed kon gebruiken. Bij sommige functionaliteiten was er nog geen complete oplossing. In dergelijke gevallen schreef ik alle codes zelf.”

Projectstructuur

Omdat Stan geen framework gebruikte, was het soms wat puzzelen om een goede projectstructuur op te zetten. Stan: ”Ik keek in dit geval graag naar hoe andere frameworks, zoals Django of FastAPI, zijn opgebouwd en liet mij daardoor inspireren.

Conclusie

Het kiezen voor een framework of frameworkless is afhankelijk van verschillende factoren: Wat is de gevraagde functionaliteit? Welke technische kennis ligt er bij de klant? Ontwikkel je alleen of in een team? Een nadeel van frameworkless is dat je een afhankelijkheid creëert van veel verschillende open source ontwikkelaars, en je weet maar nooit of een gekozen package in toekomst ondersteund zal blijven. “Daarom ben ik altijd heel voorzichtig met het gebruiken van packages en is het belangrijk dat afhankelijkheden goed worden gedocumenteerd. Het belangrijkste is dat wat je oplevert voldoet aan de vraag van de klant. Met in het achterhoofd dat wat je ontwikkelt voor een langere tijd draaiend en onderhoudbaar moet blijven, ook nadat jezelf misschien niet meer betrokken bent bij het product.”