Hoe wij real-time applicaties bouwen

Een chatbericht dat direct verschijnt. Een dashboard dat automatisch update zodra er een nieuwe order binnenkomt. Een voorraad melding die precies op het juiste moment verschijnt. Voor gebruikers is dit tegenwoordig heel normaal, maar er komt best wat kijken bij het bouwen van software die zich zo soepel gedraagt. Bij het ontwikkelen van maatwerk software zorgen wij ervoor dat belangrijke informatie direct doorstroomt naar het scherm van de gebruiker, zonder vertraging en zonder dat iemand op een vernieuwknop hoeft te drukken. In dit artikel leggen we uit hoe wij dit implementeren en waarom het waardevol kan zijn voor jouw organisatie.

Auteur: Thijmen Perdon

Gepubliceerd: 1 september, 2026

Waarom 'even wachten' niet meer van deze tijd is

Veel websites en applicaties werken nog volgens een simpel principe: je vraagt iets op, de server zoekt het op en stuurt het antwoord terug. Voor een pagina die zelden verandert werkt dat prima. Maar bij processen waarbij elke seconde telt, wordt dit al snel een knelpunt. En in een tijd waarin de vraag naar steeds meer realtime informatie gebruikelijk is, werkt dat niet meer. Vroeger loste men dat op met 'polling': de applicatie vraagt op de achtergrond steeds opnieuw: “is er al iets nieuws?” Elke paar seconden opnieuw, ook al is het antwoord bijna altijd "nee". Dat kost onnodig veel servercapaciteit, jaagt de kosten van je clouddiensten/hosting op, en levert alsnog vertraging op.

