...

Server Sent Events en Websockets lijken veel op elkaar. Ook is er in dit geval één kopje voor de twee samen. Een aantal verschillen tussen de twee is dat SSE over HTTP gebruikt kan worden terwijl websockets hun eigen protocol hebben. Een verschil tussen de twee die echt een verschil maakt is wie requests en responses kan sturen. Bij SSE wordt er één keer een request gestuurd naar de server. Dit request is een aanvraag om te verbinden. Daarna kan alleen de server berichten terug sturen. De client kan geen berichten naar de server sturen. Dit is ook waar SSE voor gemaakt is. Websockets, die wel berichten kunnen sturen naar de server als er eenmaal een connectie is geopend, zouden in dit geval dan een overkill zijn. Er zijn nog wel andere voor en nadelen te benoemen, zoals dat SSE maar een maximaal open connecties mag hebben, maar ook hiervoor zijn oplossingen te bedenken. Echter is dit ook geen probleem voor deze applicatie.

Conclusie

Als we los kijken naar alle systemen dan zijn er twee die er gelijk uitspringen. Dit zijn de Server Sent Events en Websockets. Deze twee, veel op elkaar lijkende technieken, zijn toch wel de twee die ons het beste lijken. Een websocket en een server side event service zijn de twee keuze's die het meest real time zijn zonder dat deze technieken extra middelen gebruiken, of meer middelen dan nodig. 

Omdat er gebruik wordt gemaakt van een message broker is onze oplossing niet afhankelijk van de rest van de andere systemen. We zouden met een websocket de data van de broker kunnen 'consumeren'. De broker krijgt de data van de Raspberry Pi en zal deze distribueren naar verschillende consumers, in dit geval de websocket en database. De websocket zou in dit geval de data in de juiste vorm kunnen gieten voor de website. Dit zou er voor zorgen dat de data die op de website binnenkomt gelijk kan worden omgezet naar de visuele weergaves. Omdat de broker ook gelijk de data naar de database stuurt kunnen we later deze gebruiken om de data te tonen van vorige races. Het kan zo zijn dat we vanuit de database een berekening willen maken, er een gebruiker wordt aangemaakt op de website of iets anders in deze richting. Het is mogelijk dat dit ook weer via de broker moet (omdat het niet naar de database moet maar ook naar een andere harde schijf die ergens ligt). Om deze reden kiezen wij er bewust voor om een websocket te gaan gebruiken in combinatie met een message broker en niet een Server Side Events Service. 

Bronnenlijst 

Herrera, E. (2018, 4 mei). Getting data in realtime from MySQL with Java. Pusher. https://pusher.com/tutorials/realtime-mysql-java/

...