Beste werkwijze gevraagd

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ad Vertentie

Ad Vertentie

15/03/2020 13:53:11
Quote Anchor link
Voor een rapportageprogramma waar tientallen werkplekken gelijktijdig mee werken ben ik benieuwd naar het volgende:

Het gebouwde systeem haalt middels een Jquery/AJAX/JSON refresh elke seconde de resultaten/rapportages van 1 (flinke) query binnen.
Momenteel werken 10 werkplekken met dit programma. Dit betekend dat elke cliënt elke seconde de query opvraagt en op het scherm toont.
Ik ben benieuwd of er een betere manier is om dit te doen b.v. dmv XML / SOAP / JSON.
De bedoeling is dat als cliënt 1 een rapportage aanmaakt, alle overige ingelogde cliënt dit ook meteen op het scherm zien (dus realtime).
 
PHP hulp

PHP hulp

29/03/2024 15:38:22
 
- Ariën  -
Beheerder

- Ariën -

15/03/2020 13:57:10
Quote Anchor link
Als je elke seconde een zware query wilt uitvoeren, dan zie ik in mijn ogen een proces wat geoptimaliseerd kan worden. Elke seconde een AJAX-requst lijkt mij overdreven, een push-systeem via sockets lijkt mij zinvoller als het moet plaatsvinden. Dan worden de wijzigingen door eén systeem naar alle clients gestuurd, in plaats van die steeds allen tezamen een request doen naar een server die het al zwaar genoeg heeft.

Dus duik eens in de wereld van websockets.....
Gewijzigd op 15/03/2020 13:58:23 door - Ariën -
 
Frank Nietbelangrijk

Frank Nietbelangrijk

15/03/2020 14:00:31
Quote Anchor link
Als het echt realtime moet zijn dan zijn websockets het enige juiste antwoord. Dit vereist echter wel een speciale extensie op je webserver.

Edit:

Waarom ben je altijd zo snel Ariën? :-)
Gewijzigd op 15/03/2020 14:01:26 door Frank Nietbelangrijk
 
Ad Vertentie

Ad Vertentie

15/03/2020 14:06:15
Quote Anchor link
Ok! Dat klinkt onbekend :)
Iemand een linkje naar iets waar ik mee vooruit kan?
 
- Ariën  -
Beheerder

- Ariën -

15/03/2020 14:16:26
Quote Anchor link
https://nl.wikipedia.org/wiki/WebSocket
https://socket.io/ >> https://socket.io/get-started/chat/

Maar zo zijn er ook een hoop andere websockets-services.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

15/03/2020 14:18:25
Quote Anchor link
Misschien kun je hier eens mee beginnen?

klik hier

Ik zie dat het linkje niet werkte... nu misschien wel?
Gewijzigd op 15/03/2020 14:27:42 door Frank Nietbelangrijk
 
Ad Vertentie

Ad Vertentie

15/03/2020 14:22:42
Quote Anchor link
Nice! Thx heren!
Enige uitdaging is denk ik wel dat alle poorten behalve 80 en 443 gesloten zijn.
Is het mogelijk om vormgeving te geven aan websockets (layout), en ook hetgeen gerapporteerd is op te slaan in MySQL (en deze te fetchen zodra er een update is)?
 
- Ariën  -
Beheerder

- Ariën -

15/03/2020 14:26:39
Quote Anchor link
Dan moet MySQL het wel kunnen pushen. En mij bekruipt de gedachte via een rondje Google, dat MySQL dit niet kan. Plus dat clients niks met MySQL te maken hebben.

Maar waarom kunnen de andere poorten niet open? Ik neem aan dat je met jouw systeem toch niet op een simpel shared webhostingpakket zit? Desnoods kan je een VPS ervoor inzetten, en NodeJS erop installeren.
Gewijzigd op 15/03/2020 14:29:01 door - Ariën -
 
Frank Nietbelangrijk

Frank Nietbelangrijk

15/03/2020 14:31:17
Quote Anchor link
Ik zou deze volgorde aanhouden:

- rapportage formulier
- POST formulier, valideer en sla gegevens op in mysql database
- PUSH het de nieuwe (zojuist opgeslagen) rapportage naar de clients

Toevoeging op 15/03/2020 14:32:14:

Alles is gewoon PHP alleen in stap drie voeg je er een nieuwe functionaliteit aan toe.
 
Ad Vertentie

Ad Vertentie

15/03/2020 14:33:19
Quote Anchor link
Ok.. dan gaat websockets het niet worden, zijn er andere opties wellicht?
Het programma draait intern (cloud) op een VPS.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

15/03/2020 14:39:44
Quote Anchor link
Tja dan krijg je denk ik long polling
Gewijzigd op 15/03/2020 14:42:17 door Frank Nietbelangrijk
 
Thomas van den Heuvel

Thomas van den Heuvel

15/03/2020 14:52:11
Quote Anchor link
Ik zou misschien ook niet een techniek/programmeertaal voorop stellen maar eerder kijken naar welke techniek / methodiek het beste werkt voor een/jouw realtime applicatie. Sockets zijn waarschijnlijk nodig, er moet immers gecommuniceerd worden, maar er zijn legio programmeertalen die sockets implementeren. Misschien kom je wel uit op een standalone applicatie van het een of ander, in plaats van een webbased aanpak. Maak anders diverse proof-of-concepts en kijk wat het beste werkt in jouw situatie. Misschien zijn er wel andere mogelijkheden of beperkingen die alle van invloed zijn op welke opties uberhaupt valide zijn. Zou eerst eens wat onderzoek doen naar de mogelijkheden.
 
