De Devschuur Coffee Corner - Iteratie ⑬

[Hydra]

.oisyn schreef op woensdag 15 december 2021 @ 02:05:
[Twitter]

Vandaar dat URL al een hele tijd deprecated is

Edit: Spuit 11.

[ Voor 3% gewijzigd door Hydra op 15-12-2021 17:59 ]

[gekkie]

Hydra schreef op woensdag 15 december 2021 @ 17:57:
[...]


Vandaar dat URL al een hele tijd deprecated is

Maar op z'n PHPsiaans nooit echt verwijderd ?

[Sebazzz]

.oisyn schreef op woensdag 15 december 2021 @ 02:05:
[Twitter]

Toen zijn een aantal Java ontwikkelaars Javascript gaan ontwikkelen, wat alles beter moest maken. Een betere taal, een beter ecosysteem.


Dat is niet wat is gebeurd, Maar had gekund!

[Firesphere]

We don’t need everyone to upgrade log4j, just enough for herd immunity to takeover

— Ricky (@rickhanlonii) 12 december 2021

---
Oy, hoe doe je die twitter embed dinges?
---
Ah, zo dus

[ Voor 56% gewijzigd door Firesphere op 16-12-2021 09:54 ]

[azerty]

We don’t need everyone to upgrade log4j, just enough for herd immunity to takeover

— Ricky (@rickhanlonii) 12 december 2021

@Firesphere zo

[Hydra]

gekkie schreef op woensdag 15 december 2021 @ 17:59:
Maar op z'n PHPsiaans nooit echt verwijderd ?

Nouja, URL domweg verwijderen zou echt een hoop dingen stukmaken. Java maakt in principe geen breaking API changes. Da's ook de reden dat collections zoals Vector nog in de API zitten.

[ThomasG]

gekkie schreef op woensdag 15 december 2021 @ 17:59:
[...]

Maar op z'n PHPsiaans nooit echt verwijderd ?

Nee, om dezelfde reden dat ze ontwerpfouten nooit hebben rechtgetrokken: backwards compatibility. Je kunt een programma gemaakt voor JDK 1.5 draaien op bijvoorbeeld JDK 17. Als ze het verwijderen kan dat niet meer.

[mcDavid]

Wat dat betreft een sterk contrast met PHP wat bijvoorbeeld de `mysql` api gewoon verwijderd heeft toen er iets beters voor in de plaats gekomen was.

[Mugwump]

mcDavid schreef op donderdag 16 december 2021 @ 11:09:
Wat dat betreft een sterk contrast met PHP wat bijvoorbeeld de `mysql` api gewoon verwijderd heeft toen er iets beters voor in de plaats gekomen was.

Of Python waar men weet ik hoe lang twee parallelle versies in stand hield.

[gekkie]

mcDavid schreef op donderdag 16 december 2021 @ 11:09:
Wat dat betreft een sterk contrast met PHP wat bijvoorbeeld de `mysql` api gewoon verwijderd heeft toen er iets beters voor in de plaats gekomen was.

Heeft ook wel even geduurd en ik ben nu met PHP ook wel weer de andere kant tegen gekomen, met een prestashopje vast zitten omdat er geen upgrade path was met de php versies van Debian, omdat de handel ineens heel snel deprecated en vervolgens verwijderd werd, althans duidelijk sneller dan de Debian release cycle.

Maar goed gelukkig werken dan uiteindelijk al die oude hoog in zoekmachines scorende mysql examples met sql injectie mogelijkheid included ook niet meer

[ Voor 12% gewijzigd door gekkie op 16-12-2021 12:29 ]

[RagingPenguin]

mcDavid schreef op donderdag 16 december 2021 @ 11:09:
Wat dat betreft een sterk contrast met PHP wat bijvoorbeeld de `mysql` api gewoon verwijderd heeft toen er iets beters voor in de plaats gekomen was.

Maar dat is toch een extensie die gewoon weer kan instaleren? Mysql (zonder i) word nog steeds genoeg gebruikt door bv. wordpress.

[mcDavid]

RagingPenguin schreef op donderdag 16 december 2021 @ 12:35:
[...]


Maar dat is toch een extensie die gewoon weer kan instaleren? Mysql (zonder i) word nog steeds genoeg gebruikt door bv. wordpress.

Neuh, die extension is vanaf de 7.0 branch al niet meer beschikbaar. Ook niet voor wordpress.

[Koenvh]

RagingPenguin schreef op donderdag 16 december 2021 @ 12:35:
[...]


Maar dat is toch een extensie die gewoon weer kan instaleren? Mysql (zonder i) word nog steeds genoeg gebruikt door bv. wordpress.

Nee, maar er zijn wel shims beschikbaar online om het toch werkend te krijgen.
(Kwam ik achter toen ik bepaalde dingen stuk maakte bij een ongeplande upgrade van PHP 5.6 naar PHP 7.0)

[RagingPenguin]

mcDavid schreef op donderdag 16 december 2021 @ 13:43:
[...]


Neuh, die extension is vanaf de 7.0 branch al niet meer beschikbaar. Ook niet voor wordpress.

Ah, dan zijn we toch iets verder dan ik dacht

[Koenvh]

RagingPenguin schreef op donderdag 16 december 2021 @ 16:24:
[...]


Ah, dan zijn we toch iets verder dan ik dacht

Volgens mij is het beveiligingsverschil tussen mysqli_ en mysql_ niet zo groot, of mis ik iets? Het grootste verschil is voor mijn gevoel of de connectie globaal is of dat je 'm steeds in de functie moet meegeven.

[hackerhater]

Koenvh schreef op donderdag 16 december 2021 @ 19:57:
[...]

Volgens mij is het beveiligingsverschil tussen mysqli_ en mysql_ niet zo groot, of mis ik iets? Het grootste verschil is voor mijn gevoel of de connectie globaal is of dat je 'm steeds in de functie moet meegeven.

Vooral het verschil tussen de nieuwe library en de oude, outdated library

[RagingPenguin]

Koenvh schreef op donderdag 16 december 2021 @ 19:57:
[...]

Volgens mij is het beveiligingsverschil tussen mysqli_ en mysql_ niet zo groot, of mis ik iets? Het grootste verschil is voor mijn gevoel of de connectie globaal is of dat je 'm steeds in de functie moet meegeven.

Mysql heeft geen prepared statements, mysqli wel. Dat is de enige aceptable manier om sql-injecties tegen te gaan, geklooi met het escapen van user input terwijl je strings aan elkaar plakt heeft een te grote kans om fout te gaan. Daarnaast ondersteund mysql i.t.t mysqli ook geen connecties over SSL. Dat zou genoeg redenen moeten zijn om mysql nooit te willen gebruiken.

[mcDavid]

ik haalde het vooral op als voorbeeld dat PHP echt niet bang is backward compatibility te breken, zoals @gekkie impliceerde. Ik had ook register_globals of zo kunnen noemen. Maar er zijn ook genoeg moderne voorbeelden

[Koenvh]

RagingPenguin schreef op donderdag 16 december 2021 @ 20:20:
[...]


Mysql heeft geen prepared statements, mysqli wel. Dat is de enige aceptable manier om sql-injecties tegen te gaan, geklooi met het escapen van user input terwijl je strings aan elkaar plakt heeft een te grote kans om fout te gaan. Daarnaast ondersteund mysql i.t.t mysqli ook geen connecties over SSL. Dat zou genoeg redenen moeten zijn om mysql nooit te willen gebruiken.

Aha, het oude project had geen user input, en de server draaide op localhost, dus daar ben ik nooit achter gekomen (zelf verder nooit met mysql_ gewerkt).

[gekkie]

mcDavid schreef op donderdag 16 december 2021 @ 20:25:
ik haalde het vooral op als voorbeeld dat PHP echt niet bang is backward compatibility te breken, zoals @gekkie impliceerde. Ik had ook register_globals of zo kunnen noemen. Maar er zijn ook genoeg moderne voorbeelden

Nouja voor 7.x gebeurde dat niet of zelden, ze zijn nu in de versnelling gegaan om het wel te doen, soms nog wel eens iets te vlot althans voor mij als eindgebruiker bij de combinatie met distropackages van stable distro's

[SPee]

ThomasG schreef op donderdag 16 december 2021 @ 10:44:
[...]
Nee, om dezelfde reden dat ze ontwerpfouten nooit hebben rechtgetrokken: backwards compatibility. Je kunt een programma gemaakt voor JDK 1.5 draaien op bijvoorbeeld JDK 17. Als ze het verwijderen kan dat niet meer.

Toch gaan ze dat in nieuwere java versies wel doen.
Deprecated maken in een versie en in de volgende versie aangeven dat deze kandidaat voor removal is. Dan kan die mogelijk veilig worden verwijderd na een paar versies.

Java:

@Deprecated(since = "4.5", forRemoval = true)

Zoiets had ik jaren geleden al voorgesteld.

[whoami]

Mugwump schreef op dinsdag 14 december 2021 @ 18:34:
Ondanks dat het sarcastisch is leg ik soms wel degelijk dat soort regeltjes op. Als er bijvoorbeeld duidelijk afspraken zijn over wat je controleert bij een MR, maar je hebt er een paar bij die twee seconden kijken en goedkeuring geven zonder dat er enig benul is van wat de MR beoogt en of het dat ook doet, dan voer ik gewoon heel kinderachtig administratieve processen in de vorm van checklistjes in of iets dergelijks.

Dit zie ik ook veel te veel.
Een pull-request met wijzigingen in 20 files ofzo, en dan binnen 2 minuten 'approved'.

Wat houden die 'administratieve processen' precies in ? Ik maak soms PR-templates, maar dat is dan vooral voor diegen die de pull-request maakt. (Unit tests gemaakt ? Documentatie aangepast ? etc... ).

[Antrax]

Antrax heeft best wel een slechte week

[Mugwump]

whoami schreef op donderdag 16 december 2021 @ 23:57:
[...]

Dit zie ik ook veel te veel.
Een pull-request met wijzigingen in 20 files ofzo, en dan binnen 2 minuten 'approved'.

Wat houden die 'administratieve processen' precies in ? Ik maak soms PR-templates, maar dat is dan vooral voor diegen die de pull-request maakt. (Unit tests gemaakt ? Documentatie aangepast ? etc... ).

Ik maak inderdaad gewoon een lijstje van dingen die gecheckt moeten worden en dan in bepaalde vorm verplichten dat de reviewer een afgevinkt lijstje oplevert, evt met bevindingen als ze echt hardnekkig zijn.
Stap 1 is altijd de vraag 'doet deze change wat de functionele beschrijving (in de vorm van een US, defect of gewoon een ouderwetse RFC oid) zegt dat het zou moeten doen? Lijkt een no-brainer, maar kennelijk is dat het voor een significant deel van de developers niet. Unit tests worden altijd wel afgedwongen door code coverage in de basis, maar code coverage is natuurlijk ook maar een metric die lang niet altijd inhoudt dat je ook zinvolle tests schrijft, dus ook daarvoor geldt dat je criteria op kunt stellen voor het evalueren van tests die je weer in lijstjes kunt zetten.

Overigens geldt hetzelfde voor het klaarzetten van een MR. Ik ken ook nog wel wat developers die vooral codekloppen en het denkwerk uitbesteden aan derden. Hup de code staat, m'n eigen unit testjes, geen idee of ik nou eigenlijk gebouwd heb wat er in de US staat of dat er 33 warnings in m'n build pipeline voorbij komen en ga zo maar door. Dus ook daar maar checklistjes voor maken voordat iemand een MR mag klaarzetten.

Dat soort checklistjes kun je vaak wel inrichten en af laten dwingen in de tooling die je gebruikt voor reviews of anders in de tooling die je gebruikt voor het vastleggen van user stories of defects of wat je ook gebruikt om requirements en functionele beschrijvingen op te stellen.

[RobertMe]

Mugwump schreef op vrijdag 17 december 2021 @ 10:21:
Unit tests worden altijd wel afgedwongen door code coverage in de basis, maar code coverage is natuurlijk ook maar een metric die lang niet altijd inhoudt dat je ook zinvolle tests schrijft, dus ook daarvoor geldt dat je criteria op kunt stellen voor het evalueren van tests die je weer in lijstjes kunt zetten.

Controleren of unit tests correct / zinvol zijn kan ook weer gedeeltelijk automatisch. Dit middels mutation testing waarbij "bugs in de code worden toegepast" (bv > aanpassen naar >=. Of hardcoded numbers aanpassen naar een +1 en -1 variant) en dan zou dus op zijn minst een unit test moeten falen. Faalt geen enkele test dan zijn de tests dus ook niet goed. Bijvoorbeeld dat niet goed op een edge wordt getest bij een > vs >=. Of als je langere/complexere condities hebt met && en/of || dat blijkt dat een bepaald deel van de conditie nooit getest wordt. (Bv foo || bar, en dat het aanpassen naar foo || !bar geen falende test oplevert, dus alleen foo wordt getest maar niet bar).

[Caelorum]

En een deel van die "test bugs" kan je weer ondervangen met property based (/random) testing a la QuickCheck en afgeleiden

