Juiste manier van dataverwerking tegenwoordig?

[HollowGamer]

Op dit moment ben ik bezig met het leren van Laravel, Slim, etc. daarbij komen de termen (Rest)API, Node.js, etc. steeds naar boven.

Neem deze API:

code:

https://example.com/api/books
https://example.com/api/books/100
https://example.com/api/books/find/foo
https://example.com/api/books/tags/foo,bar
https://example.com/api/tags
..

Met deze opzet is het misschien beter om niet gebruik te maken van bijvoorbeeld Eloquent ORM (en controllers, modules, etc.), en in plaats hiervan mij Node.js aan te leren.
Formuliergegevens stuur ik vervolgens in JSON formaat op, en de melding(en)/acties worden ook opgehaald via dit formaat. Tevens kan ik het eenvoudiger verwerken in mijn templates.

Is mijn manier van denken hierin dom/overdreven? Levert mij dit performance verbetering op (omdat Node.js multi-threat is)? Of is het beter/sneller om toch gebruik de maken van de Eloquent ORM/PDO?

Stel ik zou kiezen voor een lokale API, dan heeft deze standaard 'root'. Wat is dan de juiste manier dit te realiseren in Laravel? Daar dien ik dan alsnog een controller voor te bouwen? Of kan ik ergens de koppeling maken met een IP-whitelist (of veiligere methode)?

Ik heb gezocht op Google, maar vind ik op deze vragen helaas geen antwoord.

Alvast bedankt!

[ Voor 11% gewijzigd door HollowGamer op 11-07-2016 17:00 ]

[DJMaze]

Wat versta jij onder "dataverwerking"? Is het HTML, is het tekst, is het een PDF, is het een plaatje, is het iets anders of is het alles wat je maar kan bedenken?

En qua performance kan je beter helemaal geen framework gebruiken maar gewoon zelf wat code kloppen.

[ Voor 23% gewijzigd door DJMaze op 11-07-2016 17:44 ]

[armageddon_2k1]

Ik zi hier verschillende dingen langskomen die ik niet helemaal kan koppelen aan elkaar.

Je zegt dat je Laravel aan het leren ben en aan de hand van een API trek je de conclusie dat het wellicht niet geschikt is daarvoor? Node.js zou beter zijn vanwege multithreading?

Ik denk dat je én de snelheid van 'normale' PHP onderschat en veel en veel te veel kijkt naar een eventuele winst die er niet is. Je moet wel een buitengewone use case hebben, of een zeer veel bezochte site, om je nu hierover druk te maken . Frameworks zijn hier juist voor gemaakt om jou te ondersteunen in een goed functionerende site te bouwen die in 99,9% van de use cases voldoet.

Met de opmerking van DJMaze ben ik het dan ook absoluut niet eens. "Zelf wat code kloppen" resulteert vaak in onjuiste, onveilige, ongeoptimaliseerde resultaten die onderdoen voor een framework ontwikkelt door professionals. Leer eerst de kern heel goed voordat je "zelf wat code klopt" om een taak te volbrengen waar anderen al uren aan besteed hebben.

Mijn advies: werk je API goed uit in Laravel en Eloquent, dat is er prima voor gemaakt, en leer daarvan hoe en wat je in het vervolg beter kan doen. Je hebt er dan een betere kijk op dan nu en hebt dan ook nog eens relevante kennis opgedaan.

[HollowGamer]

DJMaze schreef op maandag 11 juli 2016 @ 17:42:
Wat versta jij onder "dataverwerking"? Is het HTML, is het tekst, is het een PDF, is het een plaatje, is het iets anders of is het alles wat je maar kan bedenken?

En qua performance kan je beter helemaal geen framework gebruiken maar gewoon zelf wat code kloppen.

Dataverwerking is misschien de foute woordkeuze, je zou beter input output kunnen noemen.

Stel je haalt gegevens op van Boeknummer 1 of insert een nieuw boek.

Zelf framework ben ik vanaf gestapt, omdat Laravel me zoveel handige features biedt (icm. Composer), dat ik niet meer terug wil naar eigen code (op wat mogelijk is na).

armageddon_2k1 schreef op maandag 11 juli 2016 @ 19:04:
Ik zi hier verschillende dingen langskomen die ik niet helemaal kan koppelen aan elkaar.