Ad Vertentie

Ad Vertentie

15/03/2020 15:03:47
Quote Anchor link
Het probleem is eigenlijk dat er geen probleem is.
De huidige manier van werken werkt eigenlijk prima.
Om met de tijd mee te gaan (ook ivm veiligheid) ben ik benieuwd wat andere mogelijkheden kunnen zijn.
Mijn eerste idee was om het met XML of SOAP te gaan doen, echter denk ik dat dit niet een hele veilige manier is om gevoelige data naar cliënts te sturen.
De opzet zou dan zijn om middens een cronjob welke elke seconde (of 5.. maakt niet heel veel uit) een XML te genereren of aan te vullen die aan bepaalde tijdsspecificaties voldoet.
Het rapportagescript zou dan aan de cliëntzijde dezelfde refreshrate kunnen aanhouden om het XML gebeuren binnen te halen en te verwerken, echter qua veiligheid lijkt me de huidige manier nog net iets beter.
Ik denk dat ik het voor dit moment even laat zoals het is.
Allen bedankt voor de snelle reacties en het verbreden van mijn spectrum!
 
- Ariën  -
Beheerder

- Ariën -

15/03/2020 15:06:10
Quote Anchor link
Als websockets het niet worden, en het is nu met de huidige techniek geen probleem, dan vrees ik wel dat het op den duur een probleem gaat vormen.

Maar waarom kan er niet geïnvesteerd worden in websockets? Het is feitelijk weinig moeite, en het is zo ingericht.

Cronjobs werken trouwens per minuut.
 
Ad Vertentie

Ad Vertentie

15/03/2020 15:07:38
Quote Anchor link
- Ariën - op 15/03/2020 15:06:10:

Cronjobs werken trouwens per minuut.


Klopt maar met een loopje erin kan dat ook 60x ;)
 
- Ariën  -
Beheerder

- Ariën -

15/03/2020 15:09:59
Quote Anchor link
Ad Vertentie op 15/03/2020 15:07:38:
- Ariën - op 15/03/2020 15:06:10:

Cronjobs werken trouwens per minuut.


Klopt maar met een loopje erin kan dat ook 60x ;)


Als jij graag investeert in dure servers..... ;-)
En het is niet te hopen dat er dan processen zullen time-out'en. Dat heb ik ooit eens gezien. php-fpm te veel geheugen door de vele opeengestapelde processen, server onderuit.
Gewijzigd op 15/03/2020 15:12:14 door - Ariën -
 
Frank Nietbelangrijk

Frank Nietbelangrijk

15/03/2020 15:13:05
Quote Anchor link
Cronjobs dat moet je niet willen. En 10 clients elke seconde een request maakt dan al gauw een extra 10 requests per seconde naast je normale verkeer. Overweeg dan een periode van bijvoorbeeld 10 seconden. dat scheelt alweer een flinke hap.
 
Thomas van den Heuvel

Thomas van den Heuvel

15/03/2020 15:21:27
Quote Anchor link
Ad Vertentie op 15/03/2020 15:03:47:
Mijn eerste idee was om het met XML of SOAP te gaan doen

Uhm, is iedereen ondertussen niet over naar JSON? Veel sneller/lichtgewicht etc?

Ad Vertentie op 15/03/2020 15:03:47:
echter denk ik dat dit niet een hele veilige manier is om gevoelige data naar cliënts te sturen.

Uhm, dat wordt eerder bepaald door het transport, en niet het formaat? Mja als je dit gewoon over HTTP knalt zonder authenticatie dan maakt het niet zoveel uit welk format dit is? :p

Ad Vertentie op 15/03/2020 15:03:47:
De opzet zou dan zijn om middens een cronjob welke elke seconde (of 5.. maakt niet heel veel uit) een XML te genereren of aan te vullen die aan bepaalde tijdsspecificaties voldoet.

De hierboven genoemde voorstellen suggereren volgens mij een PUSH-strategie (je wordt ingelicht wanneer er nieuwe data beschikbaar is), in plaats van het standaard PULL-mechanisme waarbij je informatie elke keer ophaalt, vergelijkbaar met het eindeloos verversen van een pagina. Oftewel "Don't call us, we will call you".

Ad Vertentie op 15/03/2020 15:03:47:
refreshrate

Heb je dus niet meer als het goed is, althans niet zoals voorheen.

Ad Vertentie op 15/03/2020 15:03:47:
veiligheid

Hangt helemaal van het transport af, lijkt mij. En of de eindgebruiker zich aan de voorschriften houdt, want dat is tegenwoordig meestal de zwakste schakel.
Gewijzigd op 15/03/2020 15:33:10 door Thomas van den Heuvel
 
Frank Nietbelangrijk

Frank Nietbelangrijk

15/03/2020 15:58:32
Quote Anchor link
ja XML en SOAP... zoals het ooit begon :p

en XML of JSON kan echt zo veilig zijn als ieder normaal verzoek aan een webserver. Voordat je de data terugstuurt kun je gewoon je SESSION raadplegen en kijken of deze gebruiker ingelogd is en voldoende rechten heeft om deze data te ontvangen. Vervolgens doe je in 2020 natuurlijk ALLES over een beveiligde verbinding zodat je data niet door "the man in the middle" wordt onderschept.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.