.Net Aspire, .Net Orleans, OpenAI Assistants API en Blazor 8

Niemand minder dan Richard Campbell, bekend van onder andere de .Net Rocks podcast, trapt vandaag Techorama af. Hij trakteert ons op de geschiedenis van, hoe kan het ook anders: Artificial Intelligence. Hij herinnert ons er fijntjes aan dat AI al decennia bestaat, in allerlei vormen en gedaanten. En dat de term AI door de tijd heen telkens opnieuw wordt “uitgevonden” en daarbij keer op keer vooral een marketing term is, om het publiek te hypen en om groot geld op te halen. Het grootste deel was saai en viel in herhaling. Maar de talk bouwde wel op naar een grote ethische waarschuwing voor ons, de developers. Want nu AI in staat is om geloofwaardige tekst, beeld en video en daarmee op grote schaal fake news te produceren, is aan ons developers DE KEUZE om AI in te zetten voor een betere wereld. We Choose.

Chris Klug geeft me een introductie van .Net Aspire. Dit nieuwe opinionated dotnet framework is absoluut veelbelovend.

Het maakt dat je vanuit C# op een simpele maar krachtige manier een online applicatie-omgeving orchistreert. Het geeft me vibes van bicep en docker compose, direct in code in je dotnet applicatie. Met enkele simpele commando’s voeg je een sql database toe of een van de vele andere ondersteunde services. Het framework zorgt er op de achtergrond voor dat de connection strings in je app bestaan en dat de services ook daadwerkelijk ergens worden opgespind. Later kan je ARM scripts laten genereren om de hele handel in Azure te hosten. Alles wordt automatisch met OpenTelemetry geconfigureerd en er is een dashboard met logs en metrics enzovoorts, ook in je lokale omgeving. Draai je lokaal, dan zijn automatisch alle betrokken apps aan de debugger gekoppeld en services zoals sql of een keyvault worden ofwel gesimuleerd, ofwel automatisch in Azure aangemaakt. Het is mogelijk om het in een bestaand project te integeren. Dit framework zou weleens een heel groot publiek kunnen gaan krijgen.

Na de lunch vertelt Anjuli Jhakry me over .Net Orleans. Deze jongedame bevestigt meteen mijn gedachte: het framework bestaat al jaren, maar het is desondanks minder bekend. Dat komt door de wat mij betreft beperkte use case. Je kunt met DI data-objecten injecteren en Orleans garandeert dat binnen je hele cluster altijd dezelfde instance wordt aangesproken. Dit werkt doordat het onder water eventual consistency voor je regelt. Op deze manier is je applicatie eenvoudig schaalbaar tot een groot cluster. Denk aan een distributed game waarbij elke speler dezelfde state moet hebben. Sterker nog: Orleans is onstaan uit de codebase van Halo.

Even later neemt de solution architect van Buienrader ons in rap tempo mee naar alle hoeken van hun absoluut indrukwekkende platform. Hij geeft me ook nog eens een diepgaand lesje meteorologie! Hij vertelt ons hoe zij in de afgelopen jaren zijn getransformeerd van een monoliet naar een kubernetes omgeving, wat met name de oplossing is voor hun uiteraard extreme piekbelastingen. Zijn talk staat bol van de informatie, er is enorm veel verteld in een uur tijd.

Jeff Prosise sluit mijn eerste dag af. Hij verrast me positief. Ik wist van eerdere jaren dat het super interessant ging worden. Maar dit keer begreep ik ook nog eens waar het precies over ging, lol. Jeff is een machine learning veteraan en in eerdere sessies sprak hij vol passie over het programmeren van neurale netwerken en over hoe Generative AI precies werkt, wat super interessant is, maar waar ik eigenlijk er geen zak van begreep. Vandaag ging het over OpenAI en dan met name de Assistants API. Hiermee kan je de, normaalgesproken contextloze antwoorden, sturen of verrijken met gesprekscontext, lokale function calls, inhoud van specifieke documenten en zelfs informatie uit databases. Maak bijvoorbeeld een zoekfunctie die alleen in jouw eigen bedrijfsdocumenten zoekt en ook nog vermeldt uit welk document het antwoord kwam. Plus, niet onbelangrijk: je kan de LLM instrueren om nooit te hallucineren maar in plaats daarvan toe te geven dat ze het antwoord niet heeft.