[Mugwump]

RobertMe schreef op vrijdag 17 december 2021 @ 10:31:
[...]

Controleren of unit tests correct / zinvol zijn kan ook weer gedeeltelijk automatisch. Dit middels mutation testing waarbij "bugs in de code worden toegepast" (bv > aanpassen naar >=. Of hardcoded numbers aanpassen naar een +1 en -1 variant) en dan zou dus op zijn minst een unit test moeten falen. Faalt geen enkele test dan zijn de tests dus ook niet goed. Bijvoorbeeld dat niet goed op een edge wordt getest bij een > vs >=. Of als je langere/complexere condities hebt met && en/of || dat blijkt dat een bepaald deel van de conditie nooit getest wordt. (Bv foo || bar, en dat het aanpassen naar foo || !bar geen falende test oplevert, dus alleen foo wordt getest maar niet bar).

Klopt, ik ben bekend met mutation testing.
Heb er wel eens naar gekeken, maar vond het toch de moeite niet om het toe te passen voor de zaken die ik toen deed.
Maar bovendien is het ook wat breder dan dat. Vertonen je unit tests bijvoorbeeld grote overlap? Maak je methodes toch maar package private (of een variant daarvan in een andere taal) puur om ze te kunnen testen? Is wat je test ook functioneel zinvol?

[Hydra]

Mutation testing is een mooie tool om je 'tester' weg te automatiseren. Je hebt niet iemand nodig die 'rare' dingen doet als je software zelf rare shit probeert

[Koenvh]

Zijn hier nog vakantieknutselprojectplannen? Ik wil eens kijken welke data ik allemaal uit de slimme meter kan uitlezen.

[gekkie]

Bij mijn ouders de raspberry pi met kodi vervangen en qua software upgraden, waaronder andere ook het uitlezen van de slimme meter een onderdeel zou kunnen zijn (maar het minst belangrijke), op zich is daar al een dongle voor die aan het bedraade netwerk hangt. Moet dus vooral nog een timeseries DB op de rpi komen en een script wat het er in frunnikt en iets van HA / Grafana wat het weer kan plotten.

[Ghehe]

Antrax schreef op vrijdag 17 december 2021 @ 10:14:
Antrax heeft best wel een slechte week

[Afbeelding]

https://issues.apache.org/jira/browse/LOG4J2-3230 Hoppa, we mogen de dans nog eens doen naar 2.17 binnenkort want 2.16 en eerder doet een infinite recursion op bepaalde input

[Mugwump]

Ghehe schreef op vrijdag 17 december 2021 @ 19:33:
[...]


https://issues.apache.org/jira/browse/LOG4J2-3230 Hoppa, we mogen de dans nog eens doen naar 2.17 binnenkort want 2.16 en eerder doet een infinite recursion op bepaalde input

Ziet eruit als een mogelijkheid tot DoS?

[.oisyn]

[gekkie]

Mjah als dan een opensource iets met wat achterstalligonderhoud ineens in de spotlights komt te staan, kan er wel eens voor een tijdje geen houden meer aan zijn , dan kloppen die "meerdere ogen" ineens erg goed.
Achja goede test voor de dev-ops en deploy kant van zaken

[ Voor 9% gewijzigd door gekkie op 17-12-2021 20:00 ]

[Creepy]

.oisyn schreef op vrijdag 17 december 2021 @ 19:58:
[Afbeelding]

Ik vind dit om de 1 of andere reden veel te leuk

[Firesphere]

Ghehe schreef op vrijdag 17 december 2021 @ 19:33:
[...]


https://issues.apache.org/jira/browse/LOG4J2-3230 Hoppa, we mogen de dans nog eens doen naar 2.17 binnenkort want 2.16 en eerder doet een infinite recursion op bepaalde input

I dub thee
Log4Log4Log4Log4Log4Log4Log4Log4Log

Het thema deze week:
[YouTube: The Log Song | The Ren & Stimpy Show | NickRewind]

[Lethalis]

Ik heb een mechanisch toetsenbord besteld (Leopold FC750RS, Silent Red switches).

Gewoon om eens uit te proberen waar de hype "als developer moet je een mechanisch toetsenbord hebben" over gaat

En mij lijkt de TKL (geen numpad) layout wel handig. Ik gebruik die toch niet en door de extra ruimte kan ik het allemaal (toetsenbord en muis) wat rechter voor mij / het beeldscherm plaatsen

Tot nu toe was ik altijd redelijk tevreden met een simpel Logitech toetsenbord. Wel met hoge toetsen en genoeg travel.

Misschien slaat het nergens op. De filmpjes op YouTube zijn wel hilarisch. Allemaal mensen die zichzelf filmen terwijl ze iets typen en dan de reacties eronder over het geluid etc Het lijkt wel een parallel toetsenbord fetish universum

[Lethalis]

Koenvh schreef op vrijdag 17 december 2021 @ 18:23:
Zijn hier nog vakantieknutselprojectplannen? Ik wil eens kijken welke data ik allemaal uit de slimme meter kan uitlezen.

Die komen bij mij niet echt van de grond. Maar ik heb een beginnetje met home automation gedaan een tijdje terug. Home Assistant, zigbee2mqtt, Conbee 2, diverse sensoren van Xaiomi, Tradfri stopcontacten etc.

Wil dat nog steeds voor de feestdagen wat meer uitbreiden. Onder andere om het huis er bewoond uit te laten zien als we er niet zijn.

En te kunnen monitoren... aan de andere kant word ik daar wellicht paranoïde van, dus weet niet of ik dat wel moet willen.

Collega van mij heeft zijn eigen domotica systeem gebouwd ooit, maar die is ook al een keer voor niks naar huis gereden vanuit kantoor omdat zijn bewegingssensoren afgingen.

Blijft een beetje een "wil ik dit wel" project.

[gekkie]

Silent, tss beetje de triangel of picolo speler van het orkest.

[Lethalis]

gekkie schreef op zaterdag 18 december 2021 @ 22:34:
Silent, tss beetje de triangel of picolo speler van het orkest.

Ik heb graag hetzelfde toetsenbord thuis als op de zaak. Dus als ik het thuis helemaal gaaf zou vinden dan bestel ik er nog een voor op kantoor.

Collega heeft al aangegeven dat hij gek ervan zou worden als het teveel herrie maakt

Vandaar de silent

[gekkie]

Lethalis schreef op zaterdag 18 december 2021 @ 22:32:
Collega van mij heeft zijn eigen domotica systeem gebouwd ooit, maar die is ook al een keer voor niks naar huis gereden vanuit kantoor omdat zijn bewegingssensoren afgingen.

Blijft een beetje een "wil ik dit wel" project.

(oude) lamp die automagisch ingeschakeld werd en toevallig eens warm genoeg werd om de pir te triggeren ?
Of de poes thuis gelaten

[ Voor 3% gewijzigd door gekkie op 18-12-2021 22:38 ]

[CurlyMo]

Koenvh schreef op vrijdag 17 december 2021 @ 18:23:
Zijn hier nog vakantieknutselprojectplannen? Ik wil eens kijken welke data ik allemaal uit de slimme meter kan uitlezen.

Al een tijdje bezig met een collega tweaker om mijn ESP8266 rules library te implementeren in een controller bordje voor Panasonic Warmtepompen. Daarmee kan een eigen regeling van de warmtepomp direct vanuit dat controller bordje gedan worden waardoor je geen externe domotica meer nodig hebt.

[Ryur]

Lethalis schreef op zaterdag 18 december 2021 @ 22:36:
[...]
Collega heeft al aangegeven dat hij gek ervan zou worden als het teveel herrie maakt

Vandaar de silent

Oplossing: gebruik de Silent toetsenbord om je collega hard te meppen. Kies daarna eentje met Blue's

Hier hetzelfde probleem, mijn collega's werden ook gek van mijn toetsenbord (toen had ik nog Browns). Nu met het thuiswerken dus lekker blue's, en ALS ik ooit weer naar kantoor moet zie ik het wel

[F.West98]

Ik zit me nu een beetje verder te verdiepen in SPA frameworks en alles, en ik snap echt voor geen meter waarom dit nou "the next best thing" is. Natuurlijk is het leuk om een pagina wat interactief te maken en sure voor de codekloppers wel zo eenvoudig om alleen een API te maken die consumed wordt in zowel een app als een website enzo, maar verder...

Je hebt verder gewoon ineens een vrij onhandige extra laag/hurdle in je flow tussen DB en DOM: je web request. Gevolg: je moet je (api/view)models op meerdere plekken definiëren en bijhouden. Je moet je validatielogica op meerdere plekken definiëren en bijhouden. Error handling kost nog meer moeite.

En dan de kers op de taart: de SEO werkt niet goed (want een crawler gaat niet goed om met SPA), dus de oplossing is: je SPA server-side pre-renderen! En dan wordt er gedaan alsof server-side rendering super hot en nieuw is... Het enige gevolg is dat je nu ook in je backend ineens dezelfde JS codebase moet gaan gebruiken, en ineens Node moet gaan draaien, en je huidige backend framework moet laten praten met die Node instance ofzo.. Sorry maar ik kan hier met mn verstand niet bij. Waar zijn we nou mee bezig?

Kan iemand me uitleggen wat er nou beter is aan een hele Node + React + Webpack + minifyers + weetikwat + backend + API stack dan gewoon lekker klassiek alles server-side renderen met wat kekke dynamische componentjes in web components ofzo?

[ElkeBxl]

F.West98 schreef op zaterdag 18 december 2021 @ 23:22:
Kan iemand me uitleggen wat er nou beter is aan een hele Node + React + Webpack + minifyers + weetikwat + backend + API stack dan gewoon lekker klassiek alles server-side renderen met wat kekke dynamische componentjes in web components ofzo?

Het hangt veel af van je applicatie. Heb je veel statische content zoals tweakers.net waar het dynamische (bv. filtering) enkel in iets zoals de pricewatch zit, dan kom je nog steeds goed weg met een serverside setup en hoef je niet bezig te zijn met een SPA. Voeg dan gerust wat simpele AJAX toe. Heck, pak er nog eens jQuery bij for all I care.

Als frontend developer die enkel met SPAs werkt schiet ik wat in mijn eigen kraam maar: SPAs zijn NIET the holy grail die velen denken. Maar zit je met veel dynamische stuff zoals in een webshop waar men constant filtert, zoekt, een chat wil hebben, ... dan is een SPA al veel interessanter. Elk heeft z'n toepassingsdomein.

F.West98 schreef op zaterdag 18 december 2021 @ 23:22:
Je hebt verder gewoon ineens een vrij onhandige extra laag/hurdle in je flow tussen DB en DOM: je web request. Gevolg: je moet je (api/view)models op meerdere plekken definiëren en bijhouden. Je moet je validatielogica op meerdere plekken definiëren en bijhouden. Error handling kost nog meer moeite.

Models op meerdere plekken: valt me nog goed mee. Toen ik ooit nog fullstack .NET MVC deed, hadden ze op het werk de gewoonte om naast Models ook ViewModels te hebben en zaten we ook met een hoop duplicatie. Nu heb ik mijn eigen models in TypeScript waarmee ik eigenlijk definieer hoe een server response er minstens moet uitzien omdat het geen 1-op-1 match hoeft te zijn. Heb ik enkel A en B van model X nodig maar stuurt backend ook nog C en D door in dezelfde request? Fine, dan heeft mijn model enkel A en B. Voeg daar nog eens iets als een graphql aan toe en het wordt al helemaal interessant, maar ook dat is optioneel. Ik heb het nog niet in een professionele context nodig gehad.

Validatielogica op meerdere plekken: is het niet sowieso best-practice om al iets van frontend validatie te hebben om de eerste dingen zoals required form field errors te hebben? Ik verwacht dat backend echt alle validatielogica doet en de frontend validatie is er om heel snelle feedback naar de user te hebben die er ook voor zorgt dat er minder slechte requests naar backend hoeven te gebeuren. Backend validatie is nodig, frontend validatie is er voor de user experience en optioneel.

F.West98 schreef op zaterdag 18 december 2021 @ 23:22:
En dan de kers op de taart: de SEO werkt niet goed (want een crawler gaat niet goed om met SPA), dus de oplossing is: je SPA server-side pre-renderen! En dan wordt er gedaan alsof server-side rendering super hot en nieuw is... Het enige gevolg is dat je nu ook in je backend ineens dezelfde JS codebase moet gaan gebruiken, en ineens Node moet gaan draaien, en je huidige backend framework moet laten praten met die Node instance ofzo.. Sorry maar ik kan hier met mn verstand niet bij. Waar zijn we nou mee bezig?

Ik werk nu op een grote commerciële website die als SPA geschreven is en wij hebben geen problemen met de SEO. Prerendering is iets wat we bekeken hebben maar uiteindelijk niet nodig hadden. Dat was in de tijd dat de code echt nog niet snel was en de website 20+ seconden nodig had op initial load. Daar wordt elke website op afgestraft in SEO, of dat nu SPA of non-SPA is. We hebben nu een sitemap (wat sowieso al good practice is, zelfs in een non-SPA setting).