In de gevallen dat er daadwerkelijk een real-time oplossing nodig is kiezen wij daarom steeds vaker voor een andere aanpak. Een permanente, beveiligde verbinding tussen het scherm van de gebruiker en de server. Zodra er iets verandert, wordt die informatie direct door de server doorgestuurd, zonder dat er iets hoeft te worden opgevraagd. Het resultaat is dat updates die binnen een fractie van een seconde zichtbaar zijn, in plaats van na enkele seconden wachten. Technisch gezien betekent dit dat er een HTTP request naar de server wordt verstuurd die in de response header aangeeft dat het een speciale websocket verbinding betreft. Hierdoor begrijpen de browser en de server elkaar en schakelen ze over naar een specifiek WebSocket protocol (ws:// of wss:// voor een beveiligde variant). Vanaf dit moment blijft er een connectie openstaan waar bi-directioneel data verstuurd kan worden.

Is dit een kant en klare dienst of in eigen beheer?

Voor deze real-time verbindingen zijn er een aantal kant-en-klare diensten, tegen betaling, beschikbaar. Een bekend voorbeeld hiervan is Pusher. Bij Dolphiq kiezen we er bewust voor om dit binnen onze eigen technische omgeving, te regelen met Laravel Reverb. Reverb is een WebSocket server geschreven en onderhouden door het Laravel team die het Pusher protocol implementeert. Dit is praktisch omdat we zo in het door ons gebruikte Laravel ecosysteem kunnen blijven met daarin geïntegreerd het Pusher protocol. Aan de voorkant gebruiken we hiervoor Laravel Echo, welke ook het Pusher protocol hanteert.

De voordelen van een eigen implementatie

Geen afhankelijkheid van een externe partij

Voorspelbare kosten, ook als je groeit

Je zit niet vast aan een leverancier en loopt geen risico op kosten die onvoorspelbaar oplopen naarmate je platform groeit en meer mensen tegelijk gebruikmaken van de real-time functies.

Volledige controle over data

Alle informatie blijft binnen de eigen omgeving

Voor sectoren als zorg, finance en logistiek is dat vaak essentieel met het oog op privacywetgeving zoals de AVG.

Geen concessies aan gebruiksgemak

Vertrouwde tools, efficiënte ontwikkeling

Onze ontwikkelaars blijven werken met de tools waar ze al ervaring mee hebben. Dat houdt de ontwikkeling efficiënt en betrouwbaar.

Real-time verbindingen veilig in eigen beheer

Niet alle informatie is voor iedereen bedoeld, en daar houden we rekening mee. Naast de standaard beveiligde verbindingen werken we in drie niveaus:

Openbaar

Informatie die voor iedereen zichtbaar mag zijn, zoals een publieke nieuwsfeed. Dit heet een public channel en vereist geen validatie aan de serverkant, omdat de data voor iedereen toegankelijk hoort te zijn.

Persoonlijk en beveiligd

Gevoelige informatie, zoals transacties of klantspecifieke meldingen, wordt pas getoond nadat de server heeft gecontroleerd of de gebruiker daar recht op heeft. Dit heet een private channel. Wil iemand de status van een order inzien, dan checkt de server eerst of die order van hem is; pas daarna krijgt hij toegang.

Samenwerking in real-time

Denk aan zien wie er online is of samen live in een document werken, alleen zichtbaar voor bevoegde gebruikers. Dit heet een presence channel: hetzelfde autorisatiemechanisme, met een extra laag die bijhoudt wie er al is, wie binnenkomt en wie vertrekt.

Het juiste signaal bij de juiste persoon

Zodra er ergens iets gebeurt in de organisatie, een nieuwe order komt binnen, een taak is afgerond, een sensor slaat aan, wordt dat signaal direct en veilig doorgestuurd naar precies de mensen die dat op dat moment moeten weten. Dit betekent dat elke keer als er iets gebeurt, de informatie wordt doorgestuurd naar Reverb, die het meteen deelt met iedereen die er toegang toe heeft en op dat moment verbonden is.

Onderdeel van een groter geheel

Wij bouwen onze applicaties het liefst met een combinatie van technologieën die samen zorgen voor een overzichtelijke, snel te onderhouden codebase, zonder onnodig zware en complexe technische lagen. Pas op het moment dat een project daadwerkelijk baat heeft bij real-time functionaliteit, voegen we die toe. Zo blijft de basis simpel en betrouwbaar, en voegen we complexiteit alleen toe waar die concrete waarde oplevert.

Onze drie uitgangspunten: betrouwbaar, veilig en schaalbaar

Betrouwbaarheid

Valt de verbinding even weg, bijvoorbeeld bij het wisselen van wifi naar mobiel internet? Dan herstelt die zich automatisch en wordt gecontroleerd of er updates zijn gemist. Zo werkt niemand met verouderde informatie en gaat er geen data verloren.

Beveiliging

We gaan uit van het principe "vertrouw niets, controleer alles". Bij elke gevoelige of persoonlijke datastroom controleren we eerst of iemand er toegang toe mag hebben, voordat er ook maar iets wordt getoond.

Schaalbaarheid

Onze opzet kan moeiteloos duizenden gebruikers tegelijk aan. Groeit een platform door, dan breiden we de infrastructuur uit terwijl snelheid en betrouwbaarheid gelijk blijven. Gebruikers merken daar niets van.

Wanneer kiezen we hier bewust niet voor?

Als strategisch partner adviseren we onze klanten ook wanneer iets niet nodig is. Real-time technologie brengt namelijk wel wat extra complexiteit met zich mee, en die investering is niet altijd de moeite waard. Verandert data maar een paar keer per dag, of maakt een vertraging van een halve minuut niets uit, zoals bij een maandelijkse rapportage of een informatieve website, dan kiezen we bewust voor de eenvoudigere, traditionele aanpak. We zetten techniek alleen in wanneer die daadwerkelijk bijdraagt aan de waarde voor jouw organisatie of aan het gemak van je gebruikers.

Wat kunnen we hiermee voor jouw organisatie betekenen?

Real-time techniek gaat over veel meer dan alleen chatberichten. In de praktijk kan het ingezet worden om bijvoorbeeld:

Transacties en belangrijke cijfers direct te verwerken en te tonen in financiële dashboards.
Voertuigen en voorraden live te volgen binnen logistiek en supply chain.
Sensordata en storingsmeldingen live inzichtelijk te maken binnen IoT-toepassingen.
Samenwerkingstools bouwen waarin meerdere collega's tegelijk in hetzelfde scherm kunnen werken, zonder elkaars werk te overschrijven.

Heb je interesse in een real-time applicatie?

Gebruikers leggen de lat tegenwoordig hoger: ze vergelijken zakelijke software met de vloeiende ervaring van WhatsApp en Teams. Een applicatie die direct en proactief reageert, voelt niet alleen professioneler aan, maar voorkomt ook dat medewerkers beslissingen nemen op basis van verouderde informatie. Benieuwd hoe we jouw bedrijfsprocessen kunnen versnellen met real-time functionaliteit? Neem contact met ons op voor een vrijblijvende sessie.