Je zegt dat je Laravel aan het leren ben en aan de hand van een API trek je de conclusie dat het wellicht niet geschikt is daarvoor? Node.js zou beter zijn vanwege multithreading?

Ik denk dat je én de snelheid van 'normale' PHP onderschat en veel en veel te veel kijkt naar een eventuele winst die er niet is. Je moet wel een buitengewone use case hebben, of een zeer veel bezochte site, om je nu hierover druk te maken . Frameworks zijn hier juist voor gemaakt om jou te ondersteunen in een goed functionerende site te bouwen die in 99,9% van de use cases voldoet.

Met de opmerking van DJMaze ben ik het dan ook absoluut niet eens. "Zelf wat code kloppen" resulteert vaak in onjuiste, onveilige, ongeoptimaliseerde resultaten die onderdoen voor een framework ontwikkelt door professionals. Leer eerst de kern heel goed voordat je "zelf wat code klopt" om een taak te volbrengen waar anderen al uren aan besteed hebben.

Mijn advies: werk je API goed uit in Laravel en Eloquent, dat is er prima voor gemaakt, en leer daarvan hoe en wat je in het vervolg beter kan doen. Je hebt er dan een betere kijk op dan nu en hebt dan ook nog eens relevante kennis opgedaan.

Klopt dat ik mij nu te druk maak over performance issues etc. Echter wil ik ook leren een zo goed mogelijk oplossing te bouwen.

Ik vraag mij alleen af wat de trend is waarin nu wordt gebouwd en of mijn insteek betreft API klopt. Met een API in node.js bouw je in een keer een mooie database verwerking tool (incl. validatie, auth, etc.), maar weet dus niet of dit langzamer of juist wel handig is.

[ Voor 55% gewijzigd door HollowGamer op 11-07-2016 22:54 ]

[Cartman!]

Er is geen heilige graal, wil je Laravel dan neem je dat. Trends zou ik me niet zo druk om maken, er is veel op de markt en er zit ook een stuk persoonlijke voorkeur in. Er zijn voor elke taal veel frameworks te krijgen en alles heeft voor- en nadelen. In PHP-land is het vooral Symfony en Laravel wat populair is (voor mij heeft de eerste duidelijk de voorkeur maar dat is persoonlijk) maar binnen Node.js zijn er ook diverse frameworks te krijgen (waaronder bijv Express). Verder denk ik dat je met:

Met een API in node.js bouw je in een keer een mooie database verwerking tool (incl. validatie, auth, etc.), maar weet dus niet of dit langzamer of juist wel handig is.

zelf niet helemaal doorhebt dat je in Node.js gewoon hetzelfde werk moet doen als in PHP maar dan in een andere taal

Zelf library/framework code kloppen is anno 2016 pure onzin imo. Dat zal mogelijk sneller zijn in je response-tijd maar als je al je tools en libraries zelf moet gaan maken ben je enorm lang bezig, zal t nooit zo goed worden als de bestaande frameworks en zit je met allemaal eigen meuk die je moet onderhouden... wat is dan je voordeel nog?

offtopic:
Node.js is niet multi threaded trouwens maar single threaded

[Montaner]

Wat archie bedoelt is (denk ik) hoe hij de URL's moet opbouwen in een RESTful API. En ook hier is niet echt een standaard voor.

Laravel geeft je een aantal standaard actions op je controller als je hen werkwijze aanhoudt:
https://laravel.com/docs/...tful-resource-controllers

Hier heb je nog wat voorbeelden, maar er is simpelweg geen standaard.
http://www.restapitutoria...estfulresourcenaming.html

Als je met NodeJS aan de slag gaat, dan moet je wat meer zelf doen. Met (bijvoorbeeld) Laravel hebben de bedenkers van het framework al een oplossing voor je neergezet. Maar, ook daar kan je zelf iets verzinnen .

Tegelijk is dit misschien wel handig om te lezen:
http://programmers.stacke...nce-between-rest-and-crud

[ Voor 30% gewijzigd door Montaner op 12-07-2016 10:28 ]

[HollowGamer]