Zelfs vor de intro van een sitemap scoorde de site al goed op vlak van SEO eens we hoop optimalisaties hadden gedaan die logisch en ook standaard zouden moeten zijn: we gebruikten 2 libraries voor time stuff dus beetje herschreven naar enkel momentjs, we hadden meerdere externe components voor sliders dus ook naar 1 overgeschakeld, meerdere calendar components die echt slecht geschreven waren, geen treeshaking geconfigureerd (momentjs, lodash en consorten werden volledig ingeladen,...), de store was onnodig bulky, requests naar de backend waren niet altijd asynchroon (1 van de vorige developers had async/await ontdekt. en wist niet wat die deed..), er was nog geen gzip geactiveerd, lazy loading van paginas en componenten werd niet gebruikt ... Eens we al die zaken toepasten (wat me niet eens zo lang geduurd heeft) ging de website van 20+ seconden naar < 2 seconden loadtime en was de SEO score al pak hoger. Een SPA hoeft niet traag te zijn en er bestaat genoeg documentatie hoe je vanaf het begin je SPA efficient kan schrijven.

Crawlers executen de JS zonder al teveel problemen. Als je natuurlijk paginas hebt die pokketraag zijn omdat je niks van optimalisaties doet en 50MB aan JS moet inladen op initial load, dan kan je SEO daar natuurlijk al eens onder lijden. Maar dan gaan je bezoekers sowieso al niet lang blijven op een publieke website, zeker als ze eens een wat tragere internetverbinding hebben. Dan heb je andere problemen qua user experience....

SSR is leuk maar de enige keren dat ik het gebruik is in bv. blogs die ik in Gatsby, Gridsome en dergelijke schrijf. En daar is het dan eerder SSG. Platformen zoals Netlify maken die ervaring zo silky smooth.... Maar dat is dan in contexten waar ik geen backend nodig heb en al mijn content in .md files of .json files kan zitten. Alles hangt van het doel af. Voeg daar nog iets als een Netlify CMS aan toe en de nood om zelf een adminpaneeltje te schrijven en een backend te bouwen om alle content te beheren is helemaal weg. SSR zou ik enkel overwegen te doen als ik ook een backend moet schrijven waar ik dan toch al naar een Node backend zou kijken.

F.West98 schreef op zaterdag 18 december 2021 @ 23:22:
Kan iemand me uitleggen wat er nou beter is aan een hele Node + React + Webpack + minifyers + weetikwat + backend + API stack dan gewoon lekker klassiek alles server-side renderen met wat kekke dynamische componentjes in web components ofzo?

So basically hangt het af van je toepassing. De stack die je opnoemt is niet the holy grail. Sommigen doen alsof het wel the next best thing is omdat iets nieuws altijd meer hip en cool aanvoelt. En zijn we als ITers sowieso niet geneigd om vaak te zoeken naar het betere en naar excuses om de boel te herschrijven? De grootste roepers dat zo'n dev stack het beste ter wereld is, zijn vaak zij met ofwel een eigen agenda (want ze hebben een blog, hebben een boek geschreven, zijn "advocate" voor die tech, ...) ofwel omdat ze oogkleppen zoals een paard ophebben en enkel maar de kudde kunnen volgen.

[ElkeBxl]

Lethalis schreef op zaterdag 18 december 2021 @ 22:21:
Misschien slaat het nergens op. De filmpjes op YouTube zijn wel hilarisch. Allemaal mensen die zichzelf filmen terwijl ze iets typen en dan de reacties eronder over het geluid etc Het lijkt wel een parallel toetsenbord fetish universum

Have you heard about our lord and savior Glarses?

[gekkie]

Buiten shops zullen een hoop SPA's sowieso wel een "echte" applicatie zijn, waar weinig aan te SEO'en is en die bovendien achter een login zit.

[Caelorum]

Tja dat hele SPA verhaal overweeg ik ook alleen als zowel e frontend als backend talen dezelfde zijn. Dan kan je eenvoudig functies en models hergebruiken aan beide kanten. Pak je dan iets als https://fable.io/ dan wordt het wel heel fijn.

[gekkie]

Maarja dan zit je al gauw aan backend javascript, bweh.
Of wellicht dat rust en webasm nog wat zou kunnen worden.

Maar goed eigenlijk is een webbrowser ook maar verworden tot een vrij matige grafische toolkit, het is dat we daar de software distributie mee "oplossen", door je tijdelijk allerlei applicaties te laten draaien op je eigen machine.

[WernerL]

Ook voor websites hebben SPAs voordelen. Veel CMS systemen zijn enorm opinionated waardoor het best een pain in the ass kan zijn om er mee te werken. Door de frontend los te trekken van het CMS heb je meer vrijheid voor het schrijven en structuren van je frontend code.

Verder heb ik zelf goede ervaringen met odata. Met ASP.NET en entity framework kun je vrij eenvoudig je data beschikbaar stellen via odata-endpoints waardoor je in de frontend je queries kunt schrijven en niet meer voor ieder ding een custom-endpoint hoeft te bouwen. Heb je ook niet het probleem dat je aan 2 kanten viewModels moet definieren. En anders zijn er ook tools waarmee je typescript-definities kunt genereren van je backend-models. TypeGen bijvoorbeeld.

[whoami]

WernerL schreef op zondag 19 december 2021 @ 12:18:
Verder heb ik zelf goede ervaringen met odata. Met ASP.NET en entity framework kun je vrij eenvoudig je data beschikbaar stellen via odata-endpoints waardoor je in de frontend je queries kunt schrijven en niet meer voor ieder ding een custom-endpoint hoeft te bouwen. Heb je ook niet het probleem dat je aan 2 kanten viewModels moet definieren. En anders zijn er ook tools waarmee je typescript-definities kunt genereren van je backend-models. TypeGen bijvoorbeeld.

Dat is misschien makkelijk, maar ook een pain in the ass. Je data-model is dan zo hard gekoppeld met je API model dat backend wijzigingen niet zomaar mogelijk meer zijn. Je impacteert meteen alle clients + die clients moeten dan ook jouw datamodel kennen.

[Mugwump]

Ik vind OData echt de meest waardeloze API-spec die er ooit bedacht is, al komt SOAP aardig in de buurt.
Nou houdt mijn werk tegenwoordig ook op bij de API laag en bouw ik dus geen systemen waarbij je een tightly coupled data store en front end heb, maar breed inzetbare APIs die door meerdere afnemers geconsumeerd worden.
GraphQL is nog wel interessant. Wij lopen nogal eens aan tegen APIs die een vrij brede set aan data leveren, waarbij veel afnemers dan weer specifiek geïnteresseerd zijn in een bepaald onderdeel, dat kan met GraphQL weer veel efficiënter aangezien de afnemer simpelweg kan aangeven welke data die wil ontvangen.

[gekkie]

Graphql is wel handig om websites te scrapen inderdaad.
Fijn json terug en je kunt vaak wat beter om de hele pagination shizzle heen

[WernerL]

whoami schreef op zondag 19 december 2021 @ 13:04:
[...]

Dat is misschien makkelijk, maar ook een pain in the ass. Je data-model is dan zo hard gekoppeld met je API model dat backend wijzigingen niet zomaar mogelijk meer zijn. Je impacteert meteen alle clients + die clients moeten dan ook jouw datamodel kennen.

In het geval de backend slechts één client hoeft te bedienen is de backend sowieso al heel erg gefocussed op te functionaliteit van de desbetreffende applicatie. Een backend wijziging zal dan in veel gevallen samengaan met een frontend wijziging dus ik vind dat niet een issue.

Enkel wanneer je stand-alone APIs ontwikkeld die door meerdere producten gebruikt moet worden kan ik me voorstellen dat je iets anders nadenkt over je API-ontwerp.

Mugwump schreef op zondag 19 december 2021 @ 13:14:
Ik vind OData echt de meest waardeloze API-spec die er ooit bedacht is, al komt SOAP aardig in de buurt.
Nou houdt mijn werk tegenwoordig ook op bij de API laag en bouw ik dus geen systemen waarbij je een tightly coupled data store en front end heb, maar breed inzetbare APIs die door meerdere afnemers geconsumeerd worden.
GraphQL is nog wel interessant. Wij lopen nogal eens aan tegen APIs die een vrij brede set aan data leveren, waarbij veel afnemers dan weer specifiek geïnteresseerd zijn in een bepaald onderdeel, dat kan met GraphQL weer veel efficiënter aangezien de afnemer simpelweg kan aangeven welke data die wil ontvangen.

Met OData heb je ook de mogelijkheid om aan te geven welke data je wilt hebben. Ook data van relaties kun je selecteren via een expand. Nadeel van GraphQL vind ik dat je zelf keuzes moet maken over hoe je sortering, paginering en filtering oplost. Iets wat gewoon onderdeel is van de OData-spec waardoor je als developer alleen moet weten hoe het data-model eruit ziet.

[RagingPenguin]

whoami schreef op zondag 19 december 2021 @ 13:04:
[...]

Dat is misschien makkelijk, maar ook een pain in the ass. Je data-model is dan zo hard gekoppeld met je API model dat backend wijzigingen niet zomaar mogelijk meer zijn. Je impacteert meteen alle clients + die clients moeten dan ook jouw datamodel kennen.

Het idee van odata is een beetje dat je (custom) backend code ook maar client is die te leven heeft met het data model van de OData server. Al werk je met OData dan moet je het klasieke concept van de monolitische backend die alle data beheerd en abstraheert los laten en ipv redeneren in clients die taken uitvoeren (wat zowel frontend als backend kan zijn, dat verschil is dan niet meer zo relevant). Daarnaast heeft OData ook gewoon API versies, al wil je een model in de api aanpassen dan kan je dat in een nieuwe versie doen.

[Mugwump]

WernerL schreef op zondag 19 december 2021 @ 13:22:
[...]


In het geval de backend slechts één client hoeft te bedienen is de backend sowieso al heel erg gefocussed op te functionaliteit van de desbetreffende applicatie. Een backend wijziging zal dan in veel gevallen samengaan met een frontend wijziging dus ik vind dat niet een issue.

Enkel wanneer je stand-alone APIs ontwikkeld die door meerdere producten gebruikt moet worden kan ik me voorstellen dat je iets anders nadenkt over je API-ontwerp.


[...]


Met OData heb je ook de mogelijkheid om aan te geven welke data je wilt hebben. Ook data van relaties kun je selecteren via een expand. Nadeel van GraphQL vind ik dat je zelf keuzes moet maken over hoe je sortering, paginering en filtering oplost. Iets wat gewoon onderdeel is van de OData-spec waardoor je als developer alleen moet weten hoe het data-model eruit ziet.

Toch komt OData bij mij heel erg over als geschikt voor "forms-over-data" CRUD toepassingen. Dat is niet het soort werk dat ik doe, dus wellicht komt mijn aversie daar vandaan.
Ik heb mijn data grotendeels niet in relationele databases staan en dus ook geen behoefte aan dat soort functionaliteit op API niveau.
GraphQL is in mijn ogen toch meer een middle layer tussen front-ends / externe systemen en REST APIs.
Zo heb ik nu bijvoorbeeld een discussie met een front-end team dat data uit twee losstaande domeinen graag in één API wil hebben in plaats van dat ze meerdere losse calls moeten doen. Aan de back-end kant zijn dat zaken die je gewoon gescheiden wilt houden, dus dan is GraphQL wel een mooie oplossing.

[F.West98]

ElkeBxl schreef op zondag 19 december 2021 @ 09:48:

Models op meerdere plekken: valt me nog goed mee. Toen ik ooit nog fullstack .NET MVC deed, hadden ze op het werk de gewoonte om naast Models ook ViewModels te hebben en zaten we ook met een hoop duplicatie. Nu heb ik mijn eigen models in TypeScript waarmee ik eigenlijk definieer hoe een server response er minstens moet uitzien omdat het geen 1-op-1 match hoeft te zijn. Heb ik enkel A en B van model X nodig maar stuurt backend ook nog C en D door in dezelfde request? Fine, dan heeft mijn model enkel A en B. Voeg daar nog eens iets als een graphql aan toe en het wordt al helemaal interessant, maar ook dat is optioneel. Ik heb het nog niet in een professionele context nodig gehad.

Het is iets dat mij iig opvalt. Bij een traditionele .NET MVC app heb je meestal een Model en een soort ViewModel, waarna je die laatste direct in je View verwerkt en klaar. Nu heb je ipv een ViewModel meer een soort ApiModel, en moet je die in je frontend weer opnieuw definiëren, samen met veel logica om met je API te communiceren. Dat voelt soms vrij omslachtig - maar goede tooling kan dat inderdaad vereenvoudigen (maar dan heb je nóg meer packages nodig).

Validatielogica op meerdere plekken: is het niet sowieso best-practice om al iets van frontend validatie te hebben om de eerste dingen zoals required form field errors te hebben? Ik verwacht dat backend echt alle validatielogica doet en de frontend validatie is er om heel snelle feedback naar de user te hebben die er ook voor zorgt dat er minder slechte requests naar backend hoeven te gebeuren. Backend validatie is nodig, frontend validatie is er voor de user experience en optioneel.

