Archief - De koffiepauzehoek
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
adrianhates
Legacy Member
Dieterg zei:Ik zie het toch wel wat anders..
Om een voorbeeld te geven: Bij mijn vorige projecten begon ik altijd van de back-end naar de front-end te werken. Eerst zorgen dat de database etc in orde was.
Nu met (bv.) AngularJS begin ik aan de front-end, als data maak ik gebruik van JSON-Objecten. Als de front-end klaar is begin ik aan de back-end, bijvoorbeeld een REST Client. Die REST client kan dan gebruik maken van de front-end JSON objecten die ik doorstuur of afhaal. Zo is server side taal en client side taal 100% gescheiden, geen rommelcode meer. Er is orde aan zowel de client als aan de serverkant. Ik zie ook dat ik nu minder lang bezig ben geweest aan dit project én een pak minder code!!
Een REST client heeft dan ook nog eens het voordeel dat er snel een ander soort applicatie aan kan toegevoegd worden zonder dat er iets aan de back-end moet veranderen.
AngularJS voelt imo zeer natuurlijk aan, als ik met jQuery/puur javascript bezig ben heb ik steeds het gevoel dat ik aan het 'hacken' ben.
om eerlijk te zijn ben ik ook (onbewust) naar die methodologie aant shiften. Misschien ook omdat men thesis puur HTML5 en JavaScript betreft
tegenwoordig heb je met echt belachelijk weinig werk een goeie RESTful service opgezet. Wat niet wegneemt dat de backend logica en database design nog steeds een grote brok blijven. Wat me vroeger tegenhield was de JavaScript onzekerheid, maar dat mensen "mogelijks hun javascript afzetten" kan mij tegenwoordig gestolen worden.
W0utR
Legacy Member
Ik ben momenteel bezig met een applicatie om te zetten in Ember.js, kwestie van het wat te leren.
Applicatie was vroeger geschreven in PHP en een hele hoop javascript code die onmogelijk nog te onderhouden is, nu, wat zouden jullie qua backend aanraden? Ik was aan het denken om het in node.js te doen, maar andere suggesties zijn altijd welkom.
Applicatie was vroeger geschreven in PHP en een hele hoop javascript code die onmogelijk nog te onderhouden is, nu, wat zouden jullie qua backend aanraden? Ik was aan het denken om het in node.js te doen, maar andere suggesties zijn altijd welkom.
Dieterg
Legacy Member
ExpressJS: framework gebouwd bovenop Node.
Of ik vind webapi 2.0 (.NET) ook leuk om mee te werken.
Node/express is heel leuk maar kheb nog moeite met het structureren van men project. Net zoals dat ik dat ook had met oude javascript projecten.
Verstuurd vanaf mijn GT-I9300 met Tapatalk 4
Of ik vind webapi 2.0 (.NET) ook leuk om mee te werken.
Node/express is heel leuk maar kheb nog moeite met het structureren van men project. Net zoals dat ik dat ook had met oude javascript projecten.
Verstuurd vanaf mijn GT-I9300 met Tapatalk 4
Moto
Legacy Member
node.js is wel leuk en dan kunt ge gaan voor het traditionele Express framework
iets waar ge veel mensen hoort over klagen is het programmeren met al die callbacks, en de makers van Express zijn begonnen aan een ander framework waar men dus niet meer met callbacks hoeft te werken namelijk koa
Koa - next generation web framework for node.js
Ik vind het vooral fijn om kleinere sites mee op te zetten boven op een mongodb, grootste nadeel voor intranet applicaties is dat ik geen automatisch windows authentication (kerberos) kan doen zoals bij IIS/ASP.net
Dus voor de meeste intranet apps gebruik ik nu een C# backend onder IIS met ServiceStack.Rest en Linq2Db
Ge kunt ServiceStack altijd vervangen door het iets mindere WebApi, maar qua ORM komt niks in de buurt van Linq2Db
Vind daar nu meestal niks aan, ik snap niet hoe daar veel tijd voor nodig is tov UI
Shaddix
Legacy Member
Met die javascriptframeworks moet er toch altijd wat opgepast worden. Soms wordt het alleen maar gebruikt omdat het zo'n buzztopic is geworden. Onlangs hoorde ik van een e-shop die amper in google werd opgenomen. De ontwikkelaar bevestigde "ja met zo'n javascript framework is het moeilijk meer dan 1 page te laten indexeren door Google" 
bealzebub
Legacy Member
Als je dan toch voor Node zou gaan raad ik Sails als framework aan. Ondersteunt zowel REST API als Websocket API. REST en request-response based socket calls krijg je gewoon out of the box, pubsub is een paar extra regels code.
Sails is trouwens een framework bovenop Express, dus je kan er indien nodig gewoon middleware van Express tussen steken. Voor de frontend code gebruikt het Grunt, dus ook daar kan je de defaults van het framework makkelijk vervangen door iets anders (Angular, Ember, …
. Voor de rest krijg je echt wel veel: router, orm, policies (authorization), …
Pas in ieder geval op met MongoDB. Het is zeker geen slechte NoSQL db en enorm populair, maar wij hebben er al stoten mee tegengekomen die minder aangenaam zijn eens je met veel data zit: corrupte db, memory usage die alle verbeelding tart (mongo neemt gewoon wat ie kan pakken), … Transacties bestaan als dusdanig ook niet in Mongo, je hebt enkel atomic operations op één document. Durability is ook iets wat je expliciet moet aanzetten (journaling) en staat niet helemaal op punt ook. Als je mongo visueel moet voorstellen is het een bak waar je losweg dingen ingooit en waar je ervan uitgaat dat het er wel in zal zitten. Als een document-based storage is het wel een goeie keuze, maar eens je met complexere relaties waar joins een betere piste zijn laat je het beter links liggen.
Sails is trouwens een framework bovenop Express, dus je kan er indien nodig gewoon middleware van Express tussen steken. Voor de frontend code gebruikt het Grunt, dus ook daar kan je de defaults van het framework makkelijk vervangen door iets anders (Angular, Ember, …
. Voor de rest krijg je echt wel veel: router, orm, policies (authorization), …Pas in ieder geval op met MongoDB. Het is zeker geen slechte NoSQL db en enorm populair, maar wij hebben er al stoten mee tegengekomen die minder aangenaam zijn eens je met veel data zit: corrupte db, memory usage die alle verbeelding tart (mongo neemt gewoon wat ie kan pakken), … Transacties bestaan als dusdanig ook niet in Mongo, je hebt enkel atomic operations op één document. Durability is ook iets wat je expliciet moet aanzetten (journaling) en staat niet helemaal op punt ook. Als je mongo visueel moet voorstellen is het een bak waar je losweg dingen ingooit en waar je ervan uitgaat dat het er wel in zal zitten. Als een document-based storage is het wel een goeie keuze, maar eens je met complexere relaties waar joins een betere piste zijn laat je het beter links liggen.
dJeez
Legacy Member
Waar heb ik dat nog gelezen? Retorische vraag overigens, je komt die - terechte - kritiek enorm veel tegen op het netbealzebub zei:
.Maar heeft er iemand ervaring met Graph DBs, dus dingen zoals OrientDB? Dat lijkt mij nl. de perfecte match voor dat probleem (best of both worlds). In hoeverre het de verwachtingen ook kan inlossen is echter een andere zaak (heb er nog niet mee gespeeld, maar zou dat wel eens willen doen
).bealzebub
Legacy Member
Moto zei:
Wij wisten wel waaraan we begonnen, er waren zelfs uitvoerige stack tests vooraf gedaan. De toepassing waar het om draait is ook een NoSQL schoolvoorbeeld: documentgestructureerde data, geen joins, geen nood aan transacties, nood aan snelheid. Ik meen toch te mogen zeggen dat wij goed weten waarmee we bezig zijn en dat elke keuze van technologie eentje is waar we met een onderbouwde redenering voor gekozen hebben.
Nu, bijna alles wat ik zeg wordt gewoon rechtuit op de mongodb site vermeld: FAQ: MongoDB Fundamentals ? MongoDB Manual 2.4.8
Zolang je met weinig data zit is corruptie zelfs geen zo'n groot probleem, de recover functie werkt echt wel naar behoren. Eens je met een dataset zoals de onze zit (een catalogus om u tegen te zeggen) duurt een recover een halve dag. Je moet gewoon voor een mission critical app redundancy/replication voorzien, want corruptie kan optreden door factoren die niets met kennis van technologie of fout gebruik te maken hebben. De meest gekende is wanneer je een electriciteitspanne hebt en de mongodb niet correct wordt afgesloten, maar da's verre van het enige. Anyway, replicatie vangt dat probleem op, maar voor grotere projecten hangt daar een aanzienlijk prijskaartje aan vast. Durability is gewoon een issue en je zorgt er best voor dat je daar de nodige maatregelen voor treft als dat belangrijk is voor je app.
Mongo heeft z'n succes vooral te danken aan het feit dat het zo simpel is. En nogmaals, ik zeg niet dat je Mongo niet moet gebruiken. De andere opties waren CouchDB of Cassandra geweest maar die hadden dan weer andere nadelen. Zouden we vandaag een andere keuze maken… da's een moeilijke vraag… Bij problemen zeggen we ieder keer van wel, maar op andere momenten plukken we wel de vruchten van onze keuze (zelfs onder massive load blijft mongo gewoon snel).
Mongo is eigenlijk een beetje een puber: enorm dynamisch en wild enthousiast, maar soms zou je hem eens een goeie lap rond z'n oren willen geven als ie weer eens zonder nadenken zichzelf in de miserie heeft gestoken. Maar er is hoop, mongo is stillekesaan volwassen aan t worden en die puberstreken zullen dus mettertijd wel verdwijnen. Elke new kid on the block heeft trouwens dat probleem, en elke ouwe rot heeft dan weer het probleem dat ie naast uiterst betrouwbaar ook een beetje vastgeroest zit en alles wa minder rap gaat.
Moto
Legacy Member
Dit is dan ook een ander verhaal dan in uw voorgaande post die begon met "maar wij hebben er al stoten mee tegengekomen ... . .. Transacties bestaan als dusdanig ook niet in Mongo, je hebt enkel atomic operations op één document "
maar had het eigenlijk ook over de vele kritische posts tegen mongoDb op bv hacker news, waar veel punten die ze aanhalen hun eigen fout is.
Bij het switchen tussen relationele databases voor deftige projecten zult ge u in veel gevallen ook eerst moeten informeren naar de specifieke implementatie / technische verschillen.
nogal logisch dan dat wanneer ge van een relationele naar een in-memory document-db gaat ook eerst eens wat artikels leest
bealzebub
Legacy Member
Moto zei:nogal logisch dan dat wanneer ge van een relationele naar een in-memory document-db gaat ook eerst eens wat artikels leest
Alleen is mongodb geen inmemory db
Het heeft een inmemory cache, maar da's verre van een inmemory db. Nu goed, we zijn hier aan het nitpicken over terminologie.Redis daarentegen is bv. echt wel inmemory met persistence via interval/treshold (waarbij je gaat instellen wat de verschillende tresholds voor persistence zijn). Wij gebruiken redis bv voor session en websocket management in een geclusterde nodejs omgeving zodat die gedeeld kunnen worden over de verschillende instances. Dat is ook één van de toepassingen waarvoor redis een heel goeie oplossing is.
W0utR
Legacy Member
Man man, begin het hier stillekes aan moe te worden op het werk (allez, ben het al 3 maand lang moe), de persoon die zichzelf designer noemt doet dus eigenlijk niet meer dan foto's aanpassen en uitvoeren in illustrator wat andere mensen vragen.
Als hij zelf iets moet designen is het ronduit lelijk of krijgt hij zoveel commentaar dat het er na 5 dagen wat deftig uitziet.
'T is natuurlijk wel zo iemand die met iedereen overeenkomt omdat hij iedereen altijd gelijk geeft, hij heeft dus totaal geen eigen mening, als één van de managers een suggestie heeft zal hij er altijd mee akkoord gaan, als ik een suggestie geeft ook, als iemand buiten ons team iets zegt gaat hij ook akkoord.
Vanaf ik dat doorhad begon ik mij daar totaal aan te ergeren, het ergste vanal is dat hij gewoon ongeloofelijk traag is, images exporteren duurt vaak uren terwijl ik zoiets op 5 minuten kan doen.
Aangeleverde mockups zijn gewoon .jpg files en ik mag dan maar uitzoeken welke fonts en kleuren hij gebruikt. (en het gaat er niet in dat dit gewoon puur tijdverlies is, maarja dat zijn gewoontes van voordat ik hier was ...)
Hetzelfde probleem met schrijven, teksten nalezen? Dat zullen we wel doen als alles op staging staat. Final copy aanleveren? Waarschijnlijk een uurtje voordat de deadline is.
Maar goed, hetgene dat ik nu geleerd heb op 8 maand, word nooit in-house developer, de meeste mensen zijn echt dom en leveren slecht werk.
</rant>
Als hij zelf iets moet designen is het ronduit lelijk of krijgt hij zoveel commentaar dat het er na 5 dagen wat deftig uitziet.
'T is natuurlijk wel zo iemand die met iedereen overeenkomt omdat hij iedereen altijd gelijk geeft, hij heeft dus totaal geen eigen mening, als één van de managers een suggestie heeft zal hij er altijd mee akkoord gaan, als ik een suggestie geeft ook, als iemand buiten ons team iets zegt gaat hij ook akkoord.
Vanaf ik dat doorhad begon ik mij daar totaal aan te ergeren, het ergste vanal is dat hij gewoon ongeloofelijk traag is, images exporteren duurt vaak uren terwijl ik zoiets op 5 minuten kan doen.
Aangeleverde mockups zijn gewoon .jpg files en ik mag dan maar uitzoeken welke fonts en kleuren hij gebruikt. (en het gaat er niet in dat dit gewoon puur tijdverlies is, maarja dat zijn gewoontes van voordat ik hier was ...)
Hetzelfde probleem met schrijven, teksten nalezen? Dat zullen we wel doen als alles op staging staat. Final copy aanleveren? Waarschijnlijk een uurtje voordat de deadline is.
Maar goed, hetgene dat ik nu geleerd heb op 8 maand, word nooit in-house developer, de meeste mensen zijn echt dom en leveren slecht werk.
</rant>
Albireo
Legacy Member
adrianhates zei:
Ik vroeg me zo af, als jullie het over REST hebben, hoe ziet dat er dan uit in de praktijk? Als ik een formulier via ajax naar een Generic Handler (ASP.NET) stuur die alles in een database zet en op een andere pagina een andere Generic Handler aanroep die alles uit de database haalt en via JSON naar m'n pagina stuurt ben ik dan RESTful bezig???
Als ik de Wikipedia pagina zo lees, is niet elke webapplicatie RESTful (tenzij die sessions gebruiken)?
bealzebub
Legacy Member
REST is een redelijk wijd en eigenlijk in webdevelopment termen al een oud concept en het is breder dan alleen maar webservices, maar daarvoor is het wel het meest gekend.
De opkomst van REST heeft veel te maken met de voordelen die het kan bieden: het schaalt makkelijk, het is een stuk compacter en performanter dan bv. SOAP en het past perfect in het plaatje van de meeste serverside MVC frameworks en HTTP en ook de frontend frameworks zoals Backbone of Ember kunnen makkelijk RESTful conventies automatiseren. Het is immers makkelijk om bv uit "GET /companies/123.json" af te leiden dat je het bedrijf met ID 123 wil uit de database halen en als JSON wil weergegeven zien.
REST heeft op zich niets met sessions te maken, ze worden zelfs dikwijls zonder sessions maar bv. via een API key in de header aangesproken. In tegenstelling tot SOAP is het ook geen protocol maar eerder een bepaalde architectuur, omdat het geen officiële standaard is. Het protocol om REST over te transporteren is HTTP(S). Daarom is het ook moeilijk om precies uit te leggen hoe een RESTful protocol er precies uitziet, je kan dat zelf beslissen, zolang het maar de principes van REST gebruikt.
Een van de meest belangrijke principes is dat je "resources" gaat exposen via een unieke identifier, bij HTTP de URL. Het manipuleren van die resources gebeurt via de mogelijkheden van een standaardinterface. De representatie is ook iets wat meegegeven wordt via het onderliggend protocol. Dat kan als extensie (resource.json) of via een Accept header (application/json). Dat moet ook niet noodzakelijk JSON of XML zijn, alhoewel die het populairst zijn. Dat kan bij wijze van spreken perfect HTML, SVG, CSV of zelfs PDF zijn.
Een mogelijke REST webservice zou als volgt in mekaar kunnen zitten:
Collectie personen via URL http://mijnapp.be/people met als HTTP method:
Individuele personen via URL http://mijnapp.be/people/123 met als HTTP method:
De opkomst van REST heeft veel te maken met de voordelen die het kan bieden: het schaalt makkelijk, het is een stuk compacter en performanter dan bv. SOAP en het past perfect in het plaatje van de meeste serverside MVC frameworks en HTTP en ook de frontend frameworks zoals Backbone of Ember kunnen makkelijk RESTful conventies automatiseren. Het is immers makkelijk om bv uit "GET /companies/123.json" af te leiden dat je het bedrijf met ID 123 wil uit de database halen en als JSON wil weergegeven zien.
REST heeft op zich niets met sessions te maken, ze worden zelfs dikwijls zonder sessions maar bv. via een API key in de header aangesproken. In tegenstelling tot SOAP is het ook geen protocol maar eerder een bepaalde architectuur, omdat het geen officiële standaard is. Het protocol om REST over te transporteren is HTTP(S). Daarom is het ook moeilijk om precies uit te leggen hoe een RESTful protocol er precies uitziet, je kan dat zelf beslissen, zolang het maar de principes van REST gebruikt.
Een van de meest belangrijke principes is dat je "resources" gaat exposen via een unieke identifier, bij HTTP de URL. Het manipuleren van die resources gebeurt via de mogelijkheden van een standaardinterface. De representatie is ook iets wat meegegeven wordt via het onderliggend protocol. Dat kan als extensie (resource.json) of via een Accept header (application/json). Dat moet ook niet noodzakelijk JSON of XML zijn, alhoewel die het populairst zijn. Dat kan bij wijze van spreken perfect HTML, SVG, CSV of zelfs PDF zijn.
Een mogelijke REST webservice zou als volgt in mekaar kunnen zitten:
Collectie personen via URL http://mijnapp.be/people met als HTTP method:
- GET Haal een lijst van de personen op
- PUT/PATCH Pas een ganse lijst van personen aan
- POST Maak een nieuwe persoon of personen aan
- DELETE Wis een lijst van personen
Individuele personen via URL http://mijnapp.be/people/123 met als HTTP method:
- GET Haal de gegevens van de persoon op
- PUT/PATCH Pas een bestaande persoon aan
- POST Wordt niet gebruikt
- DELETE Wis de persoon
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.