In zekere zin is dat er wel. Als je Angular of React gebruikt heb je namelijk geen jQuery nodig.armageddon_2k1 schreef op donderdag 29 augustus 2019 @ 08:52:
@Lethalis Ik snap niet helemaal wat Angular en RXJS met jQuery van doen hebben? Er is nagenoeg geen overlap in functionaliteit of doel.
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
/u/102105/crop56f481fe1f74f.png?f=community)
Snel refactoren dan
Scheelt toch weer een bak loze code.
Anyone who gets in between me and my morning coffee should be insecure.
Meh, afhankelijk van hoe je build straat in elkaar zit en hoe/hoeveel jQuery je gebruikt kan dat reuze meevallen. Problematischer vind ik dat je, je code in een outdated format opschrijft.:
[...]
Snel refactoren dan
Daarnaast, kun je lazy loaden. Detecteer of code nodig is met minimale code, laat vervolgens de echte module in die dat stukje code uitvoert. Doe dat per component en je laad eigenlijk nooit meer code in dan nodig. Vooral bij grote projecten scheelt dat aardig.
Onze huidige opzet doet ruwweg dit:
Per component (gewoon gespoed stukje html/css/js, hoeft geen React of iets te zijn):
- Constants.js: Een JS file met constanten, dit bevat o.a. NodeList van alle targets (of een lege NodeList indien het component niet gebruikt wordt op een pagina.
- Index.js: deze wordt in de main module opgenomen en importeert enkel de NodeList, indien deze een lengte > 0 heeft wordt de specifieke bundel ingeladen.
- Bundle.js de daadwerkelijke code inclusief alle dependencies, wordt dus enkel geladen indien nodig.
Van elke bestand worden alle ongebruikte codepaden gedropt dus. Netto blijven er dus N kleine modules over die enkel ingeladen worden indien nodig. Je gaat dus van een situatie waarin je in 1 request alle code inlaad naar een situatie waarin met enkele requests een klein deel van de code inlaad.
De enige nadelen hiervan zijn enkele regels detectiecode extra en de (met http2 minimale) overhead van meerdere requests. Maar dit effect kun je verder reduceren met een fatsoenlijk gebruik van een CDN. Niet wat het onder de streep negatief doet uitkomen.
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/25009/crop65f1e3109d1b7_cropped.jpg?f=community)
/u/172597/crop5e1225c8b1011.png?f=community)
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
/u/12668/hydra.png?f=community)
/u/293532/crop602d26dcd0ef0_cropped.png?f=community)
De grap is dat ik nog geen 4 weken later alweer volop met Angular aan het programmeren ben
Het is meer dat ik er tegenaan hik als ik het een tijdje niet meer heb gedaan, omdat er zoveel moving parts zijn.
Maar zodra ik er weer in zit, dan gaat het eigenlijk vanzelf.
10 jaar geleden vond ik het nodig om mijn eigen object mapper te schrijven, een soort light weight ORM.
Vorige week moest ik een groot project dat deze mapper gebruikt nieuw leven inblazen. En eerlijk gezegd denk ik al de hele tijd "waarom heb ik dit ooit gedaan?". Tegenwoordig zou ik gewoon Dapper kiezen. En als dat niet kan iets anders, maar altijd proberen te voorkomen dat ik het zelf ga zitten doen.
En als ik ergens niet helemaal happy mee ben, er simpelweg interfaces voor definiëren, zodat het later makkelijker te vervangen is door iets anders.
Zodat ik (of iemand anders) niet 10 jaar later met de gebakken peren zit. Door mijn keuzes 10 jaar geleden is het project anno nu nauwelijks te porteren naar .NET Core bijvoorbeeld. Toch jammer.
[ Voor 56% gewijzigd door Lethalis op 10-09-2019 12:36 ]
Ask yourself if you are happy and then you cease to be.
:strip_icc():strip_exif()/u/45575/crop5eabccf00c955_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/439769/crop5a510243ea2e3_cropped.jpeg?f=community)
Meh, je hebt er 10 jaar van kunnen genieten, dat is een eeuwigheid. Nu een stuk rewriten mag dan best, was Dapper er 10 jaar geleden al?:
[...]
De grap is dat ik nog geen 4 weken later alweer volop met Angular aan het programmeren ben
Het is meer dat ik er tegenaan hik als ik het een tijdje niet meer heb gedaan, omdat er zoveel moving parts zijn.
Maar zodra ik er weer in zit, dan gaat het eigenlijk vanzelf.
[...]
10 jaar geleden vond ik het nodig om mijn eigen object mapper te schrijven, een soort light weight ORM.
Vorige week moest ik een groot project dat deze mapper gebruikt nieuw leven inblazen. En eerlijk gezegd denk ik al de hele tijd "waarom heb ik dit ooit gedaan?". Tegenwoordig zou ik gewoon Dapper kiezen. En als dat niet kan iets anders, maar altijd proberen te voorkomen dat ik het zelf ga zitten doen.
En als ik ergens niet helemaal happy mee ben, er simpelweg interfaces voor definiëren, zodat het later makkelijker te vervangen is door iets anders.
Zodat ik (of iemand anders) niet 10 jaar later met de gebakken peren zit. Door mijn keuzes 10 jaar geleden is het project anno nu nauwelijks te porteren naar .NET Core bijvoorbeeld. Toch jammer.
Nu is alles docker en nog 10 andere buzzwords, shit happens.
Less alienation, more cooperation.
:strip_icc():strip_exif()/u/1199012/crop5e9b58ab2e2b7_cropped.jpeg?f=community)
Ook even respect inderdaad dat je gewoon toegeeft dat je in het verleden foute keuzes maakt en ervan leert. Dat soort houding ben ik zelf heel erg fan van. Waren er maar meer van dat soort mensen. Als je daarvan een team had, dan heb je een team die hun fouten durft toe te geven en zichzelf in de toekomst durft te verbeteren. Dan heb je vaak een team die erg snel fouten inziet en vooruit gaat, zonder elkaar de grond in te drukken. Vraagtekens bij je eigen werk stellen is voor mij wel een vorm van competent gedrag bij iemand.
Maar over het web met Back-End server side rendering, versus Single Page Application. Ik denk zelf dat er nog een ronde aan komt die de SPA zoals we nu kennen in Javascript weer gaat omblazen.
Uiteindelijk blijft Server-Side Rendering een solide techniek die ook de WebAssembly fase zal overleven. SPA zoals we die kennen niet.(heb het over al die Javascript frameworks)
Ik persoonlijk kijk al erg uit naar dat ik mijn gehele applicatie zowel back-end als front-end kan programmeren in C++. (Rust is daar ook vooruitstrevend in.)
Dit zal straks ook wel kunnen met C# en Java. Maar C++ en Rust zijn de voorlopers.
Het is nog niet doorgebroken, omdat volgens mij de DOM en andere browser api's not niet toegankelijk zijn voor WebAssembly.
Uiteindelijk krijg je dan een C++20 Module voor bijvoorbeeld de DOM, en dan kan je gewoon je front-end in C++ schrijven en ook je back-end.
Dat lijkt mij echt heerlijk.
Vooral met Moderne C++17 en hoger.
Maar dan maakt het niet zoveel meer uit, je kan gewoon je favoriete taal pakken die WebAssembly uitspuugt vanuit jou gewenste taal. Alleen zal de ene taal meer performance kennen, en de andere taal minder developertijd kosten.
Het probleem met talen die "systemen" nodig hebben zoals een Garbage Collector. Of een virtual machine.. etc. zullen vaak groter uitpakken. Daarom zijn lagere talen met hoge abstracties zoals C++ en Rust zo populair voor webassembly kleinere file + meer performance. Maar ze gaan volgens mij een native Garbage Collector implementeren in webassembly als OPT-IN.
Maar goed, dat is toekomst muziek. Volgens mij is het betreft Server Side rendering, of SPA gewoon de keuze of het meer een "applicatie" is met veel dynamisch gedrag op de website zelf.
Bij veel andere type website zou ik inderdaad kiezen voor server-side rendering, met zo weinig mogelijk Javascript. Het is dus gewoonweg een afweging. Het ene is niet beter als het andere, het heeft ieders zijn eigen doel.
Maar over het web met Back-End server side rendering, versus Single Page Application. Ik denk zelf dat er nog een ronde aan komt die de SPA zoals we nu kennen in Javascript weer gaat omblazen.
Uiteindelijk blijft Server-Side Rendering een solide techniek die ook de WebAssembly fase zal overleven. SPA zoals we die kennen niet.(heb het over al die Javascript frameworks)
Ik persoonlijk kijk al erg uit naar dat ik mijn gehele applicatie zowel back-end als front-end kan programmeren in C++. (Rust is daar ook vooruitstrevend in.)
Dit zal straks ook wel kunnen met C# en Java. Maar C++ en Rust zijn de voorlopers.
Het is nog niet doorgebroken, omdat volgens mij de DOM en andere browser api's not niet toegankelijk zijn voor WebAssembly.
Uiteindelijk krijg je dan een C++20 Module voor bijvoorbeeld de DOM, en dan kan je gewoon je front-end in C++ schrijven en ook je back-end.
Dat lijkt mij echt heerlijk. Vooral met Moderne C++17 en hoger.
Maar dan maakt het niet zoveel meer uit, je kan gewoon je favoriete taal pakken die WebAssembly uitspuugt vanuit jou gewenste taal. Alleen zal de ene taal meer performance kennen, en de andere taal minder developertijd kosten.
Het probleem met talen die "systemen" nodig hebben zoals een Garbage Collector. Of een virtual machine.. etc. zullen vaak groter uitpakken. Daarom zijn lagere talen met hoge abstracties zoals C++ en Rust zo populair voor webassembly kleinere file + meer performance. Maar ze gaan volgens mij een native Garbage Collector implementeren in webassembly als OPT-IN.
Maar goed, dat is toekomst muziek. Volgens mij is het betreft Server Side rendering, of SPA gewoon de keuze of het meer een "applicatie" is met veel dynamisch gedrag op de website zelf.
Bij veel andere type website zou ik inderdaad kiezen voor server-side rendering, met zo weinig mogelijk Javascript. Het is dus gewoonweg een afweging. Het ene is niet beter als het andere, het heeft ieders zijn eigen doel.
Mijn indruk is dat het heel handig is voor reken intensieve taken. Zo zou je bijvoorbeeld een video codec in C++ kunnen maken die compileert naar wasm.
Vervolgens kan iedereen video's met jouw codec direct bekijken, zonder dat deze geïnstalleerd hoeft te zijn op de computer.
Dat vind ik persoonlijk wel "nieuw" en opent allerlei mogelijkheden voor content providers om hun eigen DRM oplossingen aan te bieden etc.
Maar een hele web applicatie bouwen in C++ zal niet in zo'n vaart lopen, omdat er simpelweg weinig C++ developers zijn (tov C#, Java, Python, Golang, etc).
De kans is dus groot dat een andere taal populairder zal zijn.
Wie bouwt er anno nu zijn rest api in C++ ?
Ik weet dat het kán, maar echt gebruikelijk is het niet.
PS
Hoe is de markt voor C++ developers eigenlijk in Nederland?
Ik werk dan wel als .Net developer, maar heb een achtergrond in C/C++. Soms vraag ik me weleens af of het niet beter is om iets te doen dat minder mensen doen / kunnen.
Ask yourself if you are happy and then you cease to be.
Ik had er gewoon goed aan gedaan om een standaard library te kiezen (of ik hem nou mooi vind of niet), omdat ik dan "gratis" gebruik maak van het werk dat anderen stoppen in het onderhouden van die library.
Nu heb ik zelf een micro ORM library waarvan ik allang geen zin meer heb om die te onderhouden. Hij zit mij alleen maar in de weg. En dat is ook waar @Hydra op doelt. Dat veel programmeurs allemaal custom libraries bouwen door de jaren heen voor zaken waar dat helemaal niet nodig was geweest.
"hun eigen kleine koninkrijkje van shit"
Ik vond in 2009 dat nhibernate en EF veel te veel overhead gaven en wou iets simpelers. Dapper en veel andere micro ORM's waren er toen nog niet, dus ging ik mijn eigen micro ORM schrijven en door de jaren heen werden ook steeds meer projecten afhankelijk van die library.
Maar je kunt je dus ook afvragen waarom miljoenen programmeurs wél gewoon met nhibernate en EF uit de voeten konden en hun aandacht volledig konden richten op het bouwen van nieuwe functionaliteit voor hun werkgever. En waarom ik per se een eigen micro ORM moest schrijven.
Ask yourself if you are happy and then you cease to be.
Oh, ik snap heel goed waar je op doelt, ik moet ook zeggen dat je eigen ORM schrijven iets anders is dan ik dacht uit je post op te maken ( object mapper ) maar dat zal mijn gebrek zijn.
Komt nog eens bij dat je een redelijk zware afhankelijkheid neemt op een bibliotheek waarvan je maar moet hopen dat de visie van de ontwikkelaars strookt met die van jou, nu en in de toekomst. Dit wil nog wel eens een heikel punt zijn.
Een simpele DB laag met ADO.net is misschien wel veel code, maar het is wel redelijk simpel. En niet simpel als in dat het dom is, maar meer dat het gemakkelijk te begrijpen is wat je code allemaal doet.
Een methode die een object persisteert naar een DB is redelijk te behappen, het gevaar schuilt hem er weer in dat als je dit vier keer hebt gedaan dat je gaat denken: "Dat kan ik ook wel generiek maken" dus dan krijg je ineens Store<T> en ga je allerlei dingen met reflection doen om de velden de uit te lezen zodat je on the fly het juiste db type kunt toewijzen.
Aan de andere kant, EF en andere ORMs zijn ook gewoon een zwarte doos en hetgeen dat ze pretenderen te doen, het relationele weghalen, gaat ook niet altijd op. Leaky abstractions enzo. DBcontexts die ineens overal opduiken etc. etc.
Zo kunnen we nog wel even doorgaan, IOC containers aspect oriented programming enz. enz.
Dus ja, hangt ervan af zeg maar.
Edit: nu ik er nog wat langer over nadenk, ik weet of ik het zo zwart wit zou stellen. EF in de eerste versies was nu niet echt om over naar huis te schrijven en nHibernate is ook redelijk complex en zwaar. De cognitive load van beiden is best hoog durf ik wel te stellen.:
[...]
Ik had er gewoon goed aan gedaan om een standaard library te kiezen (of ik hem nou mooi vind of niet), omdat ik dan "gratis" gebruik maak van het werk dat anderen stoppen in het onderhouden van die library.
Nu heb ik zelf een micro ORM library waarvan ik allang geen zin meer heb om die te onderhouden. Hij zit mij alleen maar in de weg. En dat is ook waar @Hydra op doelt. Dat veel programmeurs allemaal custom libraries bouwen door de jaren heen voor zaken waar dat helemaal niet nodig was geweest.
"hun eigen kleine koninkrijkje van shit"
Ik vond in 2009 dat nhibernate en EF veel te veel overhead gaven en wou iets simpelers. Dapper en veel andere micro ORM's waren er toen nog niet, dus ging ik mijn eigen micro ORM schrijven en door de jaren heen werden ook steeds meer projecten afhankelijk van die library.
Maar je kunt je dus ook afvragen waarom miljoenen programmeurs wél gewoon met nhibernate en EF uit de voeten konden en hun aandacht volledig konden richten op het bouwen van nieuwe functionaliteit voor hun werkgever. En waarom ik per se een eigen micro ORM moest schrijven.
Komt nog eens bij dat je een redelijk zware afhankelijkheid neemt op een bibliotheek waarvan je maar moet hopen dat de visie van de ontwikkelaars strookt met die van jou, nu en in de toekomst. Dit wil nog wel eens een heikel punt zijn.
Een simpele DB laag met ADO.net is misschien wel veel code, maar het is wel redelijk simpel. En niet simpel als in dat het dom is, maar meer dat het gemakkelijk te begrijpen is wat je code allemaal doet.
Een methode die een object persisteert naar een DB is redelijk te behappen, het gevaar schuilt hem er weer in dat als je dit vier keer hebt gedaan dat je gaat denken: "Dat kan ik ook wel generiek maken" dus dan krijg je ineens Store<T> en ga je allerlei dingen met reflection doen om de velden de uit te lezen zodat je on the fly het juiste db type kunt toewijzen.
Aan de andere kant, EF en andere ORMs zijn ook gewoon een zwarte doos en hetgeen dat ze pretenderen te doen, het relationele weghalen, gaat ook niet altijd op. Leaky abstractions enzo. DBcontexts die ineens overal opduiken etc. etc.
Zo kunnen we nog wel even doorgaan, IOC containers aspect oriented programming enz. enz.
Dus ja, hangt ervan af zeg maar.
[ Voor 87% gewijzigd door Sandor_Clegane op 23-09-2019 15:43 ]
Less alienation, more cooperation.
BaseManager<T> en in een latere versie EntityCollection<T> was het geworden:
Een methode die een object persisteert naar een DB is redelijk te behappen, het gevaar schuilt hem er weer in dat als je dit vier keer hebt gedaan dat je gaat denken: "Dat kan ik ook wel generiek maken" dus dan krijg je ineens Store<T> en ga je allerlei dingen met reflection doen om de velden de uit te lezen zodat je on the fly het juiste db type kunt toewijzen.
Maar inderdaad, je bouwt er steeds meer dingen bij om het jezelf makkelijker te maken... en vervolgens kom je erachter dat je in grote lijnen hetzelfde aan het bouwen bent als nhibernate of EF. Want er komt steeds iets nieuws bij. Change tracking bijvoorbeeld. Al mijn entities erven over van een BaseEntity en ik had ook al plannen ooit om met virtuele proxies te werken (met reflection.emit overerven van de entity en change tracking toe te voegen, zoals dat bij diverse ORM libraries gaat).
En tsja, R in ORM is ook zo'n dingetje. Dus voor je het weet, begin je alweer aan relaties vastleggen met attributes en ga je achter de schermen SQL generen met JOIN's zodat je classes kan vullen met N levels diep.
Allemaal zonde van de tijd...
Ask yourself if you are happy and then you cease to be.
Ach, dat weet ik niet, als je nHibernate had gedaan had je nu grote kans gehad dat je het naar EF moest ombouwen aangezien dat de zegen van MS heeft.
Alles is relatief zeg maar.
Denk dat het punt meer is dat je er niet aan ontkomt, voortschrijdend inzicht zeg maar. Maar belangrijk is ook dat je best kritisch mag blijven. Ik gebruik zelf Unity veel en ook daar kun je hetzelfde punt maken. Neemt niet weg dat doordat je op de "schouders van reuzen" staat je ook ver kan vallen.
Je moet je ook conformeren aan hun visie. Of dat al dan niet de juiste is, moet je voor jezelf uitmaken.
En dat is niet "gratis", goed je hebt er het werk niet van qua programmeren maar je moet je er wel weer in verdiepen en thuis in geraken.
Less alienation, more cooperation.
March 26, 2018:
[...]
Ach, dat weet ik niet, als je nHibernate had gedaan had je nu grote kans gehad dat je het naar EF moest ombouwen aangezien dat de zegen van MS heeft.
Alles is relatief zeg maar.
NHibernate 5.1 is released with the support of .NET Core 2.0 and .NET Standard 2.0.
May 8, 2019
EF 6.3 Preview supports .NET Core 3.0
Ik snap jouw punt van voortschrijdend inzicht wel, maar je ziet nu dus dat het in beide gevallen vanzelf goed was gekomen.
Met NHibernate zelfs sneller dan met EF
Maar om terug op het oorspronkelijke topic te komen... het enige dat frontend development zo eng maakt, is de snelheid waarmee alles verandert. Je hoopt gewoon dat als je nu een Angular of React frontend bouwt, dat het nog makkelijk 5 jaar mee kan, het liefst 10 jaar.
Dat kun je een eeuwigheid noemen, maar de meeste projecten waar ik aan werk, gaan makkelijk zolang mee
Ik werk nu alweer ruim 12 jaar voor dezelfde werkgever en bijna alles waar ik aan gewerkt heb - op een paar uitzonderingen na - wordt nog steeds dagelijks gebruikt.En ik haat het om dingen opnieuw te moeten bouwen.
Misschien moet ik dan niet zolang blijven plakken ergens, maar toch
Daarnaast kun je tegenwoordig steeds meer ermee. Dus potentiële Angular / React apps die je nu bouwt, vervangen misschien wel volledig Windows client applicaties met meer dan 100 schermen etc. Dan ben je rustig 2 a 3 jaar aan het bouwen voordat je die app überhaupt in een werkbare staat hebt.
Het zou jammer zijn als al dat harde werk al obsolete is, voordat je het überhaupt opgeleverd hebt.
[ Voor 46% gewijzigd door Lethalis op 23-09-2019 23:08 ]
Ask yourself if you are happy and then you cease to be.
/u/122874/crop5e26d7a209cd1_cropped.png?f=community)
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
/u/189240/av70.png?f=community)
EF Core 1.0 ondersteunde gewoon .NET Core hoor:
[...]
Met NHibernate zelfs sneller dan met EF
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Maar EF Core is een complete rewrite van EF die niet feature complete is.:
[...]
EF Core 1.0 ondersteunde gewoon .NET Core hoor
Ask yourself if you are happy and then you cease to be.
Bij de klant hier moeten we iets bouwen voor een ander team. Daar werd ons verteld dat we gewoon sowieso maar een 'dirty hack' moesten schrijven omdat, wat we ook opleveren, het sowieso weggegooid gaat worden.
Als ZZPer is het natuurlijk prima dat mensen graag enorm veel tijd en geld wegsmijten maar als software engineer zit ik hier regelmatig te facedesken.
https://niels.nu
Mijn voorganger heeft hetzelfde gedaan, maar dan nog weer eens gebruikmakend van EF:
[...]
Ik had er gewoon goed aan gedaan om een standaard library te kiezen (of ik hem nou mooi vind of niet), omdat ik dan "gratis" gebruik maak van het werk dat anderen stoppen in het onderhouden van die library.
Nu heb ik zelf een micro ORM library waarvan ik allang geen zin meer heb om die te onderhouden. Hij zit mij alleen maar in de weg. En dat is ook waar @Hydra op doelt. Dat veel programmeurs allemaal custom libraries bouwen door de jaren heen voor zaken waar dat helemaal niet nodig was geweest.
"hun eigen kleine koninkrijkje van shit"
Ik vond in 2009 dat nhibernate en EF veel te veel overhead gaven en wou iets simpelers. Dapper en veel andere micro ORM's waren er toen nog niet, dus ging ik mijn eigen micro ORM schrijven en door de jaren heen werden ook steeds meer projecten afhankelijk van die library.
Maar je kunt je dus ook afvragen waarom miljoenen programmeurs wél gewoon met nhibernate en EF uit de voeten konden en hun aandacht volledig konden richten op het bouwen van nieuwe functionaliteit voor hun werkgever. En waarom ik per se een eigen micro ORM moest schrijven.
Denk je dat je tegen EF praat, blijkt het uiteindelijk toch een ander framework te zijn.
:strip_exif()/u/591794/crop61a251d10f7b3.gif?f=community)
En anders wacht je even en dan is er weer een nieuw Frameworkje du jour for the job.
Less alienation, more cooperation.
Enigszins uit context, maar veel moderne JavaScript libraries vermelden IE11 niet eens meer als ondersteunde browser op hun github pagina's. Ergens ook wel terecht. Het is gewoon jammer dat er nog zoveel mensen zijn in het bedrijfsleven die het per se willen gebruiken.
Al was ik wel blij toen het uitkwam voor Windows Server 2012 recentelijk, omdat we nog klanten hadden die op IE10 vastzaten
Ik ben er als de dood voor, eerlijk gezegd:
[...]
Wat denk je zelf?
Aan de ene kant ben ik een voorvechter van webapplicaties en zie ik het als de enige toekomstbestendige oplossing, aan de andere kant is web development een soort Vietnam geworden waarbij elke stap die je zet, de verkeerde kan zijn.
Hoe langer de doorlooptijd van het beoogde project, hoe enger het wordt.
Ja irritant is dat.
Soms zoek ik naar diepgaandere informatie over iets, en dan krijg ik op 20 verschillende blogs hetzelfde Hello World voorbeeld van 1 of andere hipster met een baard en zijn MacBook
I'm getting too old for this shit. En ik ben pas 38.
Ik hou ook mijn hart vast voor als ik ooit weer moet solliciteren... al die bedrijven die hip proberen te zijn. En dan zie je een foto van een kantoor met een knalrode muur (waar ik agressief van word) met 1 of andere slogan er op en het jaarlijkse Ski uitje met de zaak
Dingen waar ik echt 0,0 om geef. Maar goed, dat even terzijde
Mijn online "aanwezigheid" is ook minimaal. Ik ben gestopt met Facebook en dergelijke. Geen zin om een cover life te fabriceren om "interessant" te lijken en mezelf af te trekken op de likes die ik krijg.
[ Voor 78% gewijzigd door Lethalis op 25-09-2019 22:03 ]
Ask yourself if you are happy and then you cease to be.
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
Het verbaast me niet eerlijk gezegd.
Ik volg het hele .NET Core traject al een tijdje sinds versie 1.0. Volgens mij vergaderen ze daar meer dan ze programmeren en dan krijgen ze het nog voor elkaar om rare beslissingen te nemen over zo ongeveer alles.
Heb meerdere keren van die momenten gehad dat ik het niet meer zag zitten en erover nadacht om maar iets anders te leren dan de Microsoft stack.
Inmiddels gaat het wel weer... maar pfff.
Ik heb overigens op diverse blogs EfBe zijn rants regelmatig voorbij zien komen over .NET Core
[ Voor 18% gewijzigd door Lethalis op 25-09-2019 23:42 ]
Ask yourself if you are happy and then you cease to be.
Hahaha, dat heb ik nu ook. Ik heb echt het idee dat het in hun DNA zit om defeat uit de jaws of victory te snatchen.:
[...]
Het verbaast me niet eerlijk gezegd.
Ik volg het hele .NET Core traject al een tijdje sinds versie 1.0. Volgens mij vergaderen ze daar meer dan ze programmeren en dan krijgen ze het nog voor elkaar om rare beslissingen te nemen over zo ongeveer alles.
Heb meerdere keren van die momenten gehad dat ik het niet meer zag zitten en erover nadacht om maar iets anders te leren dan de Microsoft stack.
Inmiddels gaat het wel weer... maar pfff.
Ik heb overigens op de .NET developer blogs EfBe zijn rants regelmatig voorbij zien komen
HTTPlistener is ook zo'n mooi voorbeeld.... "Neem maar kestrel"
Het is ook de reden dat ik niet de HTTP client gebruik. Ja het is ruk, maar ik maak liever zelf mijn requests dan dat een exception in een gedeelde client alle uitstaande async awaits opdoekt omdat het onderliggende object ergens een exception heeft gehad.
Maar ja, dat F#......
Less alienation, more cooperation.
Herkenbaar.
Hetzelfde nu met de GRPC support in .NET Core. Ze stoppen superveel effort in het ondersteunen van het ding in ASP .NET Core. Ze implementeren de helft van de features.
Dan stoppen ze wel veel effort in het stroomlijnen van het ASP.NET Core gedeelte (waarom niet gewoon op .NET Core laten werken, waarom moet die ASP stack erin gevouwen worden? Ik wil GRPC niet hosten in IIS, waarom zou ik.)
En de andere helft van de effort zit in het native in CLR ondersteunen van grpc, ipv de onderliggende C lib te gebruiken. Die redenatie kan ik nog een beetje volgen, maar ook dat gaat op termijn weer subtiele implementatieverschillen veroorzaken, weet ik nu al.
Kijk, gelukkig draaien wij single stack (.NET), dus maakt het mij niet zoveel uit. Maar je zult maar multi-stack zijn en rare subtiele bugs krijgen in je infrastructuur libraries.
[ Voor 24% gewijzigd door Grijze Vos op 26-09-2019 14:08 ]
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Weet je wat ik eigenlijk nog vervelender vind? Dat ze bij zo ongeveer alles ervan uitgaan dat je EF gebruikt. Zo ook met ASP.NET Identity en IdentityServer4.
Ik moet een goede authenticatie en autorisatie flow bouwen voor een SPA en ik heb geen zin het wiel opnieuw uit te vinden.
Dus neig ik gewoon naar het gebruiken van IdentityServer4 met OAuth2 en PKCE. Maar ik wil geen EF rommel erbij
Als ik dan weer zie wat voor een gedoe dit allemaal is om het zonder EF te doen pfff.
Natuurlijk kan ik ook de boel omzeilen door zelf JWT tokens te genereren, maar dan krijg je dus met allerlei security concerns te maken waarvan het juist fijn is als die door een standaard library worden afgevangen.
Want zelf JWT access tokens maken, komt in grote lijnen met een Implicit Grant flow overeen met ditto security concerns. Refresh tokens mogen dan eigenlijk zelfs niet eens
/einde rant
Tot zover "even snel" authenticatie integreren in mijn SPA. Ik begin mijn cookies te missen (die overigens nog wel vaak worden gebruikt icm tokens zie ik op diverse blogs, dan wel met HttpOnly, secure etc).
Als iemand nog tips heeft, zijn ze welkom
Time is not on my side...
Sterker nog, ze zijn een eigen JSON library aan het bouwen, terwijl iedereen gewoon NewtonSoft gebruikt.
Allemaal voor een klein beetje extra performance... maar weet God hoeveel compatibiliteit issues dit weer gaat opleveren.
[ Voor 11% gewijzigd door Lethalis op 29-09-2019 11:50 ]
Ask yourself if you are happy and then you cease to be.
/u/9441/def.png?f=community)
"When I am weaker than you I ask you for freedom because that is according to your principles; when I am stronger than you I take away your freedom because that is according to my principles"- Frank Herbert
Wij generaten idd zelf JWT tokens en stoppen die in een cookie. Moet eerlijk zeggen dat ik het niet gebouwd heb en er vrij weinig van weet. Heb alleen de implementatie as is netjes weggewerkt in onze nieuwe .NET Core architectuur nadat mijn collega het gebouwd had.:
[...]
Tot zover "even snel" authenticatie integreren in mijn SPA. Ik begin mijn cookies te missen (die overigens nog wel vaak worden gebruikt icm tokens zie ik op diverse blogs, dan wel met HttpOnly, secure etc).
Als iemand nog tips heeft, zijn ze welkom
Time is not on my side...
Wij moesten wel integreren met onze oude zooi, dus we zetten sowieso twee cookies op het moment, voor beiden implementaties.
Dat doen ze al, die dude werkt voor MS. Vaag dat ze het opnieuw bouwen. Verbeter dan gewoon Newtonsoft.Json, desnoods breng je het onder in een MS namespace.
[ Voor 20% gewijzigd door Grijze Vos op 29-09-2019 20:17 ]
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Daar voldoen ze al een tijdje niet meer aan.
Sterker nog, open source is een manier voor ze om juist steeds meer dingen af te stoten. Daarom verbaast het mij ook dat ze soms alsnog weer iets zelf gaan doen, zoals die JSON library.
Een groot bedrijf als Microsoft denkt simpelweg door de community bij een project te betrekken, dat ze dan met minder mensen in dienst bepaalde producten in leven kunnen houden. Als je op github kijkt wie er dan commit, dan is het ook nog eens vaak een intern.
Ook al wil je graag een eigen ORM oplossing aanbieden, dan nog is het handig als je klanten / gebruikers de mogelijkheid geeft om er aan te knopen wat je maar wil.
Nu kan dat met IdentityServer ook, maar Microsoft documenteert dat scenario niet / nauwelijks. Alle voorbeelden gebruiken EF. Dus als jij geen EF maar NHibernate of Dapper wil gebruiken, dan moet je het van de community hebben en eindig je al snel op iemand zijn blog die dan een artikel schrijft met een enorm stappenplan dat je denkt van "really? voor zoiets simpels?".
Microsoft duwt EF door je strot met zo ongeveer alles dat je wil doen. Sowieso is een nieuw ASP.NET Core project maken een mijnenveld. Ik kies altijd voor een Empty Project template, en voeg dan elk dingetje dat ik wil handmatig toe... anders krijg ik er een berg zooi bij waar ik helemaal niet op zit te wachten. Van uitgebreide telemetrie, EF, tot en met allemaal JavaScript en bootstrap libraries waarvan ik helemaal niet wil dat Visual Studio die beheert.
Ach ja.
Hoe doen jullie dan sessie management?
Stel je genereert een JWT token, dan verloopt deze meestal na 10 tot 15 minuten. Als gebruikers actief bezig zijn met jouw SPA, is het niet handig als ze ineens opnieuw moeten inloggen. Dus dan zul je automatisch een nieuw access token moeten aanvragen, met bijvoorbeeld een refresh token.
Maar zodra iemand een refresh token bemachtigt, kan hij oneindig nieuwe tokens aanvragen... dus dat is een vrij nasty scenario als daar geen extra beveiliging op zit.
Of gaan jullie zover als sommige voorbeelden die ik gezien heb, dat elke gelukte request naar een API ook automatisch een nieuw token oplevert? Dat voelt heel wrang voor mij ergens (het mixen van 2 verantwoordelijkheden).
Al met al vind ik de gedachte achter een aparte IdentityServer die als authority fungeert voor het uitdelen en valideren van tokens wel iets hebben, omdat je dan 1 duidelijke afgebakende functie hebt op 1 plek. Bovendien met een beperkte attack surface.
PS
Wat ik wil, lijkt met een eigen implementatie van IResourceOwnerPasswordValidator te kunnen:
https://www.linkedin.com/...4-using-owner-dalvandi-2/
Ik ga er nog een tijdje mee verder spelen. Zou natuurlijk prima een class kunnen maken die IResourceOwnerPasswordValidator implementeert en bijvoorbeeld met Dapper de juiste gegevens erbij haalt.
Schijnt onveilige methode te zijn
Ach ja. Next."The Resource Owner Password Flow is rarely the recommended approach. It is intended for applications for which no other flow works"
Ik moet er echt rustig voor gaan zitten en het allemaal gaan uitzoeken... meh. Ook fijn dat er blijkbaar mensen zijn die het gewoon implementeren en het verder prima vinden. Er zelfs een hele blog post op LinkedIn aan wenden.
[ Voor 30% gewijzigd door Lethalis op 29-09-2019 21:37 ]
Ask yourself if you are happy and then you cease to be.
/u/313216/crop679f937b7f4c1_cropped.png?f=community)
/u/454206/crop562d2ccb2479a.png?f=community)
Ik heb hier weken voor aan de eetkamer tafel gezeten. Nagedacht hoe het hedendaags zou moeten zijn of gaan. Geconstateerd dat het veel gebruikt wordt zoals voorbeeld projecten het hebben (aka. Hello World).
Ik heb er teveel tijd aan verspilt imho. voor een Symfony backend applicatie. Ik sta nu op het punt om de voorkant te programmeren met React.
Ik gebruik om die reden de refresh token in zijn geheel niet. Bij het genereren van de token gebruik ik `RS256` en ziet mijn token er zo uit:
code:
De 0 bij exp is met opzet voor dit voorbeeld omdat de geldigheid per environment aangepast kan worden (staging en testing CI hebben bijv. dynamic values) maar die is in de backend: `time() + (60 * 60 * $this->jwtTtl),`. Vraag mij niet waarom ik voor 168 uur (7 dagen) heb gekozen. Ik wilde in eerste instantie de gebruiker niet lastig vallen met opnieuw inloggen maar ik kan er nog voor kiezen om het IP adres te koppelen aan de token (een node _ipAddress_ in de token should do the job) en als die niet overeenkomt moet je gewoon opnieuw inloggen of naast een ip adres de user agent erin zetten?! (Misschien ab-testen in de toekomst, als ik ooit een doel vind voor deze applicatie). In de backend wordt bij iedere request de token gesjeckt. Is het nog geldig? De standaard shizzle. Kan ik met de private key de token decrypten? In de SPA zal ik vervolgens de public key gebruiken (per environment) om vervolgens ook te controleren of er niet gerommeld is met de token.1
2
3
4
5
6
| {
"iat": 1569791543,
"nbf": 1569791543,
"exp": 0,
"sub": "gebruiker@bedrijfsdomein.nl"
} |
En uiteraard (want dat gaat gebeuren
) zijn er developers hier in dit draadje die het niet eens zullen zijn met mijn aanpak maar vooralsnog zie ik geen betere oplossing Ik wil niemand, maar dan ook niemand, dit adviseren te implementeren in welke applicatie dan ook. I rather shoot myself in the foot.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
"When I am weaker than you I ask you for freedom because that is according to your principles; when I am stronger than you I take away your freedom because that is according to my principles"- Frank Herbert
"zoals het hoort" is meestal een tijdelijk begrip
Daarom loop ik hier ook nog steeds mee te kutten na 16 jaar als programmeur gewerkt te hebben
Dit is eigenlijk al een apart topic waard.
Ask yourself if you are happy and then you cease to be.
Ja dat begrijp ik inderdaad:
[...]
"zoals het hoort" is meestal een tijdelijk begrip
Daarom loop ik hier ook nog steeds mee te kutten na 16 jaar als programmeur gewerkt te hebben
Dit is eigenlijk al een apart topic waard.
Ik heb het nu zo geleerd, dat probeer ik dan ook te doen, maar ik probeer wel zo veel mogelijk kwaliteit te leveren, hoewel dat niet altijd lukt. Bijvoorbeeld Google + Microsoft authorization mogelijk maken, terwijl je Angular moet gebruiken, maar dan ook wilt authenticeren op de eigen server.
Ik heb het werkend, maar niet mooi Je blog ga ik doorlezen!
Verder, een applicatie die een backend heeft van C# en de frontend Angular. Dan zijn het technisch gezien twee applicaties toch? Of spreek je dan nog steeds van Monolitisch? Monolitisch lijkt mij als je maar 1 groot blok hebt toch? Dus gewoon C# met MVC Core bijvoorbeeld, waarbij alles door elkaar heen is gehutseld?
[ Voor 40% gewijzigd door Jantje2000 op 30-09-2019 10:12 ]
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
Zit ook serieus te overwegen hier een nieuwe blogpost over te schrijven. I.p.v. over de techniek over de architectuur.
Cool! Feedback/vragen zijn altijd welkom
Ik heb het over de back-end; dus dat het gewoon 1 service is. De front-end heeft hier weinig mee te maken.
[ Voor 53% gewijzigd door Hydra op 30-09-2019 10:16 ]
https://niels.nu
Tja, ik ben het nu nog vooral aan het leren. Ik zit in het derde jaar op een hbo-opleiding, dus als ik blijkbaar een foute keuze heb gemaakt wijzig ik dat graag, zodat ik het de volgende keer gelijk goed kan doen
.Ik ben nu even aan het kijken naar de linkjes die Lethalis stuurde, en nog even aan het uitzoeken wat beter aan miin doel beantwoord, dus ik ben benieuwd wat daar uit komt.
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
Wil je nu dat ik een heel lijstje ga opsommen? Je zet het zelf heel zwart wit hier dat het enige voordeel van JWT is dat het je login service ontlast en dat is gewoon niet zo.
Ik zou zeggen, zet je tunnel-visie tegen JWT aan de kant
JWT is gewoon net zoals alles, pick the right tool for the job. Ik heb menig site ontwikkeld waar intrekken van een sessie totaal niet aan de orde is maar wel graag een horizontaal schaalbare REST api wilden hebben dan kan JWT handig zijn, helemaal als je gebruik kan maken van bestaande componenten
Doe niet zo raar zeg. Ik stel je gewoon een vraag? Jij weet kennelijk iets wat ik niet weet, dus ik hoop uit te vinden of ik een blinde vlek heb of niet.
Okay, WTF? Ik zeg letterlijk dat ik het toegepast heb. Heb er n.b. een blog post over geschreven, en dat doe je volgens mij niet als ik er iets 'tegen' heb ofwel?Ik zou zeggen, zet je tunnel-visie tegen JWT aan de kant
Je zegt hier letterlijk wat ik zeg, maar heb nog steeds niet uitgelegd welke voordelen er nu meer zijn naast schaalbaarheid.
[ Voor 44% gewijzigd door Hydra op 30-09-2019 12:52 ]
https://niels.nu
/u/715027/crop6047c50ae8d4c.png?f=community)
Je komt een beetje anti-JWT over vandaar
Je zegt zelf ook "JWTs zijn een oplossing voor een enkel probleem: we hebben een 'login' service die het te druk heeft om elk request te kunnen beoordelen."En dat is niet waar in mijn ogen, het is namelijk heel iets anders dan het horizontaal schalen van een REST service, dankzij JWT heb je geen shared sessie of DB met guid's nodig. Dat kan een keuze zijn, los van het te druk hebben. Ook wil je het stuk authenticatie misschien niet bij je API hebben liggen maar bijvoorbeeld bij een SSO provider zoals Auth0 of ADFS
Dat dacht ik ook, maar in de Google Cloud Console staan er: "OAuth 2.0-client-ID's" en "Oauth toestemmingsscherm" wat beiden over het externe inloggen gaat. Zie ik iets over het hoofd?:
[...]
Dat is OpenID Connect
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
Dat is niet dankzij JWT. JWT is namelijk niets anders dan een token formaat. Het kan ook heel goed zonder JWT, bijvoorbeeld door een ander token formaat te gebruiken. Wat je daarvoor nodig hebt is een authenticatie protocol, en dat is JWT niet.:
[...]
Je komt een beetje anti-JWT over vandaar
En dat is niet waar in mijn ogen, het is namelijk heel iets anders dan het horizontaal schalen van een REST service, dankzij JWT heb je geen shared sessie of DB met guid's nodig. Dat kan een keuze zijn, los van het te druk hebben. Ook wil je het stuk authenticatie misschien niet bij je API hebben liggen maar bijvoorbeeld bij een SSO provider zoals Auth0 of ADFS
IMHO is het meer een stukje architectuur. Het exacte formaat is m.i. niet zo relevant (hoewel je natuurlijk gewoon voor een standaard gaat) als welke problemen het oplost en welke problemen het veroorzaakt. Je kunt, als je zelf de client en services bouwt, precies hetzelfde doen met een 'eigen' formaat. Op basis van XML ofzo
XWT
https://niels.nu
Ja, angular heeft ook mijn voorkeur inderdaad, omdat ik dan het meest nieuw leer.
OAuth laat ik nu inloggen, door de gebruiker na een klik op de button, een popup te geven die via de server naar Google redirect. Dan log je in, waarna de server jouw oauth gegevens ontvangt. Op basis van die gegevens verstrek ik een jwt token aan de client, waarna de client daarbij kan blijven authenticeren
Api bouwen met .Net Core is heel erg gemakkelijk, het lastigste blijft de authenticatie
. Dat moet gelijk goed gebeuren
[ Voor 4% gewijzigd door Jantje2000 op 30-09-2019 16:02 ]
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
Prima toch?
Wel nog even netjes de expiry op 10m zetten ofzo en de client laten refreshen maar dan ben je er volgens mij al.
https://niels.nu
Ja, ik wist niet 100% zeker of dit een nette oplossing was. Het voelde een beetje hacky:
[...]
Prima toch?
.Als ik dan dus laten expiren na 10 minuten, heb je dan ook nog weer speciale refreshtokens nodig? En zou jij een ander token dan jwt aanraden, of maakt dat ook weer niet heel erg veel uit?
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.