Dat is zeker best practice. Alleen is voor mij het "bekende" alternatief .NET server-side rendering die automagisch op basis van één ViewModel zowel back-end als front-end validation doet Volgens mij kunnen meerdere engines dat wel. In dat opzicht is het dus een extra duplicatie in je code.

Ik werk nu op een grote commerciële website die als SPA geschreven is en wij hebben geen problemen met de SEO. Prerendering is iets wat we bekeken hebben maar uiteindelijk niet nodig hadden. Dat was in de tijd dat de code echt nog niet snel was en de website 20+ seconden nodig had op initial load. Daar wordt elke website op afgestraft in SEO, of dat nu SPA of non-SPA is. We hebben nu een sitemap (wat sowieso al good practice is, zelfs in een non-SPA setting).

Goed, dat is mijn gebrek aan kennis. Ik las vooral dat SSR toch echt nodig was om je SEO op orde te krijgen.

So basically hangt het af van je toepassing. De stack die je opnoemt is niet the holy grail. Sommigen doen alsof het wel the next best thing is omdat iets nieuws altijd meer hip en cool aanvoelt. En zijn we als ITers sowieso niet geneigd om vaak te zoeken naar het betere en naar excuses om de boel te herschrijven? De grootste roepers dat zo'n dev stack het beste ter wereld is, zijn vaak zij met ofwel een eigen agenda (want ze hebben een blog, hebben een boek geschreven, zijn "advocate" voor die tech, ...) ofwel omdat ze oogkleppen zoals een paard ophebben en enkel maar de kudde kunnen volgen.

Dat is inderdaad vooral wat mij stoort, hoe men online doet alsof SSR+SPA de beste uitvinding sinds gesneden brood is en alsof het allemaal geweldige magie is... terwijl ik hier dan zit te lezen van ja SSR dat doen ze al decennia.

Overigens moet ik de eerste écht responsive SPA nog tegenkomen, Tweakers/GoT is in mijn ervaring veel soepeler dan alle moderne meuk op Facebook, Twitter, Maps, GMail, Outlook, etc. Ook webshops die iets SPA-achtigs doen vind ik bijzonder irritant soms Hetzelfde geldt voor bijna alle electron-meuk die tegenwoordig op je PC moet draaien. De enige uitzondering tot nu toe is VS Code

Caelorum schreef op zondag 19 december 2021 @ 12:04:
Tja dat hele SPA verhaal overweeg ik ook alleen als zowel e frontend als backend talen dezelfde zijn. Dan kan je eenvoudig functies en models hergebruiken aan beide kanten. Pak je dan iets als https://fable.io/ dan wordt het wel heel fijn.

Dat is heel leuk, maar ik heb toch liever niet mijn backend "vervuild" met JavaScript en consorten

WernerL schreef op zondag 19 december 2021 @ 12:18:
Verder heb ik zelf goede ervaringen met odata. Met ASP.NET en entity framework kun je vrij eenvoudig je data beschikbaar stellen via odata-endpoints waardoor je in de frontend je queries kunt schrijven en niet meer voor ieder ding een custom-endpoint hoeft te bouwen. Heb je ook niet het probleem dat je aan 2 kanten viewModels moet definieren. En anders zijn er ook tools waarmee je typescript-definities kunt genereren van je backend-models. TypeGen bijvoorbeeld.

Ik heb me er niet enorm in verdiept, maar is het niet dat je dan volledig vastzit aan je DB model? Ik heb vaak genoeg dat ik in de codebase en al helemaal richting clients een ander datamodel wil presenteren: sommige relations niet meer genormaliseerd, of sommige velden weglaten, of bijvoorbeeld data aggregaten. Is dat ook te doen met OData? Ik ben het zelf nog niet tegengekomen maar zou het wel enorm handig vinden.

[Caelorum]

F.West98 schreef op zondag 19 december 2021 @ 14:57:
[...]
Dat is heel leuk, maar ik heb toch liever niet mijn backend "vervuild" met JavaScript en consorten
[...]

In het geval van fable is zowel frontend als backend f#, wat je met moeite onder javascript kan scharen lijkt me.

En zoiets kan vast ook wel met andere talen.

[Alex)]

Goedemiddag, hier ben ik al lang niet meer geweest! Tweakers is echt helemaal uit mijn systeem gevallen...

Koffie?

[whoami]

F.West98 schreef op zondag 19 december 2021 @ 14:57:
[...]

Ik heb me er niet enorm in verdiept, maar is het niet dat je dan volledig vastzit aan je DB model? Ik heb vaak genoeg dat ik in de codebase en al helemaal richting clients een ander datamodel wil presenteren: sommige relations niet meer genormaliseerd, of sommige velden weglaten, of bijvoorbeeld data aggregaten. Is dat ook te doen met OData? Ik ben het zelf nog niet tegengekomen maar zou het wel enorm handig vinden.

Dat is wat ik ook probeerde te verwoorden

[Lethalis]

Ryur schreef op zaterdag 18 december 2021 @ 22:45:
[...]

Oplossing: gebruik de Silent toetsenbord om je collega hard te meppen. Kies daarna eentje met Blue's

Hier hetzelfde probleem, mijn collega's werden ook gek van mijn toetsenbord (toen had ik nog Browns). Nu met het thuiswerken dus lekker blue's, en ALS ik ooit weer naar kantoor moet zie ik het wel

Als ik het goed begrijp heb je dan eigenlijk voor een zwaarder tikkend toetsenbord gekozen?

MX Red 45cN operating force
MX Brown 55cN operating force
MX Blue 60cN operating force

Ik heb ook deels voor de Red gekozen zodat het soepel zal zijn. Nu heb ik geen ervaring hiermee, dus kan zijn dat ik er straks spijt van krijg en toch iets anders wil... maar dat is een kwestie van uitproberen.

Wat maakt de MX Blue voor jou ideaal? Meeste feedback?

[gekkie]

Alex) schreef op zondag 19 december 2021 @ 16:27:
Goedemiddag, hier ben ik al lang niet meer geweest! Tweakers is echt helemaal uit mijn systeem gevallen...

Koffie?

[Afbeelding]

Doe morgen vroeg maar (of straks na het avondeten een bakkie).

[CodeCaster]

OData met Entity Framework is dom, net als API Platform in PHP. Je wil niet, nooit, never en te nimmer je API's rechtstreeks verbonden laten zijn aan jouw (on)vermogen om je achterliggende (relationele) database te normalizeren of juist relaties te leggen waar die er niet zijn (NoSQL-store).

Verplaats een kolom naar een andere tabel, voeg een koppeltabel toe omdat een foreign key niet meer genoeg is of de relatie is veranderd, sla data helemaal anders op: tough luck, dat kan niet zonder je API te breken. Natuurlijk zijn daar weer workarounds voor met providers, filters, mappers, give it a name, maar als je het vanaf het begin af aan goed had opgezet (lees: met een API die niet hard is gebonden aan je databasestructuur), had je dat probleem ook niet gehad. $include een paar gerelateerde entities omdat je van factuur->order->orderregel->product wat eigenschappen wil hebben, en plotseling is je respons 20 MB en duurt je query een halve minuut.

Of je hebt van die "puristen" die vinden dat dat alles REST moet zijn, en dat je API-calls allemaal over één entity moeten gaan, waarbij een entity dan liefst ook nog één-op-één mapt naar een databasetabel. Gevolg: je landingpage/dashboard moet twintig separate API-calls doen om het overzicht voor de gebruiker (je weet wel, de klant die je uiteindelijk bedient) samen te stellen, dit duurt 20 seconden, en dan gaat men workarounds met caching, skeleton screens, loading throbbers en weet ik veel wat introduceren.

Of je kijkt gewoon welke data je afnemers nodig hebben, en maakt hier een endpoint voor. MaAR daN KAn iK NIeT allES alS RESouRCE BehAndelEN. Nee, dat is het ook niet altijd.

Mensen die fitties gooien over SOAP kan ik ook niet serieus nemen; die hebben blijkbaar het tijdperk gemist waarin API-documentatie niet bestond en het gemiddelde dataverkeer nog niet over HTTPS liep. Met een gegenereerde WSDL weet je in ieder geval nog welke endpoints er op een API zitten en welke modellen die teruggeeft. Ja het is XML, en dat is wat meer verbose dan JSON. Als dat het enige is wat je kunt inbrengen...

[ Voor 17% gewijzigd door CodeCaster op 19-12-2021 17:00 ]

[gekkie]

Lethalis schreef op zondag 19 december 2021 @ 16:52:
[...]
Als ik het goed begrijp heb je dan eigenlijk voor een zwaarder tikkend toetsenbord gekozen?

In het kader van het sluiten van de sportscholen, krachttraining op maat

[Lethalis]

CodeCaster schreef op zondag 19 december 2021 @ 16:54:

Of je hebt van die "puristen" die vinden dat dat alles REST moet zijn, en dat je API-calls allemaal over één entity moeten gaan, waarbij een entity dan liefst ook nog één-op-één mapt naar een databasetabel. Gevolg: je landingpage/dashboard moet twintig separate API-calls doen om het overzicht voor de gebruiker (je weet wel, de klant die je uiteindelijk bedient) samen te stellen, dit duurt 20 seconden, en dan gaat men workarounds met caching, skeleton screens, loading throbbers en weet ik veel wat introduceren.

Ik dacht dat "purist" zijn op dit gebied betekende dat je resource een root entity is van een afgebakend domein en vooral géén armoedige 1 op 1 mapping naar een relationeel model is Dus bijvoorbeeld een Order met regels er op ipv een Orderregel.

Het REST purist zijn gaat meestal toch ook meer over de juiste HTTP verbs en response codes gebruiken en een goede hiërarchie in de urls aan te brengen?

Daarnaast zijn losse API calls vanuit een frontend meestal niet zo'n probleem omdat ze parallel kunnen worden uitgevoerd

[Alex)]

Lethalis schreef op zondag 19 december 2021 @ 17:09:
[...]
Daarnaast zijn losse API calls vanuit een frontend meestal niet zo'n probleem omdat ze parallel kunnen worden uitgevoerd

Maar de UX wordt er niet beter van.

[Lethalis]

Alex) schreef op zondag 19 december 2021 @ 17:11:
[...]

Maar de UX wordt er niet beter van.

It depends. As usual.

Ik heb o.a. een support site gemaakt die data ophaalt (over een klant) bij meerdere systemen. Als 1 systeem er uitligt, wordt de overige data uit de andere systemen iig nog getoond.

[Ryur]

Lethalis schreef op zondag 19 december 2021 @ 16:52:
[...]

Als ik het goed begrijp heb je dan eigenlijk voor een zwaarder tikkend toetsenbord gekozen?

MX Red 45cN operating force
MX Brown 55cN operating force
MX Blue 60cN operating force

Ik heb ook deels voor de Red gekozen zodat het soepel zal zijn. Nu heb ik geen ervaring hiermee, dus kan zijn dat ik er straks spijt van krijg en toch iets anders wil... maar dat is een kwestie van uitproberen.

Wat maakt de MX Blue voor jou ideaal? Meeste feedback?

Ik heb zelf nooit Red's geprobeerd trouwens, heb Browns & Blues altijd.