Cartman! schreef op dinsdag 12 juli 2016 @ 00:11:
Er is geen heilige graal, wil je Laravel dan neem je dat. Trends zou ik me niet zo druk om maken, er is veel op de markt en er zit ook een stuk persoonlijke voorkeur in. Er zijn voor elke taal veel frameworks te krijgen en alles heeft voor- en nadelen. In PHP-land is het vooral Symfony en Laravel wat populair is (voor mij heeft de eerste duidelijk de voorkeur maar dat is persoonlijk) maar binnen Node.js zijn er ook diverse frameworks te krijgen (waaronder bijv Express). Verder denk ik dat je met:


[...]

zelf niet helemaal doorhebt dat je in Node.js gewoon hetzelfde werk moet doen als in PHP maar dan in een andere taal

offtopic:
Node.js is niet multi threaded trouwens maar single threaded

Het is dan misschien toch beter om gewoon voor Laravel te kiezen 'voor alles' en niet gebruikt te maken van losse componenten.

Maar toch, neem bijvoorbeeld deze tutorial, dan heb ik wel een aantal voordelen:
- Het database-systeem is echt gescheiden van het framework, mocht ik ooit weer overstappen dan zit ik niet vast aan de ORM van Laravel bijvoorbeeld
- Het database-systeem kan worden uitgebreid in JavaScript (eenvoudige syntax) en communicatie gebeurd over JSON, zonder dat ik dit hoeft te 'forceren' in mijn framework
- Door de zaken te scheiden kan ik 'eenvoudig' de API (database, maar in toekomst mogelijk meer) aanspreken in andere apps en zelfs in HTML/jQuery, etc. zonder eerst een andere tussenlaag in PHP te programmeren
- De performance van Node.js schijnt beter te zijn (link), plus zou ik ook gebruik kunnen maken van een aparte Nginx proxy die ook weer sneller is dan alles over Laravel.

