Ontwikkelaars van event-foto-apps hebben nu een concrete checklist om browser-uploads levend te houden in drukke locaties. Een enkele gebruiker kan wisselen tussen Wi-Fi en mobiele data terwijl tientallen apparaten strijden om dezelfde hotspot. De gids laat zien hoe je voorkomt dat een foto verdwijnt na een "upload voltooid"-toast-melding, zelfs als de gast zijn telefoon vergrendelt of het netwerk hapert.

Waarom gewone uploads mislukken op bruiloften en festivals

Op een kantoor staat een laptop op een stabiele Ethernet-verbinding en klikt een enkele gebruiker op "verzenden". Tijdens een bruiloft of een muziekfestival kan dezelfde actie een cascade aan problemen veroorzaken: de gast loopt van de ceremoniezaal naar de parkeerplaats, de router bezwijkt onder honderden telefoons, of de telefoon verliest de Wi-Fi en schakelt over naar mobiele data. De browser heeft misschien elke byte naar de server gestreamd, maar de server heeft het bestand nog niet naar de opslag geschreven. Als de UI succes meldt op het moment dat de voortgangsbalk de 100% bereikt, kan de gast de foto verwijderen, waardoor de organisator met een ontbrekend bestand achterblijft.

De verborgen kosten van "gewoon uploaden"

Een naïeve aanpak behandelt de upload als een enkele HTTP POST. Dit werkt wanneer de verbinding stabiel is, maar op een overbelast netwerk dwingt elke onderbreking het hele bestand om opnieuw te beginnen. Gebruikers raken gefrustreerd en de bandbreedte piekt wanneer tientallen telefoons tegelijkertijd opnieuw proberen. Het opdelen van het bestand in chunks en het bijhouden van elk deel voegt complexiteit toe, maar de beloning is een voorspelbare transfer met weinig overhead die netwerkwisselingen overleeft.

Het bouwen van een hervatbaar, chunked upload-systeem

Hieronder staat een praktisch stappenplan.

1. Genereer een upload-ID voordat er data de browser verlaat

Maak lokaal een universeel unieke identifier (UUID) aan en stuur deze als de eerste aanvraag naar de server. De server legt een sessie vast onder die ID. Als de browser later opnieuw probeert vanwege een timeout, wordt dezelfde UUID meegestuurd, zodat de server de sessie herkent en een dubbele invoer voorkomt. Dit maakt de workflow idempotent — het herhalen van dezelfde aanvraag heeft geen nadelig effect.

2. Splits het bestand in chunks van 5 – 10 MB

De grootte van de chunk is een afweging. Kleine chunks (onder de 1 MB) verhogen het aantal HTTP-verzoeken en de bijbehorende header-overhead. Zeer grote chunks maken elke onderbreking kostbaar omdat de client een groot deel opnieuw moet verzenden. Voor typische foto's en korte video's is 5 – 10 MB een goede balans: elk verzoek wordt snel genoeg voltooid om de UI responsief te houden, terwijl het aantal verzoeken beheersbaar blijft.

3. Beperk het aantal parallelle uploads

Mobiele browsers kunnen veel verbindingen openen, maar op een overbelast Wi-Fi-netwerk concurreert elke extra stream om de beperkte bandbreedte. Twee stabiele streams zijn beter dan acht concurrerende streams. Gebruik de navigator.connection API om omstandigheden met een lage bandbreedte te detecteren en de concurrency automatisch te verlagen.

4. Bewaar de uploadstatus in IndexedDB

Sla de upload-ID, de lijst met reeds verzonden chunks en eventuele door de server bevestigde offsets op in de IndexedDB van de browser. Als de pagina opnieuw wordt geladen of de gebruiker het tabblad sluit, kan de client de status bij de volgende keer laden herstellen. Wanneer de gebruiker de pagina opnieuw opent, vraag hem dan om hetzelfde bestand te selecteren; de opgeslagen metadata zorgt ervoor dat de upload kan worden hervat vanaf de laatste bevestigde chunk in plaats van opnieuw te beginnen.

5. Detecteer echte netwerkveranderingen, niet alleen navigator.onLine

De navigator.onLine flag rapporteert vaak "online" zelfs wanneer de verbinding onbruikbaar is. Stel in plaats daarvan een korte request timeout in (bijv. 5 seconden) voor elke chunk. Als er een timeout optreedt, behandel het netwerk dan als offline. Wanneer de verbinding herstelt, vraag dan aan de server welke chunks deze al heeft en ga vervolgens alleen verder met het uploaden van de ontbrekende delen. Dit voorkomt het verzenden van dubbele gegevens na een korte onderbreking.

6. Pas exponential backoff met jitter toe voor retries

Wanneer de apparaten van veel gasten merken dat het netwerk weer beschikbaar is, zouden ze allemaal op hetzelfde moment opnieuw kunnen proberen, wat de server kan overbelasten. Exponential backoff zorgt ervoor dat elke retry langer wacht dan de vorige, terwijl jitter een kleine willekeurige offset toevoegt. De combinatie verspreidt het retry-verkeer over enkele seconden, waardoor een plotselinge piek wordt voorkomen.

7. Toon gelaagde, toegankelijke feedback

Een statusbalk met drie niveaus communiceert de werkelijke status van het bestand:

  • Ontvangen – de server heeft elke chunk opgeslagen en het bestand als voltooid gemarkeerd.
  • Voorbereiden – de server genereert thumbnails of transcodeert een video.
  • Beschikbaar – de organisator kan het bestand bekijken of downloaden.

Vertrouw niet alleen op kleur; combineer iconen met korte tekst, zodat gebruikers van schermlezers ook de voortgang begrijpen.

Wat kan er nog misgaan?

Zelfs een goed ontworpen resumable upload kan struikelen over een paar edge cases.

Waar je vervolgens op moet letten

Het webplatform is volop in ontwikkeling.

Conclusie

Een resumable, chunked upload die elk deel bijhoudt, de status lokaal opslaat en intelligent opnieuw probeert, verandert een onbetrouwbaar netwerk van events in een betrouwbare verbinding voor gastenfoto's. Implementeer de bovenstaande checklist.