De reden eigenlijk waarom ik voor Blue's ben gegaan is dat ik bij Brown's veel merk dat ik zit te "bottomen" (oftewel de key eigenlijk tegen het toetsenbord zelf aanduwen).
Blijkbaar hou ik dus enorm van feedback, en ik merk ook dat ik juist voor Tactile (o.a. Blue's, maar ook Clears hebben dat ook) switches moet kiezen ipv van Linear.

Op mijn werk Mac heb ik Blue's.
Op mijn gaming PC heb ik wel browns (waar ik ook dit bericht mee tik trouwens).

Toevallig ben ik nu in de markt voor nieuw toetsenbord en denk dat ik dan eens de Clear's ga uitproberen

[ElkeBxl]

F.West98 schreef op zondag 19 december 2021 @ 14:57:
[...]

Het is iets dat mij iig opvalt. Bij een traditionele .NET MVC app heb je meestal een Model en een soort ViewModel, waarna je die laatste direct in je View verwerkt en klaar. Nu heb je ipv een ViewModel meer een soort ApiModel, en moet je die in je frontend weer opnieuw definiëren, samen met veel logica om met je API te communiceren. Dat voelt soms vrij omslachtig - maar goede tooling kan dat inderdaad vereenvoudigen (maar dan heb je nóg meer packages nodig).

Mijn models zijn zoveel mogelijk afgestemd op het formaat van de response die backend stuurt. En voor de uitzonderingen van velden (zoals het parsen van een datetime string in een Date obejct om nu simpel voorbeeld te nemen), kleine functie erover om dat te parsen en klaar. Eigenlijk werk ik dus meestal met een APImodel in mijn frontend. Hoe dat er op backend uitziet heb ik geen idee van. Maar die backend zit dan ook met de situatie dat dezelfde endpoints die ik aanroep, ook aangeroepen wordt door ander frontends. Om dan (voor zover ik heb gezien) soms maar 5 van de 100 object properties te gebruiken. Dan lijkt een model per frontend wel clean om mee te werken. Het is iets dat ik ook vaker van collegas hoor dat 1 backend meerdere frontends van data voorziet.

F.West98 schreef op zondag 19 december 2021 @ 14:57:
[...]
Dat is zeker best practice. Alleen is voor mij het "bekende" alternatief .NET server-side rendering die automagisch op basis van één ViewModel zowel back-end als front-end validation doet Volgens mij kunnen meerdere engines dat wel. In dat opzicht is het dus een extra duplicatie in je code.

Gewoon dezelfde validatie kunnen importeren zou wel iets cool kunnen zijn. Maar daar staat dan tegenover dat ik mijn JS niet wil vervuilen met backend code

F.West98 schreef op zondag 19 december 2021 @ 14:57:
[...]
Goed, dat is mijn gebrek aan kennis. Ik las vooral dat SSR toch echt nodig was om je SEO op orde te krijgen.

No worries, zo roepen het overal dus ik snap dat wel. En uiteindelijk ben ik ook maar 1 ervaring... Google zelf geeft wel wat info erover zoals in deze codelab: https://codelabs.develope...age-app-search-friendly#3 waar ze eigenlijk showcasen dat bv. je meta tags aanpassen in JS geen probleem lijkt te zijn. Meeste SPAs die ik heb gezien komen nooit aan de meta tags aan en passen de titel van de pagina niet aan. Tja, dan schiet je jezelf in je voet natuurlijk.

F.West98 schreef op zondag 19 december 2021 @ 14:57:
[...]
De enige uitzondering tot nu toe is VS Code

Ik wou dat meer Electron apps zo'n plezier waren om te runnen zoals VS Code. Wat zou mijn laptop zoveel minder zitten blazen...

WernerL schreef op zondag 19 december 2021 @ 12:18:
Ook voor websites hebben SPAs voordelen. Veel CMS systemen zijn enorm opinionated waardoor het best een pain in the ass kan zijn om er mee te werken. Door de frontend los te trekken van het CMS heb je meer vrijheid voor het schrijven en structuren van je frontend code.

Headless CMS for the win!

gekkie schreef op zondag 19 december 2021 @ 12:14:
Of wellicht dat rust en webasm nog wat zou kunnen worden.

Daar ben ik echt benieuwd naar wat de toekomst wordt van webassembly. Van wat ik hoor van klanten en collega's is er nog niet zoveel volk chaud en lijken ze het vooral te kennen van ports van games en andere "demo's" om te laten zien hoe snel het is. Zelf heb ik het nu nog niet nodig, daarvoor zijn mijn frontends te simpel en zit er weinig tot geen rekenkracht of zware grafische meuk in.

Ryur schreef op zondag 19 december 2021 @ 17:33:
[...]
De reden eigenlijk waarom ik voor Blue's ben gegaan is dat ik bij Brown's veel merk dat ik zit te "bottomen" (oftewel de key eigenlijk tegen het toetsenbord zelf aanduwen).

Ik heb zelf MX Brown's en het bottomen is iets wat ik ook ervaar. O-rings hielpen daar al wat in, maakte het voor de partner al wat aangenamer als ze ging slapen en ik nog zat te tokkelen in de kamer ernaast

[ Voor 6% gewijzigd door ElkeBxl op 19-12-2021 21:12 ]

[Ryur]

ElkeBxl schreef op zondag 19 december 2021 @ 21:11:
[...]
Ik heb zelf MX Brown's en het bottomen is iets wat ik ook ervaar. O-rings hielpen daar al wat in, maakte het voor de partner al wat aangenamer als ze ging slapen en ik nog zat te tokkelen in de kamer ernaast

Ik heb ook gehoord dat O-rings willen helpen ja. Of ze extra te 'luben', maar zo ver wil ik niet echt gaan
In die tijd kon ik Blue's van een collega even proberen en ik was om (+ ik moest ook een nieuw toetsenbord voor mijn werklaptop).
Zou graag nog zo'n "Switch-tester" willen, alleen veel hebben maar een paar switches (terwijl ik ook de 'obscure' zoals Clear/White/Black wil testen) of diegene die ik leuk vind is beetje te duur om naar NL te verschepen; het is dan bijna goedkoper om een aantal "goedkope" borden aan te schaffen met die specifieke Switches.

Voordeel van vrijgezel zijn, geen partner die last heeft als ik 's nachts zit te werken/gamen (buiten mijn kat, maar die valt mij lastig tijdens het werk door of voor mijn beeldscherm te zitten/mee willen praten met vergaderingen of ligt zo hard te snurken)

[Voutloos]

Of een SPA goed met SEO scoort is ook wel een beetje een defiitiekwestie. Google komt heel ver dus praktisch gezien heb je dan SEO. Maar dan wel tegen onneembare kosten voor startende search engines.

Cynisch: Dingen als React zorgen er voor dat je altijd Google of Facebook als vertrekpunt hebt als je gaat surfen. Ten opzichte van primair serverside zal er altijd meer complexiteit voor de user agent zichtbaar zijn.

[ Voor 13% gewijzigd door Voutloos op 20-12-2021 08:01 ]

[RagingPenguin]

Voutloos schreef op maandag 20 december 2021 @ 07:59:
Cynisch: Dingen als React zorgen er voor dat je altijd Google of Facebook als vertrekpunt hebt als je gaat surfen. Ten opzichte van primair serverside zal er altijd meer complexiteit voor de user agent zichtbaar zijn.

? Met een SPA laadt je nog steeds de website vanaf het domein waar die op geserveerd is, met exact dezelfde user-agent als bij een MPA. Wat in de begin dagen van SPA's vooral kut was dat analytics tools niet om konden gaan met client-side routing.

[Voutloos]

Keyword: surfen. Als je de site kent, is het voor een eindgebruiker om het even. Maar de site ontdekken kan enkel via een belachelijk complexe spider als Google.

offtopic:
Je leest wel bizar selectief/slaperig als je uit mn post haalt dat ik SPA’s niet snap.

[ Voor 28% gewijzigd door Voutloos op 20-12-2021 08:23 ]

[hackerhater]

CodeCaster schreef op zondag 19 december 2021 @ 16:54:
Mensen die fitties gooien over SOAP kan ik ook niet serieus nemen; die hebben blijkbaar het tijdperk gemist waarin API-documentatie niet bestond en het gemiddelde dataverkeer nog niet over HTTPS liep. Met een gegenereerde WSDL weet je in ieder geval nog welke endpoints er op een API zitten en welke modellen die teruggeeft. Ja het is XML, en dat is wat meer verbose dan JSON. Als dat het enige is wat je kunt inbrengen...

Inderdaad.
Als ik tegen third-parties aan moet praten met mijn code verkies ik SOAP met een harde WSDL dan een (REST) API met meestal outdated documentatie.

Met een harde WSDL kan je tenminste de andere party om de oren slaan dat ze zich er niet aan houden -_-'
Ik ben nog geen enkele non-SOAP third-party API tegen gekomen waarbij de documentatie 100% klopte!
Maar de ergste offender tot nu toe is Atlastian Daar kan je beter van zeggen wat er wel klopt aan de documentatie.

[ Voor 6% gewijzigd door hackerhater op 20-12-2021 09:29 ]

[WernerL]

Voor Rest APIs heb je swagger waarmee je ook harde afspraken vast kunt leggen over je API design. Dat het weinig gebruikt wordt is een ander verhaal.

[hackerhater]

WernerL schreef op maandag 20 december 2021 @ 09:30:
Voor Rest APIs heb je swagger waarmee je ook harde afspraken vast kunt leggen over je API design. Dat het weinig geruikt wordt is een ander verhaal.

Probleem is dat Swagger in het algemeen alleen maar documentatie is
Geen afdwinging op code-niveau dat het ook dat is. Dat afdwingen at runtime kan je met SOAP wel.
Ja SOAP is rot om te begrijpen en het is bulky, maar om te praten met partijen die je niet kent is het super.

[Caelorum]

Voor dat afdwingen hebben we dan ook https://pact.io/, wat veel beter afdwingt DAN Soap (als je het goed inzet)

[hackerhater]

Caelorum schreef op maandag 20 december 2021 @ 09:33:
Voor dat afdwingen hebben we dan ook https://pact.io/, wat veel beter afdwingt DAN Soap (als je het goed inzet)

Ik heb het even bekeken, maar ik zie niet hoe dat voor een gebruiker van de API af dwingt dat A x keer mag voorkomen en echt een int is en dat B 1 keer mag voorkomen met de keuze uit x,y of z?

Dat is namelijk de kracht van SOAP. Dat het de communicatie-standaard hard af dwingt. Voor de rest is de standaard irritant en heel erg bulkie om te gebruiken (verbose).

Voor mijn huidige klant hebben we de applicatie tegen 2 externe beheersystemen aan moeten praten.
Beide SOAP-API's waarbij we de WSDL aangeleverd kregen.
Geïmplementeerd volgens de WSDL's en de connectie-tests gingen direct foutloos. Geen trial&error, het werkte gewoon.

[ Voor 35% gewijzigd door hackerhater op 20-12-2021 09:47 ]

[Merethil]

hackerhater schreef op maandag 20 december 2021 @ 09:31:
[...]


Probleem is dat Swagger in het algemeen alleen maar documentatie is

Als je het laat genereren uit je code is het nog goed te doen. Ons platform genereert on-the-fly een swagger als je deze opvraagt na de laatste deployment, en die cached hij dan tot er een nieuwe deployment plaatsvindt. Op die manier heb je altijd de nieuwste versie van de swaggerdefinitie die hoort bij de opgevraagde API. Omdat 'ie genereert op basis van de code heb je ook direct de juiste definities voor velden.

Wat er niet standaard in zit is het doorgeven van dataformaten, b.v. voor een datum. In het platform zit ondersteuning voor comments op veldniveau en methodeniveau, dus kunnen we deze gebruiken voor dat soort informatie. Die comments worden dan automatisch op veldniveau of op methodeniveau in de swagger bijgelezen zodat je daar direct ziet dat een datumveld bijvoorbeeld in "yyyy-MM-dd'T'HH:mm:ss.SSS" met timezone UTC aangeleverd dient te worden.

Dit lijkt op zich goed te werken voor het overgrote deel van de afnemers, behalve één bedrijf waar mensen zitten die voor zover ik heb begrepen nooit hebben geleerd hoe ze moeten lezen.

[hackerhater]

@Merethil
Als je het zo diep implementeert, werkt het inderdaad prima
Helaas doen maar weinig dat waardoor de documentatie een gegeven moment gaat achterlopen

[Janoz]

Merethil schreef op maandag 20 december 2021 @ 09:47:
[...]


Als je het laat genereren uit je code is het nog goed te doen. Ons platform genereert on-the-fly een swagger als je deze opvraagt na de laatste deployment, en die cached hij dan tot er een nieuwe deployment plaatsvindt. Op die manier heb je altijd de nieuwste versie van de swaggerdefinitie die hoort bij de opgevraagde API. Omdat 'ie genereert op basis van de code heb je ook direct de juiste definities voor velden.

Nadeel van een code first approach is dat je je API onbedoeld kan wijzigen. Zeker wanneer je API afgenomen wordt door anderen is een contract first aanpak veiliger.

[Merethil]

Janoz schreef op maandag 20 december 2021 @ 10:06:
[...]


Nadeel van een code first approach is dat je je API onbedoeld kan wijzigen. Zeker wanneer je API afgenomen wordt door anderen is een contract first aanpak veiliger.

Zeker, maar daar houd je dan ook rekening mee in je opzet van je API/code. Sowieso hadden we het hier laatst al over viewmodels - die houden wij ook aan. Elke "source" (API endpoint) krijgt zijn eigen viewmodel waarop wij alleen dingen toevoegen. Als er toch een wijziging moet plaatsvinden waarbij we zaken verwijderen danwel hernoemen wordt het een nieuwe versie van het endpoint (met versienummer in de URL) en ondersteunen we ook de oude versie.

Hetzelfde probleem houd je ook met je WSDL's als deze niet correct opnieuw worden gegenereerd - kijk maar eens naar het aantal mopperende mensen die een WSDL krijgen waar de provider zich uiteindelijk helemaal niet netjes aan houdt

Het is trouwens ook onderdeel van onze code reviews - van elkaar in de gaten houden dat we geen slopende wijzigingen maken door DEV/TST en ACC met elkaar te vergelijken en te zien of alles nog klopt volgens de eerder gemaakte afspraken.
Ook wordt er een set tests op afgevuurd van buitenaf die wij zelf niet ontwikkelen - daarin komt ook altijd naar voren dat we een naamswijziging / wijziging van veldtype etc. hebben gedaan die niet verwacht was.

[ Voor 19% gewijzigd door Merethil op 20-12-2021 10:19 ]

[Janoz]

Merethil schreef op maandag 20 december 2021 @ 10:14:
Hetzelfde probleem houd je ook met je WSDL's als deze niet correct opnieuw worden gegenereerd - kijk maar eens naar het aantal mopperende mensen die een WSDL krijgen waar de provider zich uiteindelijk helemaal niet netjes aan houdt

Het ging om contract first vs code first. Niet WSDL vs swagger. Contract first is met een WSDL triviaal.

[Merethil]

Janoz schreef op maandag 20 december 2021 @ 10:50:
[...]

Het ging om contract first vs code first. Niet WSDL vs swagger. Contract first is met een WSDL triviaal.

Duidelijk, zo las ik het niet helemaal. Excuus!

[CodeCaster]

Janoz schreef op maandag 20 december 2021 @ 10:50:
[...]

Het ging om contract first vs code first. Niet WSDL vs swagger. Contract first is met een WSDL triviaal.

Ja, dat. Er is een verschil tussen "Oeps, die wijziging aan die entity die drie niveaus diep toch uit de API bleek te komen, hebben we over het hoofd gezien" en "Oh, die nieuwe property moet ook uit de API komen, op welke plek gaan we die in de WSDL / het schema stoppen?".

Bij dat laatste word je gedwongen om na te denken wat dit met je API-versioning doet, dat eerste zul je moeten afdekken met integratietests.

WernerL schreef op maandag 20 december 2021 @ 09:30:
Voor Rest APIs heb je swagger waarmee je ook harde afspraken vast kunt leggen over je API design. Dat het weinig geruikt wordt is een ander verhaal.

Mijn ervaring met (andere partijen die) Swagger/OpenAPI gebruiken, is dat het één keer wordt gegenereerd (development-time) en vervolgens niet meer aangeraakt.

Ik was onlangs bezig met een webshoppakket, en er klopte echt geen hol meer van. De voorbeeld-JSON was in 2015 aangemaakt, en daarna nooit meer bijgewerkt. Ook de types klopten niet meer, de helft van de integers/floats was string geworden, het datumformaat was veranderd, het al dan niet verplicht zijn van verschillende properties was veranderd, enzovoorts...

Bij .NET heb je tenminste nog Swashbuckle, dat at runtime met reflection kijkt wat de gedeclareerde types zijn. Maar dat werkt ook maar tot op het niveau dat de developers consequent zijn, want wanneer een controller-action IActionResult retourneert (omdat je soms model-JSON returnt, en soms een statuscode al dan niet met Problem Json (RFC 7808), dus het returntype van de methode kan niet IEnumerable<OrderModel> zijn), dan moet je met attributen gaan aangeven wat er uit die functie komt, en dat hoeft ook weer niet overeen te komen met de werkelijkheid...

Lethalis schreef op zondag 19 december 2021 @ 17:09:
[...]
Het REST purist zijn gaat meestal toch ook meer over de juiste HTTP verbs en response codes gebruiken en een goede hiërarchie in de urls aan te brengen?

Oh hou op schei uit. Als ik die tegenkom op Stack Overflow, krijgen ze steevast een down- en soms closevote omdat ze op meningen of incorrecte aannames zijn gebaseerd.

[Insert ellenlange omschrijving van een API-call die overduidelijk RPC is] - welke statuscode moet ik volgens REST teruggeven om deze exotische uitzonderingssituatie correct te omschrijven?

- Geen, wat je beschrijft is RPC, geen REST, en REST doet niks met statuscodes, tenzij ze over het HTTP-niveau gaan (authentication, authorization, rate limiting, content negotiation, conditional requests). Moet je dan toch per se de HTTP-statusregel gebruiken en niet een JSON-body waar de ontvangende kant wat mee kan, dan heb je 9 van de 10 keer 409 Conflict of 422 Unprocessable Entity nodig (of gewoon een 400 want who cares), en de rest (ha-ha) is praktisch irrelevant. En dan nog weet de caller niet wat er mis is, dus again, zet het in je fucking body.

[ Voor 72% gewijzigd door CodeCaster op 20-12-2021 11:17 ]

[Alex)]