Jason Taylor vertelt over ‘Clean Architecture‘. Bah ik hoopte op wat slimme architectuur tips, maar het gaat letterlijk om de ‘Clean Architecture’ methode. Hij laat zien hoe je automatisch CQRS code kan scaffolden, dus commands, queries en handlers. Bah wat vind ik dit een slecht idee. Hij heeft vast nog nooit zo’n project hoeven onderhouden of upgraden. Al die code duplicatie en fluff in commandhandlers, ik heb hier persoonlijk vooral slechte ervaringen mee. Gelukkig zegt hij zelf: Clean Architecture is niet voor elk project geschikt, dus denk daar wel over na. Het wordt nog erger: met de Azure Developer CLI (azd) kan je voor je project automatisch een github pipeline laten genereren waardoor je project automatisch naar Azure wordt uitgerold, inclusief het automatisch genereren en instellen van github (deployment-) secrets en een principal in Azure. Opnieuw geinig dat je dit kan genereren, maar ook dit vind ik een slecht idee: imho is het beter om bij de start van een project alvast de leertijd te pakken om daadwerkelijk te begrijpen hoe je zelf zo’n pipeline en rechten inricht en wat je eigenlijk precies aan het doen bent. Want je kunt er op wachten dat het een keer kapot gaat of dat je het moet upgraden.

Dan weer iets echt leuks: Rockford Lhotka deelt zijn enthousiasme over Blazor 8. Altijd prettig om naar “Rocky” te luisteren, hij heeft er duidelijk veel plezier in. Zijn boodschap: Blazor 8 is echt briljant, want vanaf nu is de Blazor render modus default “automatisch”. Waar je in de eerste versie van Blazor expliciet moest kiezen tussen “server mode” en “webassembly” mode, kan blazor dit nu helemaal zelf bepalen, voor de optimale gebruikservaring. De eerste page load is bij voorkeur “server static”, omdat dit het snelste inlaadt. Blazor schakelt vervolgens zelf naar “server interactive”, waarbij dus een actieve server-connectie is opgezet. Tenslotte, wanneer de browser alles heeft ingeladen, wordt geschakeld naar “webassembly”, waarna de meeste acties als een SPA werken. Ik vind dit een super slimme ontwikkeling, want op deze manier krijg je het beste van beide werelden. Rocky legt uit hoe je hier mee moet omgaan. Want soms wil je in code weten in welke render modus je zit, om bijvoorbeeld formulierelementen alleen te tonen wanneer je in een interactieve modus bent. Een ander belangrijk aspect van Blazor 8 is dat je niet meer sessies zomaar kunt koppelen aan een “scoped” object: je moet nu een slimmere oplossing implementeren bij te werken met sessie data.

Tenslotte is daar Adam Ralph. Zijn grootste punt: sommige performance-lastige taken die je nu met cronjobs oplost, zoals bijhouden van bepaalde statistieken, kan je ook anders/beter aanpakken. Hij komt met een imho super ingewikkelde oplossing, waarbij vereist is dat je een service bus gebruikt die de feature heeft om berichten “in de toekomst” af te leveren. Met daarbij de constatering dat zo goed als alle ESBs dit juist niet ondersteunen. Super handig dus maar niet heus. Maar zijn punt is zeker interessant: heb je te maken met hoge load en kost het genereren van statistische data je nu hoofdpijn, let dan op. Stel je wilt weten of een bepaalde gebruiker vaker dan 3x per week een verdachte transactie uitvoert. Dit kan je oplossen met een zware query die je in een cronjob stopt. Of nog erger, als je een DBA hebt rondlopen: direct in de database. Adam zegt: een veel betere manier is om gebruik te maken van een SAGA. Bij elke transactie zet je een message op de queue. Je berekent de statistiek nu incrementeel (acties = acties + 1). Plus je zet een nieuwe message op de queue die je “over 7 dagen” moet afleveren met als inhoude: “acties = acties – 1”. Een betere uitleg vind je op deze link. Ja, dit is uit 2019 lol.