Beste werkwijze gevraagd
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).
Edit:
Waarom ben je altijd zo snel Ariën? :-)
Waarom ben je altijd zo snel Ariën? :-)
Gewijzigd op 15/03/2020 14:01:26 door Frank Nietbelangrijk
Iemand een linkje naar iets waar ik mee vooruit kan?
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.
https://socket.io/ >> https://socket.io/get-started/chat/
Maar zo zijn er ook een hoop andere websockets-services.
klik hier
Ik zie dat het linkje niet werkte... nu misschien wel?
Gewijzigd op 15/03/2020 14:27:42 door Frank Nietbelangrijk
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)?
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 -
- 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.
Het programma draait intern (cloud) op een VPS.
long polling
Tja dan krijg je denk ik Gewijzigd op 15/03/2020 14:42:17 door Frank Nietbelangrijk
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.
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!
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.
- Ariën - op 15/03/2020 15:06:10:
Cronjobs werken trouwens per minuut.
Cronjobs werken trouwens per minuut.
Klopt maar met een loopje erin kan dat ook 60x ;)
Ad Vertentie op 15/03/2020 15:07:38:
Klopt maar met een loopje erin kan dat ook 60x ;)
- Ariën - op 15/03/2020 15:06:10:
Cronjobs werken trouwens per minuut.
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 -
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.
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
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.