CodeCaster schreef op maandag 20 december 2021 @ 10:57:
[...]

Bij .NET heb je tenminste nog Swashbuckle

Ik ben een tijdje terug overgestapt op NSwag, dat werkt naar mijn ervaring nét even ietsjes beter samen met enums. Ik heb daarna in de build een stap opgenomen die automatisch een complete client genereert (via NSwag.MSBuild).

Dat werkt best wel heel erg goed.

[Caelorum]

hackerhater schreef op maandag 20 december 2021 @ 09:39:
[...]
Ik heb het even bekeken, maar ik zie niet hoe dat voor een gebruiker van de API af dwingt dat A x keer mag voorkomen en echt een int is en dat B 1 keer mag voorkomen met de keuze uit x,y of z? [...]

Hoe ik het normaal zou inzetten is dat de afnemers via een contract aangeven wat ze precies gebruiken/verwachten, doorgaans doordat ze het in de eigen testbase opnemen en bij het draaien van de tests een contract produceren. Aan de API kant neem je dat dan op in je testbase en dan weet je meteen bij veranderingen welke contracten met consumers je breekt.
Dit kan je ook helemaal loskoppelen van je builds als je wil. Voor veel afnemers kan je dan ook 1 of meerdere standaard clients ontwikkelen die ze kunnen gebruiken.

In the end heb je gewoon een hele set aan contract voorbeelden van hoe de API daadwerkelijk wordt gebruikt die in testvorm gegoten zijn.

Het nadeel van het verhaal is dat je wel echt moet samenwerken met de afnemende partijen (en als afnemer met de producerende kant). Dat eist wat organisatorische inzet

[ Voor 7% gewijzigd door Caelorum op 20-12-2021 11:38 ]

[Lethalis]

CodeCaster schreef op maandag 20 december 2021 @ 10:57:
[...]
- Geen, wat je beschrijft is RPC, geen REST, en REST doet niks met statuscodes, tenzij ze over het HTTP-niveau gaan (authentication, authorization, rate limiting, content negotiation, conditional requests). Moet je dan toch per se de HTTP-statusregel gebruiken en niet een JSON-body waar de ontvangende kant wat mee kan, dan heb je 9 van de 10 keer 409 Conflict of 422 Unprocessable Entity nodig (of gewoon een 400 want who cares), en de rest (ha-ha) is praktisch irrelevant. En dan nog weet de caller niet wat er mis is, dus again, zet het in je fucking body.

Ik doe zelf meestal idd gewoon een 400 Bad Request en geef een JSON body met omschrijving (reason) terug die bijvoorbeeld in de frontend wordt getoond.

Maar goed, ik ben dan ook geen purist En vaak te lui om dat soort details uit te zoeken, laat staan dat ik er een post op SO aan zou wijden.

Sowieso is een "resource" lastig als het om een handeling gaat die geen CRUD is, maar je mag werkwoorden gebruiken dacht ik.

Anyways... gaat het wel goed? Ik dacht dat ik gefrustreerd was Ben nog aan het bijkomen van het feit dat mijn dochtertje van 5 voorlopig thuis zit en ik maar moet kijken hoe ik het oplos met mijn werk.

Heb voorlopig maar vrije dagen opgenomen. Ik ben helaas iemand die het beste werkt als hij zich zo ongeveer opsluit in een kamer, multi tasken is mijn ding niet... dus ik zie de komende periode somber in.

Ik doe maar even alsof de deadlines er niet zijn

[CodeCaster]

Lethalis schreef op maandag 20 december 2021 @ 11:41:
[...]

Ik doe zelf meestal idd gewoon een 400 Bad Request en geef een JSON body met omschrijving (reason) terug die bijvoorbeeld in de frontend wordt getoond.

Maar goed, ik ben dan ook geen purist En vaak te lui om dat soort details uit te zoeken, laat staan dat ik er een post op SO aan zou wijden.

Sowieso is een "resource" lastig als het om een handeling gaat die geen CRUD is, maar je mag werkwoorden gebruiken dacht ik.

Anyways... gaat het wel goed? Ik dacht dat ik gefrustreerd was Ben nog aan het bijkomen van het feit dat mijn dochtertje van 5 voorlopig thuis zit en ik maar moet kijken hoe ik het oplos met mijn werk.

Heb voorlopig maar vrije dagen opgenomen. Ik ben helaas iemand die het beste werkt als hij zich zo ongeveer opsluit in een kamer, multi tasken is mijn ding niet... dus ik zie de komende periode somber in.

Ik doe maar even alsof de deadlines er niet zijn

API's schrijven en consumeren is mijn dagelijkse werk, naast of in combinatie met ETL, documentatie schrijven en test-, release- en source control-processen verbeteren.

Ik kom daarbij een heleboel troep en incompetentie tegen en raak daar soms een beetje gefrustreerd van ja. Gelukkig kan ik het hier en op SO van me af schrijven, en ben ik in het echt meestal best gezellig.

Kan me inderdaad voorstellen dat het lastig is met kinderen die plots weer drie weken thuis zitten...

[Merethil]

CodeCaster schreef op maandag 20 december 2021 @ 12:33:
[...]

API's schrijven en consumeren is mijn dagelijkse werk, naast of in combinatie met ETL, documentatie schrijven en test-, release- en source control-processen verbeteren.

Ik kom daarbij een heleboel troep en incompetentie tegen en raak daar soms een beetje gefrustreerd van ja. Gelukkig kan ik het hier en op SO van me af schrijven, en ben ik in het echt meestal best gezellig.

Kan me inderdaad voorstellen dat het lastig is met kinderen die plots weer drie weken thuis zitten...

Ik loop nu steeds tegen een interne developmentclub bij een klant aan die REST-resources maken á la

code:

GET /restapi/customer/setPhotoForCustomer?guestNumber={gnum}&photo_location={phot_loc}&IsAvailable=true

of

code:

PUT /restapi/guest/{gnum}/addVisiToSiteForCustomer?site_code={siteCode}&timestamp={datetime}&guest_number={gnum}
Body: {leeg}

en elke keer vraag ik me af wat ze aan het doen zijn als ze weer een excentriek endpoint verzinnen. Het mooiste is nog dat we de helft van de tijd 200 / OK terugkrijgen, met in de body:

code:

{
    "succes": "false",
    "error": "Customer number 1234567890 not found"
}

Ook dan ben ik blij dat ik een collega heb die hetzelfde meemaakt, kunnen we even tegen elkaar mopperen

[Kalentum]

Merethil schreef op maandag 20 december 2021 @ 13:55:
[...]


Ik loop nu steeds tegen een interne developmentclub bij een klant aan die REST-resources maken á la

code:

GET /restapi/customer/setPhotoForCustomer?guestNumber={gnum}&photo_location={phot_loc}&IsAvailable=true

of

code:

PUT /restapi/guest/{gnum}/addVisiToSiteForCustomer?site_code={siteCode}&timestamp={datetime}&guest_number={gnum}
Body: {leeg}

en elke keer vraag ik me af wat ze aan het doen zijn als ze weer een excentriek endpoint verzinnen. Het mooiste is nog dat we de helft van de tijd 200 / OK terugkrijgen, met in de body:

code:

{
    "succes": "false",
    "error": "Customer number 1234567890 not found"
}

Ook dan ben ik blij dat ik een collega heb die hetzelfde meemaakt, kunnen we even tegen elkaar mopperen

Het enige wat daar REST aan is, is het eerste stukje van de URL. Maar goed, API's bedenken is heel makkelijk, een consistente, logische API die enigszins doet wat een developer verwacht (principle of least surprise) is moeilijk.

[Woy]

Janoz schreef op maandag 20 december 2021 @ 10:06:
[...]


Nadeel van een code first approach is dat je je API onbedoeld kan wijzigen. Zeker wanneer je API afgenomen wordt door anderen is een contract first aanpak veiliger.

Met een contract first is het natuurlijk ook prima mogelijk om non-compatibel te zijn na een wijziging van het contract. Natuurlijk is dat risico met code-first wel iets groter, maar met een juiste opzet ( en bijbehorende checks ) moet je aan dezelfde regels voldoen om compatible te blijven.

Als ik dingen code-first doe, dan leg ik het contract alsnog vast in een set bestanden die niet de daadwerkelijke implementatie zijn. Uiteindelijk is het dan nog steeds contract-first, alleen is het contract wel in code

[ElkeBxl]

Merethil schreef op maandag 20 december 2021 @ 13:55:
[...]
en elke keer vraag ik me af wat ze aan het doen zijn als ze weer een excentriek endpoint verzinnen. Het mooiste is nog dat we de helft van de tijd 200 / OK terugkrijgen, met in de body:

code:

{
    "succes": "false",
    "error": "Customer number 1234567890 not found"
}

Ook dan ben ik blij dat ik een collega heb die hetzelfde meemaakt, kunnen we even tegen elkaar mopperen

* ElkeBxl meldt haar ook met deze ervaring en moppert wat mee
Hier exact hetzelfde met die bullshit "success" dingen in de response. Niet eens een code meegeven, gewoon direct de vertaling van de error in NL, FR, EN en DE. Moet ik zelf nog uitzoeken wat er fout is gelopen en hopen dat de vertaalde labels uberhaupt bestaan. Genoeg meegemaakt dat ik enkel een "success": "false" terugkrijg. Tja dan krijgen ze gewoon een bericht met een copy van de request en een "please fix this".