Wat ik nu bijvoorbeeld van gegevens/files ophaal (Movie #):
- assets (png, gif, mp4)
- tags
- zoeken
- ophalen van records

Allemaal zaken die performance kosten..

Zit ik goed met mijn gedachte of echt beter om het allemaal over te laden via Laravel zelf?

trix0r schreef op dinsdag 12 juli 2016 @ 10:22:
Wat archie bedoelt is (denk ik) hoe hij de URL's moet opbouwen. En ook hier is niet echt een standaard voor.

Laravel geeft je een aantal standaard actions op je controller als je hen werkwijze aanhoudt:
https://laravel.com/docs/...tful-resource-controllers

Hier heb je nog wat voorbeelden, maar er is simpelweg geen standaard.
http://www.restapitutoria...estfulresourcenaming.html

Als je met NodeJS aan de slag gaat, dan moet je wat meer zelf doen. Met (bijvoorbeeld) Laravel hebben de bedenkers van het framework al een oplossing voor je neergezet. Maar, ook daar kan je zelf iets verzinnen .

Dit is niet precies wat ik bedoel, weet dat er geen standaarden zijn voor API's. Zelfs Rest hoeft niet persé, een POST kan ook prima deze zaken afhandelen.

Betreft Node.js; deze hebben wel degelijk zo te zien allemaal tools en hulpmiddelen beschikbaar, waardoor ik eigenlijk vrij weinig zelf hoef te bouwen, dan alleen valideren, verwerken, resultaat terugkoppelen, toch?

[InZane]

HollowGamer schreef op dinsdag 12 juli 2016 @ 10:38:
Zelfs Rest hoeft niet persé, een POST kan ook prima deze zaken afhandelen.

Ik zou me eerst even in de materie verdiepen voordat je verdergaat. Wat je nu zegt raakt kant noch wal.

[Cartman!]

Waarom maak je je eigenlijk zo druk om performance als je de basis nog niet beheerst? Node.js is bloedsnel maar alleen als je het goed doet anders kun je een compleet baggertraag ding maken.

[Ventieldopje]

Voor alleen een losstaande api is Silex of Lumen ook al voldoende. De mini frameworks van respectievelijk Symfony en Laravel.

Erg makkelijk om een REST API mee te bouwen. Post data kun je gewoon verzenden als post data, niet als json. Dat heeft geen enkel voordeel en is ook niet goed voor de compatibiliteit. Dat er geen standaard is wil niet zeggen dat er geen gebruiken zijn. However, REST is redelijk rechttoe rechtaan

Om je nou te storten op NodeJS terwijl je net om de hoek komt kijken met PHP (en frameworks), zou ik niet doen.

[ Voor 11% gewijzigd door Ventieldopje op 12-07-2016 11:00 ]

[Montaner]

Het ORM systeem van Laravel is niet gebonden aan Laravel. Dat kan je ook buiten het framework gebruiken:
https://github.com/illuminate/database

In de NodeJS tutorial bind je het model aan Mongoose (en zit je dus vast aan MongoDB). Met Illuminate is je keuze ook niet heel ruim, maar kan je eventueel nog wisselen (als dat de flexibiliteit is die je wil).

In de performance vergelijking testen ze zo te zien tegen Zend 2. Je kan nog wat vergelijkingsmateriaal zoeken tussen Zend 2 en Laravel.

Je noemt PHP een 'tussenlaag', maar NodeJS is dat ook. Alleen de taal is hetzelfde zoals je deze ook client-side kan gebruiken op een website.

Daarbij moet je het verschil nog even lezen tussen REST en CRUD. Want iets met 'POST' afhandelen is prima (CRUD) op een enkel record, maar REST is iets anders dan dat.

Als je alleen een API wil bouwen kan je ook Lumen gebruiken (https://lumen.laravel.com/) wat kleiner en sneller is. Daarbij is zelfs standaard de ORM uitgeschakeld ;-).

[HollowGamer]

InZane schreef op dinsdag 12 juli 2016 @ 10:57:
[...]




Ik zou me eerst even in de materie verdiepen voordat je verdergaat. Wat je nu zegt raakt kant noch wal.

Weet niet precies wat je bedoeld?
Neem de Wiki en volgende code (zoals in Laravel):

code:

<form action="/path/to/process" method="post">
<input type="hidden" name="_method" value="PUT">
</form>

Dan ben je nog steeds bezig met REST, alleen niet direct via de form-method.

Cartman! schreef op dinsdag 12 juli 2016 @ 10:58:
Waarom maak je je eigenlijk zo druk om performance als je de basis nog niet beheerst? Node.js is bloedsnel maar alleen als je het goed doet anders kun je een compleet baggertraag ding maken.

Omdat ik mij afvraag of het zinvol is om Node.js te leren en waarom 'niet iedereen' dit doet (of juist wel).

Ventieldopje schreef op dinsdag 12 juli 2016 @ 10:59:
Voor alleen een losstaande api is Silex of Lumen ook al voldoende. De mini frameworks van respectievelijk Symfony en Laravel.

Erg makkelijk om een REST API mee te bouwen. Post data kun je gewoon verzenden als post data, niet als json. Dat heeft geen enkel voordeel en is ook niet goed voor de compatibiliteit. Dat er geen standaard is wil niet zeggen dat er geen gebruiken zijn. However, REST is redelijk rechttoe rechtaan

Om je nou te storten op NodeJS terwijl je net om de hoek komt kijken met PHP (en frameworks), zou ik niet doen.

Zit al een hele tijd in de PHP, alleen nog niet zo heel veel met het Laravel framework.
Op dit moment heb ik alles gebouwd in SlimPHP, mooi framework, alleen zie ik nu ook wel voordelen in de features van Laravel of andere (non-PHP) frameworks.

Kan inderdaad ook direct posten, alleen met JSON maak ik het allemaal wat makkelijker met parsen van de data, toch?
Tevens kan ik heel eenvoudig validatie resultaat parsen via JavaScript, i.p.v. weer plain alles verwerken.

code:

{"validation":[
     "firstName":"Should not be empty",
    "lastName":"At least ..",
]}

I.p.v.

code:

firstName: Should not be empty
..

.
Wat ik heb geprobeerd met Laravel kan ik dit heel eenvoudig direct parsen, of via een json_decode().

trix0r schreef op dinsdag 12 juli 2016 @ 11:01:
Het ORM systeem van Laravel is niet gebonden aan Laravel. Dat kan je ook buiten het framework gebruiken:
https://github.com/illuminate/database

In de NodeJS tutorial bind je het model aan Mongoose (en zit je dus vast aan MongoDB). Met Illuminate is je keuze ook niet heel ruim, maar kan je eventueel nog wisselen (als dat de flexibiliteit is die je wil).

In de performance vergelijking testen ze zo te zien tegen Zend 2. Je kan nog wat vergelijkingsmateriaal zoeken tussen Zend 2 en Laravel.

Je noemt PHP een tussenlaag, maar NodeJS is dat ook. Alleen de taal is hetzelfde zoals je deze ook client-side kan gebruiken op een website.

Daarbij moet je het verschil nog even lezen tussen REST en CRUD. Want iets met 'POST' afhandelen is prima (CRUD) is prima op een enkel record, maar REST is iets anders dan dat.

Als je alleen een API wil bouwen kan je ook Lumen gebruiken (https://lumen.laravel.com/) wat kleiner en sneller is. Daarbij is zelfs standaard de ORM uitgeschakeld ;-).

Thanks, ga mij meer verdiepen in REST en CRUD, maar tot nu toe begrijp ik wel de methodes van PUT, PATCH, POST, etc..

In dit voorbeeld werd Mongo gebruikt, maar het is ook wat ik zo op het eerste gezicht vond ook prima mogelijk met MySQL/MariaDB.

Tussenlaag bedoel ik mee dat ik nog altijd communiceer via Laravel als ik bijvoorbeeld bij de database wil, terwijl ik met een API altijd erbij kan d.m.v. een simpel curl bijvoorbeeld. Niet echt direct een voordeel, maar gewoon om aan de geven hoe ik precies bedoel.

[ Voor 3% gewijzigd door HollowGamer op 12-07-2016 11:19 ]

[Ventieldopje]

Ja precies, dat moet je parsen. POST data staat al in je $_POST superglobal en kun je zo gebruiken (of in je request object). Wat heeft json voor voordelen in dit geval? Geen.

Bovendien moet je je form data afvangen, json encoden en dan verzenden met ajax. Weer een scriptje voor een non-issue.

[ Voor 4% gewijzigd door Ventieldopje op 12-07-2016 11:20 ]

[Montaner]

HollowGamer schreef op dinsdag 12 juli 2016 @ 11:13:
[...]
Tussenlaag bedoel ik mee dat ik nog altijd communiceer via Laravel als ik bijvoorbeeld bij de database wil, terwijl ik met een API altijd erbij kan d.m.v. een simpel curl bijvoorbeeld. Niet echt direct een voordeel, maar gewoon om aan de geven hoe ik precies bedoel.

Maar welk systeem gaat die cURL call van je afhandelen dan? Dat is toch je NodeJS webserver? die cURL call kan je ook doen naar een webserver waar je Laravel instantie op staat.

PHP:

<?php
$app->get('/', function() {
    return response()->json(['name' => 'Abigail', 'state' => 'CA']);
});

[Cartman!]

HollowGamer schreef op dinsdag 12 juli 2016 @ 11:13:
[...]
Omdat ik mij afvraag of het zinvol is om Node.js te leren en waarom 'niet iedereen' dit doet (of juist wel).

Elke taal of framework heeft z'n eigen voordelen. Persoonlijk vind ik Node.js niet geschikter dan PHP als het aankomt op wat CRUD-werk. In PHP zijn er al zoveel goede frameworks/libraries die dit grotendeels voor je doen terwijl dit bij Node.js nog pas in opmars begint te komen.

Tussenlaag bedoel ik mee dat ik nog altijd communiceer via Laravel als ik bijvoorbeeld bij de database wil, terwijl ik met een API altijd erbij kan d.m.v. een simpel curl bijvoorbeeld. Niet echt direct een voordeel, maar gewoon om aan de geven hoe ik precies bedoel.

Maar wat gaat Node.js daar dan anders in zijn? Je zal altijd een laag tussen je data en je client moeten hebben dus ik snap niet helemaal wat nu het probleem is.

[HollowGamer]

Cartman! schreef op dinsdag 12 juli 2016 @ 11:32:
[...]

Elke taal of framework heeft z'n eigen voordelen. Persoonlijk vind ik Node.js niet geschikter dan PHP als het aankomt op wat CRUD-werk. In PHP zijn er al zoveel goede frameworks/libraries die dit grotendeels voor je doen terwijl dit bij Node.js nog pas in opmars begint te komen.

[...]

Maar wat gaat Node.js daar dan anders in zijn? Je zal altijd een laag tussen je data en je client moeten hebben dus ik snap niet helemaal wat nu het probleem is.

Je hebt helemaal gelijk dat alles prima in PHP-code kan worden opgevallen, en de manier waarop dit gebeurd in Laravel is fantastisch. Echter vraag ik mij dus af of Node.js voor een lokale API zinvol is en of ik dit zou moeten leren.

trix0r schreef op dinsdag 12 juli 2016 @ 11:21:
[...]

Maar welk systeem gaat die cURL call van je afhandelen dan? Dat is toch je NodeJS webserver? die cURL call kan je ook doen naar een webserver waar je Laravel instantie op staat.

PHP:

<?php
$app->get('/', function() {
    return response()->json(['name' => 'Abigail', 'state' => 'CA']);
});

Een simpele controller had ik gedachte i.c.m. Guzzle: url, data (opt), parameter(s) (opt)
Die controller geeft een foutmelding bij invalide url/parameter, etc.
Data wordt teruggestuurd in een JSON-formaat, zodat deze eenvoudig kan worden gebind aan een formulier input-tag bijvoorbeeld.

[Cartman!]

HollowGamer schreef op dinsdag 12 juli 2016 @ 11:46:
[...]

Je hebt helemaal gelijk dat alles prima in PHP-code kan worden opgevallen, en de manier waarop dit gebeurd in Laravel is fantastisch. Echter vraag ik mij dus af of Node.js voor een lokale API zinvol is en of ik dit zou moeten leren.

Als jij het interessant vind ga je t leren, zo simpel is t toch?

HollowGamer schreef op dinsdag 12 juli 2016 @ 11:46:
Een simpele controller had ik gedachte i.c.m. Guzzle: url, data (opt), parameter(s) (opt)
Die controller geeft een foutmelding bij invalide url/parameter, etc.
Data wordt teruggestuurd in een JSON-formaat, zodat deze eenvoudig kan worden gebind aan een formulier input-tag bijvoorbeeld.

Ik begrijp niet wat Guzzle hier nu mee te maken heeft...je wilde toch data in een database querien?

[ Voor 37% gewijzigd door Cartman! op 12-07-2016 12:11 ]

[HollowGamer]

Cartman! schreef op dinsdag 12 juli 2016 @ 12:10:
[...]

Als jij het interessant vind ga je t leren, zo simpel is t toch?


[...]

Ik begrijp niet wat Guzzle hier nu mee te maken heeft...je wilde toch data in een database querien?

Bedoelde de manier waarom ik de API benader, dat wil ik gaan doen via Guzzle.
Vind het zeker interessant, alleen heb ik soms een idee, maar vraag je hardop af of dit wel een goede insteek is.
---
Thanks allemaal voor de input en eerlijkheid, ga ermee aan de slag.

[Cartman!]

Maar je gaat een API maken in PHP en die ga je zichzelf weer met Guzzle laten aanroepen? Volgens mij heb je t nog niet helemaal helder

[HollowGamer]

Cartman! schreef op dinsdag 12 juli 2016 @ 12:16:
Maar je gaat een API maken in PHP en die ga je zichzelf weer met Guzzle laten aanroepen? Volgens mij heb je t nog niet helemaal helder

Klopt, ben ook steeds meer aan het denken dat het een dom idee is.
Dacht dat het wel handig was als ik een losse API zou maken, maar kan net zo goed alles in Laravel verwerken, i.c.m. Eloquent ORM, en alle andere overige zaken.

Had deze opzet in gedachte:
- Klein simpel framework
- API (node.js) die alles valideert, verwerkt, resultaat terugkoppelt

Maar kan net zo goed alles in een framework verwerken, en daar een API aanroeping op maken indien ik dit nodig zou hebben.

[borft]

Je idee is in principe goed, bepaalde functionaliteit in een API bouwen. Maar waarom zou je dat over HTTP willen gooien? Definieer je API in een Interface, en implementeer die dan. Vervolgens kan je in je Controller gebruik maken van die API door de class te instantieren. Lijkt me dat een extra HTTP tussenlaag alleen maar overhead is.