Ondertussen beginnen ze de response codes beetje bij beetje te gebruiken. Maar een 404 gebruiken voor als ik iets opvraag dat niet bestaat, dat doen we niet. Nee we gebruiken 204 No Content om aan te geven dat de data die ik opvraag niet bestaat Hun uitleg? "we vinden de data niet met die request en dus is er geen content om terug te sturen". En natuurlijk heeft niet elke response die "success" in de response body dus dat is dan ook al niet betrouwbaar. So yeah...

[Creepy]

ElkeBxl schreef op maandag 20 december 2021 @ 14:19:
[...]
Hun uitleg? "we vinden de data niet met die request en dus is er geen content om terug te sturen".

O wow. " we vinden de data niet", elke beetje devver zou er dan een 404 van maken. Maar dat helemaal kapot redeneren naar een 204, alsof er een product owner die denkt te kunnen devven zich er mee bemoeit heeft......

[Mugwump]

ElkeBxl schreef op maandag 20 december 2021 @ 14:19:
[...]

* ElkeBxl meldt haar ook met deze ervaring en moppert wat mee
Hier exact hetzelfde met die bullshit "success" dingen in de response. Niet eens een code meegeven, gewoon direct de vertaling van de error in NL, FR, EN en DE. Moet ik zelf nog uitzoeken wat er fout is gelopen en hopen dat de vertaalde labels uberhaupt bestaan. Genoeg meegemaakt dat ik enkel een "success": "false" terugkrijg. Tja dan krijgen ze gewoon een bericht met een copy van de request en een "please fix this".

Ondertussen beginnen ze de response codes beetje bij beetje te gebruiken. Maar een 404 gebruiken voor als ik iets opvraag dat niet bestaat, dat doen we niet. Nee we gebruiken 204 No Content om aan te geven dat de data die ik opvraag niet bestaat Hun uitleg? "we vinden de data niet met die request en dus is er geen content om terug te sturen". En natuurlijk heeft niet elke response die "success" in de response body dus dat is dan ook al niet betrouwbaar. So yeah...

Zo werkte ik ooit eens in een team met een volstrekt onhandelbare front-enderdie z'n vak totaal niet verstond, maar wel het idee had dat hij zo ongeveer de best mogelijke developer ooit was en derhalve ook van niemand iets wilde aannemen. Ik had een REST API ontwikkeld die inderdaad bij een opvraging op basis van ID netjes een 404 gaf op het moment dat iets niet bestond. Meneer de rockstar developer begreep helemaal niets van REST (het was immers pas 2018 ofzo) en kwam informeren wat ik dacht dat die 404 moest betekenen. Ik antwoordde uiteraard dat dit betekent dat de resource niet bestaat, waarna ik een hele tirade kreeg over dat meneer wel wist hoe het HTTP protocol werkte, maar dat hij wilde weten wat een 404 van een REST API betekende.

[Merethil]

ElkeBxl schreef op maandag 20 december 2021 @ 14:19:
[...]

* ElkeBxl meldt haar ook met deze ervaring en moppert wat mee
Hier exact hetzelfde met die bullshit "success" dingen in de response. Niet eens een code meegeven, gewoon direct de vertaling van de error in NL, FR, EN en DE. Moet ik zelf nog uitzoeken wat er fout is gelopen en hopen dat de vertaalde labels uberhaupt bestaan. Genoeg meegemaakt dat ik enkel een "success": "false" terugkrijg. Tja dan krijgen ze gewoon een bericht met een copy van de request en een "please fix this".

Ondertussen beginnen ze de response codes beetje bij beetje te gebruiken. Maar een 404 gebruiken voor als ik iets opvraag dat niet bestaat, dat doen we niet. Nee we gebruiken 204 No Content om aan te geven dat de data die ik opvraag niet bestaat Hun uitleg? "we vinden de data niet met die request en dus is er geen content om terug te sturen". En natuurlijk heeft niet elke response die "success" in de response body dus dat is dan ook al niet betrouwbaar. So yeah...

De marketingtool waar ik tegenaan moest praten (Selligent) gaf ook op alle calls een 500 Internal Server Error terug:

Gemiddelde 404-achtige error:

code:

Header: 500 Internal Server Error
Body: "Resource /rest/endpoint/naamvanapplicatie/naamvantabel unavailable"

Gemiddelde 400-achtige error:

code:

Header: 500 Internal Server Error
Body: "Data in field XYZ not in line with expected definition"

Gemiddelde 500-achtige error:

code:

Header: 500 Internal Server Error
Body: "Unexpected error occurred"

Die laatste kwam voor alles wat ze niet expliciet hadden ingebouwd naar voren, maar dus ook voor:

• geplande downtime
• een ongerelateerde applicatie die verderop in het landschap eruit lag
• een record dat niet bestaat
• een veld dat niet bestaat maar wel gevuld is in de request, een veld dat wél bestaat en gevuld is in de request maar opeens 'niet gevonden' kan worden in de database (wtf?!)

... en zo nog veel andere permutaties.

Omdat 'ie ook vaak teruggegeven werd terwijl er helemaal niets mis leek te zijn hebben we een retry ingebouwd: na elke 500 Internal Server Error proberen we het nog tweemaal extra met tussenpozen van 3 seconden (yup... Elke request kan zomaar 10+ seconden duren) en dan ging het opeens prima.
Op die manier ongeveer 90% van de foutlogging richting die applicatie weg weten te werken

[RagingPenguin]

ElkeBxl schreef op maandag 20 december 2021 @ 14:19:
[...]

En natuurlijk heeft niet elke response die "success" in de response body dus dat is dan ook al niet betrouwbaar. So yeah...

Dat laatste is vooral een drama. Al heb je een of ander vaag RCP-achtig protocol op basis van REST dan is dat opzich niet zo'n probleem. Daar bouw ik dan wel een WeirdosRCPClient ding voor die alle ongein mapt naar iets wat logisch is. Maar als het van uitzonderingen aan elkaar hangt dan moet je dus per call met een httpclient gaan klooien om het een beetje consitent te maken naar de rest van je applicatie.

[RagingPenguin]

Merethil schreef op maandag 20 december 2021 @ 15:10:
[...]


De marketingtool waar ik tegenaan moest praten (Selligent) gaf ook op alle calls een 500 Internal Server Error terug:

Gemiddelde 404-achtige error:

code:

Header: 500 Internal Server Error
Body: "Resource /rest/endpoint/naamvanapplicatie/naamvantabel unavailable"

Gemiddelde 400-achtige error:

code:

Header: 500 Internal Server Error
Body: "Data in field XYZ not in line with expected definition"

Gemiddelde 500-achtige error:

code:

Header: 500 Internal Server Error
Body: "Unexpected error occurred"

Die laatste kwam voor alles wat ze niet expliciet hadden ingebouwd naar voren, maar dus ook voor:

• geplande downtime
• een ongerelateerde applicatie die verderop in het landschap eruit lag
• een record dat niet bestaat
• een veld dat niet bestaat maar wel gevuld is in de request, een veld dat wél bestaat en gevuld is in de request maar opeens 'niet gevonden' kan worden in de database (wtf?!)

... en zo nog veel andere permutaties.

Omdat 'ie ook vaak teruggegeven werd terwijl er helemaal niets mis leek te zijn hebben we een retry ingebouwd: na elke 500 Internal Server Error proberen we het nog tweemaal extra met tussenpozen van 3 seconden (yup... Elke request kan zomaar 10+ seconden duren) en dan ging het opeens prima.
Op die manier ongeveer 90% van de foutlogging richting die applicatie weg weten te werken

Wij hebben hier gewoon een interne retry library die hangfire gebruikt om dat op de achtergrond te doen (die scheduled elke keer dat een call failed een retry over X tijd). Aan de voorkant houden we er dan rekening mee dat er een inprogres state is voor een actie. Dat lost ook direct op dat veel van die vage systemen totaal niet om kunnen gaan met piek belastingen.

[Koenvh]

Wat ik in deze discussie nog mis: is het ee pie ai, aa pee ie, of aapie?

[Koenvh]

Verder ben ik bezig met proberen geautomatiseerd de energieprijzen van Essent op te halen. Gelukkig heeft die API niet te weinig informatie :

XML:

<?xml version="1.0" encoding="UTF-8"?>
<HandleOfferDetails>
  <Header>
    <Context>
      <ServiceUser>SelfService</ServiceUser>
      <Domain>MIJNESSENT</Domain>
      <Channel>BACO</Channel>
      <Brand>essent</Brand>
    </Context>
  </Header>
  <request>
    <SendOffer>false</SendOffer>
    <Customer>
      <SegmentType code="HH" text="" />
      <Connection>
        <Address>
          <HouseNr>1</HouseNr>
          <HouseNrExt />
          <Postcode>9999ZZ</Postcode>
        </Address>
      </Connection>
    </Customer>
    <Campaign>
      <CampaignID>143131</CampaignID>
      <Incentive id="" />
      <Products>
        <Product>
          <Services>
            <Service code="LOOPTIJD" value="F" />
            <Service code="VERBLIJFSFUNCTIE" value="1" />
          </Services>
        </Product>
      </Products>
    </Campaign>
    <ContactDate>2021-12-20</ContactDate>
    <StandardAnnualUsages>
      <StandardAnnualUsage>
        <EnergyType code="01" text="" />
        <ValueStandard>100000</ValueStandard>
      </StandardAnnualUsage>
      <StandardAnnualUsage>
        <EnergyType code="02" text="" />
        <ValueStandard>250000</ValueStandard>
      </StandardAnnualUsage>
    </StandardAnnualUsages>
  </request>
  <response>
    <Campaign>
      <Campaign code="143131" text="Acq DF Variabel OBT (dec)" />
      <Type Code="Above the line" />
      <Description>Variabel contract, onbepaalde looptijd (tijdelijk aanbod)</Description>
      <Priority>100</Priority>
      <Period FromDate="2021-12-01" ToDate="2021-12-31" />
      <CampaignDetails>
        <Actions>
          <Action code="AddCustomer" text="AddCustomer" />
        </Actions>
        <SegmentType code="HH" text="Huishouden" />
        <AsIsProducts />
        <ToBeProducts>
          <Product>
            <EnergyType code="01" text="Elektriciteit" />
            <ProductPackage code="E_H_BD" text="Elektriciteit Keuzetarief Groene Stroom" />
            <Services>
              <Service code="LOOPTIJD" text="Looptijd">
                <Option value="F" description="F" />
              </Service>
              <Service code="KEUZE_TARIEF_E" text="Keuze tarief E">
                <Option value="S" description="Standaard" />
              </Service>
              <Service code="VERBLIJFSFUNCTIE" text="Verblijfsfunctie">
                <Option value="1" description="Ja" enabled="true" isDefault="true" Blocked="false" />
                <Option value="0" description="Nee" enabled="true" isDefault="false" Blocked="false" />
              </Service>
            </Services>
          </Product>
          <Product>
            <EnergyType code="02" text="Gas" />
            <ProductPackage code="G_H_B" text="Gas" />
            <Services>
              <Service code="LOOPTIJD" text="Looptijd">
                <Option value="F" description="F" />
              </Service>
            </Services>
          </Product>
        </ToBeProducts>
        <CampaignServices />
        <UseContractDate>false</UseContractDate>
      </CampaignDetails>
      <PropositionType>Dual Fuel Acquisitie</PropositionType>
    </Campaign>
    <StandardAnnualUsages>
      <StandardAnnualUsage>
        <EnergyType code="01" text="01" />
        <ValueStandard>100000</ValueStandard>
        <UnitOfMeasurement>kWh</UnitOfMeasurement>
      </StandardAnnualUsage>
      <StandardAnnualUsage>
        <EnergyType code="02" text="02" />
        <ValueStandard>250000</ValueStandard>
        <UnitOfMeasurement>m3</UnitOfMeasurement>
      </StandardAnnualUsage>
    </StandardAnnualUsages>
    <TotalAmounts>
      <TotalMonthlyAmount>
        <Amount>39743.33</Amount>
        <Description>Totaal maandkosten elektriciteit en gas</Description>
      </TotalMonthlyAmount>
      <TotalYearlyAmount>
        <Amount>476919.63</Amount>
        <Description>Totaal jaarkosten elektriciteit en gas</Description>
      </TotalYearlyAmount>
    </TotalAmounts>
    <TotalDiscountedAmounts />
    <Offers>
      <OfferOverview>
        <Product>
          <EnergyType code="01" text="" />
          <SegmentType code="HH" text="" />
          <PropositionID>AW5_E_H_BD-99-S</PropositionID>
          <PropositionDescription>Groene Stroom - Variabel - Flexibele looptijd</PropositionDescription>
          <Services>
            <Service code="KEUZE_TARIEF_E" value="S" />
            <Service code="LOOPTIJD" value="F" />
            <Service code="VERBLIJFSFUNCTIE" value="1" />
          </Services>
          <CARData>
            <Profile>
              <Origin>DEFAULT</Origin>
              <Profile code="NPK" text="" />
            </Profile>
            <GridCompanyInformation>
              <Origin>DEFAULT</Origin>
              <GridCompany EAN="8716879000004" name="" />
            </GridCompanyInformation>
            <NetAreaInformation>
              <Origin>DEFAULT</Origin>
              <NetArea EAN="871687910000219120" name="" />
            </NetAreaInformation>
            <Residential>
              <Origin>REQUEST</Origin>
              <Value>1</Value>
            </Residential>
            <CapacityTariffInformation>
              <Origin>DEFAULT</Origin>
              <CapacityTariff code="8742010102115" text="8742010102115" />
            </CapacityTariffInformation>
            <DeterminationComplex>
              <Origin>EDSN</Origin>
              <Value>00</Value>
            </DeterminationComplex>
          </CARData>
        </Product>
        <ConsumptionPrice>
          <TotalConsumPrice>
            <Amount>0.4432</Amount>
            <Description>elektriciteit Enkeltarief (1 t/m 10.000 kWh):</Description>
            <Zone>1</Zone>
          </TotalConsumPrice>
          <TotalConsumPrice>
            <Amount>0.40503</Amount>
            <Description>elektriciteit Enkeltarief (10.001 t/m 50.000 kWh):</Description>
            <Zone>2</Zone>
          </TotalConsumPrice>
          <TotalConsumPrice>
            <Amount>0.33669</Amount>
            <Description>elektriciteit Enkeltarief (50.001 t/m 10 mln kWh):</Description>
            <Zone>3</Zone>
          </TotalConsumPrice>
        </ConsumptionPrice>
        <PriceGroups>
          <Description>Leveringskosten elektriciteit</Description>
          <SequenceNr>010</SequenceNr>
          <Percentage>79</Percentage>
          <Prices>
            <Description>Variabele leveringskosten Enkeltarief</Description>
            <SequenceNr>1</SequenceNr>
            <PriceType>SUP_ELEC</PriceType>
            <UnitPrice>
              <Amount>0.29282</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>2440.17</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>29282</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Vaste leveringskosten (€ 6,49 / maand)</Description>
            <SequenceNr>5</SequenceNr>
            <PriceType>FIXED_SUP_ELEC</PriceType>
            <UnitPrice>
              <Amount>0.21323</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>6.49</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>77.83</Amount>
            </YearlyPrice>
            <UoM>€/dag</UoM>
          </Prices>
          <Prices>
            <Description>Totaal leveringskosten</Description>
            <SequenceNr>10</SequenceNr>
            <PriceType>SUBTOTAL_SUPPLY</PriceType>
            <TotalMonthlyPrice>
              <Amount>2446.66</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>29359.83</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
        <PriceGroups>
          <Description>Netbeheerkosten</Description>
          <SequenceNr>020</SequenceNr>
          <Percentage>1</Percentage>
          <Prices>
            <Description>Netbeheerder : Capaciteitstarief t/m 3 x 25A of t/m 1 x 80A (€ 250,81 / jaar)</Description>
            <SequenceNr>1</SequenceNr>
            <PriceType>CAPTAR_ELEC</PriceType>
            <UnitPrice>
              <Amount>0.68716</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>20.9</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>250.81</Amount>
            </YearlyPrice>
            <UoM>€/dag</UoM>
          </Prices>
          <Prices>
            <Description>Totaal netbeheerkosten</Description>
            <SequenceNr>2</SequenceNr>
            <PriceType>SUBTOTAL_NETWORK</PriceType>
            <TotalMonthlyPrice>
              <Amount>20.9</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>250.81</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
        <PriceGroups>
          <Description>Belasting en toeslagen</Description>
          <SequenceNr>030</SequenceNr>
          <Percentage>20</Percentage>
          <Prices>
            <Description>Energiebelasting zone 1 (1 t/m 10.000 kWh)</Description>
            <SequenceNr>3</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.11408</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>95.07</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>1140.8</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Energiebelasting zone 2 (10.001 t/m 50.000 kWh)</Description>
            <SequenceNr>3</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.06248</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>208.27</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>2499.2</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Energiebelasting zone 3 (50.001 t/m 10 mln kWh)</Description>
            <SequenceNr>3</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.01664</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>69.33</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>832</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Opslag duurzame energie- en klimaattransitie zone 1 (1 t/m 10.000 kWh)</Description>
            <SequenceNr>4</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.0363</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>30.25</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>363</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Opslag duurzame energie- en klimaattransitie zone 2 (10.001 t/m 50.000 kWh)</Description>
            <SequenceNr>4</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.04973</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>165.77</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>1989.2</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Opslag duurzame energie- en klimaattransitie zone 3 (50.001 t/m 10 mln kWh)</Description>
            <SequenceNr>4</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.02723</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>113.46</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>1361.5</Amount>
            </YearlyPrice>
            <UoM>€/kWh</UoM>
          </Prices>
          <Prices>
            <Description>Vermindering energiebelasting (€ -558,56 / jaar)</Description>
            <SequenceNr>7</SequenceNr>
            <PriceType>TAX_REDUCTION</PriceType>
            <UnitPrice>
              <Amount>-1.5303</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>-46.55</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>-558.56</Amount>
            </YearlyPrice>
            <UoM>€/dag</UoM>
          </Prices>
          <Prices>
            <Description>Totaal belasting en toeslagen</Description>
            <SequenceNr>8</SequenceNr>
            <PriceType>SUBTOTAL_TAXES</PriceType>
            <TotalMonthlyPrice>
              <Amount>635.6</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>7627.14</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
        <PriceGroups>
          <Description>Totaal elektriciteit</Description>
          <SequenceNr>040</SequenceNr>
          <Percentage />
          <Prices>
            <Description>Totaal elektriciteit</Description>
            <SequenceNr />
            <PriceType>SUBTOTAL_ELEC</PriceType>
            <TotalMonthlyPrice>
              <Amount>3103.16</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>37237.78</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
      </OfferOverview>
      <OfferOverview>
        <Product>
          <EnergyType code="02" text="" />
          <SegmentType code="HH" text="" />
          <PropositionID>AW5_G_H_B-99</PropositionID>
          <PropositionDescription>Gas - Variabel - Flexibele looptijd</PropositionDescription>
          <Services>
            <Service code="LOOPTIJD" value="F" />
            <Service code="VERBLIJFSFUNCTIE" value="1" />
          </Services>
          <CARData>
            <Profile>
              <Origin>DEFAULT</Origin>
              <Profile code="G1A" text="" />
            </Profile>
            <GridCompanyInformation>
              <Origin>DEFAULT</Origin>
              <GridCompany EAN="8716879000004" name="" />
            </GridCompanyInformation>
            <NetAreaInformation>
              <Origin>DEFAULT</Origin>
              <NetArea EAN="871718518003003501" name="" />
            </NetAreaInformation>
            <Residential>
              <Origin>REQUEST</Origin>
              <Value>1</Value>
            </Residential>
            <CapacityTariffInformation>
              <Origin>DEFAULT</Origin>
              <CapacityTariff code="8742010202112" text="8742010202112" />
            </CapacityTariffInformation>
            <DeterminationComplex>
              <Origin>EDSN</Origin>
              <Value>00</Value>
            </DeterminationComplex>
          </CARData>
        </Product>
        <ConsumptionPrice>
          <TotalConsumPrice>
            <Amount>1.65003</Amount>
            <Description>tarief gas (1 t/m 170.000 m3):</Description>
            <Zone>1</Zone>
          </TotalConsumPrice>
          <TotalConsumPrice>
            <Amount>1.23296</Amount>
            <Description>tarief gas (170.001 t/m 1 mln m3):</Description>
            <Zone>2</Zone>
          </TotalConsumPrice>
        </ConsumptionPrice>
        <PriceGroups>
          <Description>Leveringskosten gas</Description>
          <SequenceNr>010</SequenceNr>
          <Percentage>64</Percentage>
          <Prices>
            <Description>Variabele leveringskosten (G1/gasregio 4)</Description>
            <SequenceNr>1</SequenceNr>
            <PriceType>SUP_GAS</PriceType>
            <UnitPrice>
              <Amount>1.1253</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>23443.75</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>281325</Amount>
            </YearlyPrice>
            <UoM>€/m3</UoM>
          </Prices>
          <Prices>
            <Description>Vaste leveringskosten (€ 6,49 / maand)</Description>
            <SequenceNr>3</SequenceNr>
            <PriceType>FIXED_SUP_GAS</PriceType>
            <UnitPrice>
              <Amount>0.21323</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>6.49</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>77.83</Amount>
            </YearlyPrice>
            <UoM>€/dag</UoM>
          </Prices>
          <Prices>
            <Description>Totaal leveringskosten</Description>
            <SequenceNr>7</SequenceNr>
            <PriceType>SUBTOTAL_SUPPLY</PriceType>
            <TotalMonthlyPrice>
              <Amount>23450.24</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>281402.83</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
        <PriceGroups>
          <Description>Netbeheerkosten</Description>
          <SequenceNr>020</SequenceNr>
          <Percentage>0</Percentage>
          <Prices>
            <Description>Netbeheerder : Capaciteitstarief t/m 10 m3/uur, stand. jaarv. tot 4.000 m3 (€ 181,52 / jaar)</Description>
            <SequenceNr>1</SequenceNr>
            <PriceType>CAPTAR_GAS</PriceType>
            <UnitPrice>
              <Amount>0.49731</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>15.13</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>181.52</Amount>
            </YearlyPrice>
            <UoM>€/dag</UoM>
          </Prices>
          <Prices>
            <Description>Totaal netbeheerkosten</Description>
            <SequenceNr>2</SequenceNr>
            <PriceType>SUBTOTAL_NETWORK</PriceType>
            <TotalMonthlyPrice>
              <Amount>15.13</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>181.52</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
        <PriceGroups>
          <Description>Belasting en toeslagen</Description>
          <SequenceNr>030</SequenceNr>
          <Percentage>36</Percentage>
          <Prices>
            <Description>Energiebelasting zone 1 (1 t/m 170.000 m3)</Description>
            <SequenceNr>3</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.42176</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>8786.67</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>105440</Amount>
            </YearlyPrice>
            <UoM>€/m3</UoM>
          </Prices>
          <Prices>
            <Description>Energiebelasting zone 2 (170.001 t/m 1 mln m3)</Description>
            <SequenceNr>3</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.07922</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>1650.42</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>19805</Amount>
            </YearlyPrice>
            <UoM>€/m3</UoM>
          </Prices>
          <Prices>
            <Description>Opslag duurzame energie- en klimaattransitie zone 1 (1 t/m 170.000 m3)</Description>
            <SequenceNr>4</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.10297</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>2145.21</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>25742.5</Amount>
            </YearlyPrice>
            <UoM>€/m3</UoM>
          </Prices>
          <Prices>
            <Description>Opslag duurzame energie- en klimaattransitie zone 2 (170.001 t/m 1 mln m3)</Description>
            <SequenceNr>4</SequenceNr>
            <PriceType />
            <UnitPrice>
              <Amount>0.02844</Amount>
            </UnitPrice>
            <MonthlyPrice>
              <Amount>592.5</Amount>
            </MonthlyPrice>
            <YearlyPrice>
              <Amount>7110</Amount>
            </YearlyPrice>
            <UoM>€/m3</UoM>
          </Prices>
          <Prices>
            <Description>Totaal belasting en toeslagen</Description>
            <SequenceNr>8</SequenceNr>
            <PriceType>SUBTOTAL_TAXES</PriceType>
            <TotalMonthlyPrice>
              <Amount>13174.8</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>158097.5</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
        <PriceGroups>
          <Description>Totaal gas</Description>
          <SequenceNr>040</SequenceNr>
          <Percentage />
          <Prices>
            <Description>Totaal gas</Description>
            <SequenceNr />
            <PriceType>SUBTOTAL_GAS</PriceType>
            <TotalMonthlyPrice>
              <Amount>36640.17</Amount>
            </TotalMonthlyPrice>
            <TotalYearlyPrice>
              <Amount>439681.85</Amount>
            </TotalYearlyPrice>
            <UoM />
          </Prices>
        </PriceGroups>
      </OfferOverview>
    </Offers>
    <DisclaimerRegion>ZUID</DisclaimerRegion>
    <DisclaimerCode>ZAOMDIS_DEF_ND</DisclaimerCode>
    <DisclaimerURL>https://www.essent.nl/content/system/HTML/disclaimers/ZAOMDIS_DEF_ND.html</DisclaimerURL>
    <OfferType>SA</OfferType>
    <PaymentMethods>
      <PaymentMethod code="Automatische incasso" text="Automatische incasso" AdminCost="0" DiscountCost="-0.605" />
      <PaymentMethod code="Handmatige betaling" text="Handmatige betaling" AdminCost="2.42" DiscountCost="2.42" />
    </PaymentMethods>
    <VAT>true</VAT>
    <Messages>
      <Message>
        <Type>I</Type>
        <Code />
        <Message>Success</Message>
      </Message>
    </Messages>
  </response>
</HandleOfferDetails>