Notificaties toevoegen aan je app: in-app, e-mail en push

Om notificaties aan een webapp toe te voegen, begin je met in-app-notificaties: een tabel met notificaties in je database en een belicoon dat ongelezen items toont. Voeg e-mail toe voor dingen die mensen moeten weten als ze weg zijn, met een e-mailprovider, en voeg webpush alleen toe als tijdige meldingen echt belangrijk zijn. Dat vraagt om een service worker, toestemming van de gebruiker en, op de iPhone, de app op het beginscherm. Welke kanalen je ook gebruikt, maak elke notificatie op één plek aan op de server en laat gebruikers kiezen wat ze ontvangen.

Deze gids vergelijkt de kanalen, laat een eenvoudige architectuur zien en geeft prompts die je met een AI-app-builder kunt gebruiken.

De belangrijkste kanalen vergeleken

De meeste apps hebben in-app plus e-mail nodig. Push en sms zijn het waard als timing echt telt, zoals een boekingsherinnering of een bestelling die klaarstaat.

Zo werkt een notificatiesysteem samen

Hou het eenvoudig en centraal:

1. Er gebeurt iets. Er wordt gereageerd, een betaling mislukt, een afspraak is morgen.
2. Je server roept één functie aan, bijvoorbeeld notify(user, type, data).
3. Die functie controleert de voorkeuren van de gebruiker en schrijft een rij naar de tabel notifications (voor de bel).
4. Daarna stuurt hij naar de andere kanalen die de gebruiker voor dat type heeft aangezet: e-mail via je provider, push via de Push API.
5. De frontend toont ongelezen notificaties en markeert ze als gelezen zodra ze worden geopend.

Met één ingangspunt kun je een kanaal toevoegen, teksten aanpassen of voorkeuren respecteren zonder door de hele codebase te zoeken.

Wat je opslaat

Een notificatietabel heeft meestal nodig: gebruikers-ID, type (bijvoorbeeld comment_reply), een korte titel en tekst, een link naar de relevante pagina, het aanmaakmoment en het moment van lezen. Een aparte voorkeurentabel bewaart per gebruiker en per type welke kanalen die wil.

Nieuwe notificaties tonen

• Laden bij het bekijken van een pagina en pollen elke 30 tot 60 seconden. Eenvoudig en betrouwbaar.
• Realtime updates met WebSockets of server-sent events voelen direct, maar voegen extra bewegende delen toe. Begin met pollen, tenzij directe updates echt nodig zijn.

E-mailnotificaties

Voor e-mail heb je een verzendprovider en een geverifieerd domein nodig. De details staan in hoe stuur je e-mails vanuit je app. Voor notificaties specifiek geldt:

• Verstuur vanaf de server, nooit met een providersleutel in de browser.
• Bundel drukke gebeurtenissen. "3 nieuwe reacties" in één e-mail is beter dan drie e-mails.
• Bied een dagelijks of wekelijks overzicht aan voor activiteit met lage prioriteit.
• Voeg een afmeld- of voorkeurenlink toe aan niet-essentiële e-mail. De regels voor marketinge-mail verschillen per land; controleer wat voor jou geldt.

Webpushnotificaties

Webpush laat je site meldingen sturen die eruitzien als appmeldingen. Volgens de documentatie van de Push API op MDN werkt het zo:

1. Je site registreert een service worker, een script dat de browser op de achtergrond kan uitvoeren.
2. Nadat de gebruiker akkoord is gegaan, abonneert de service worker zich via PushManager.subscribe(). De browser geeft dan een abonnement terug met een endpoint en versleutelingssleutels.
3. Je server slaat dat abonnement op en stuurt, als er iets gebeurt, een bericht naar het endpoint, meestal ondertekend met VAPID-sleutels (een sleutelpaar dat je server identificeert).
4. De browser start je service worker, die de melding toont, ook als je pagina niet open staat.

MDN wijst er ook op dat het endpoint geheim moet blijven, want wie het kent kan berichten naar die gebruiker sturen.

iPhone en iPad

WebKit heeft Web Push voor webapps toegevoegd in iOS en iPadOS 16.4, met twee voorwaarden uit de aankondiging: de site moet aan het beginscherm zijn toegevoegd, en de toestemming moet worden gevraagd als reactie op een actie van de gebruiker, zoals tikken op een knop Abonneren. Op de iPhone bereikt push dus alleen gebruikers die je webapp hebben geïnstalleerd. Zie native apps versus progressive web apps voor wat installeren van een webapp betekent.

Toestemming goed vragen

Vraag niet al bij het eerste bezoek. Leg eerst het voordeel uit ("Krijg een herinnering een uur voor je les"), en toon de browservraag pas als de gebruiker op een knop tikt. Als iemand weigert, laat de browser je misschien niet meer vragen. Een te vroege vraag kan iemand dus voorgoed kwijtraken.

Geplande notificaties hebben een trigger nodig

"Herinnering 24 uur van tevoren" of "wekelijks overzicht elke maandag" vraagt om iets dat volgens schema draait. Dat is een achtergrondtaakprobleem, dat wordt behandeld in hoe draai je achtergrondtaken. Een veelgebruikt patroon: een externe planner roept elke paar minuten een beveiligd endpoint aan, en dat endpoint verstuurt wat er klaarstaat.

Prompts voor je AI-builder

Begin met in-app:

Voeg in-app-notificaties toe. Maak een tabel notifications (gebruiker, type, titel, tekst, link, created_at, read_at). Voeg een serverfunctie notify(userId, type, data) toe die elke functie aanroept. Toon in de header een belicoon met een aantal ongelezen items, een dropdown met de laatste 20, en een knop "alles als gelezen markeren". Vraag elke 60 seconden naar nieuwe.

Daarna voorkeuren en e-mail:

Voeg notificatie-instellingen toe: laat de gebruiker per type (reacties, vermeldingen, facturatie) kiezen voor in-app, e-mail, beide of geen. notify() moet deze respecteren. Verstuur e-mail via [PROVIDER] met de geheime sleutel [ENV_NAME], alleen op de server. Groepeer reactiemails zodat een gebruiker maximaal één e-mail per 15 minuten krijgt.

Dan push, als je dat nodig hebt:

Voeg optionele webpush toe. Registreer een service worker, genereer VAPID-sleutels en sla de private sleutel op als geheim. Voeg in de instellingen een knop "Meldingen inschakelen" toe die alleen om toestemming vraagt als erop wordt geklikt. Sla elk abonnement per gebruiker en apparaat op, verstuur pushes vanuit notify() als de gebruiker dat heeft aangezet, en verwijder abonnementen die de pushdienst als verlopen meldt.

Veelgemaakte fouten

• Notificaties verspreid door de code. Elke functie verstuurt zijn eigen e-mail op zijn eigen manier, en voorkeuren worden genegeerd. Gebruik één functie notify().
• Pushtoestemming vragen bij het laden van de pagina. De meeste mensen weigeren, en je krijgt misschien geen tweede kans.
• Geen voorkeuren. Gebruikers die storende meldingen niet kunnen uitzetten, zetten ze allemaal uit, of vertrekken.
• Vanuit de browser versturen. Sleutels voor e-mail en push horen op de server.
• Verlopen pushabonnementen niet opruimen. Ze stapelen zich op en verspillen verzendingen.
• Gevoelige details in de tekst van de notificatie. Vergrendelschermen tonen die tekst. "Je hebt een nieuw bericht" is veiliger dan het bericht zelf.
• Geen log van wat is verstuurd. Als een gebruiker zegt "ik heb de e-mail nooit ontvangen", helpen logs met berichten-ID's van de provider je uitzoeken waarom.

Checklist

• Eén notify()-functie aan de serverkant, overal gebruikt
• Notificatietabel met leesstatus, en een bel met een aantal ongelezen items
• Voorkeuren per type en kanaal, gerespecteerd door notify()
• E-mail verstuurd vanaf de server met een geverifieerd domein; overzicht of bundeling voor drukke gebeurtenissen
• Pushtoestemming alleen gevraagd na een actie van de gebruiker, met uitleg
• Push getest op desktop en op een iPhone met de app op het beginscherm
• Verlopen pushabonnementen verwijderd
• Geen gevoelige inhoud in push- of e-mailvoorbeelden
• Geplande herinneringen hebben een betrouwbare trigger

Notificaties in Mythex

Mythex heeft geen ingebouwde e-mail- of pushdienst voor de apps die je bouwt. Je brengt dus je eigen e-mailprovider mee en genereert je eigen pushsleutels, die je als projectgeheimen opslaat. Het in-app-deel heeft alleen de database van het project nodig, die Mythex toevoegt als je erom vraagt. Bouw met prompts zoals hierboven, test de bel en de e-mails in Preview, en test push op je gepubliceerde URL, want service workers en push hebben een echt HTTPS-adres nodig. Het documentatierecept e-mail versturen vanuit je app heeft een startprompt. Mythex documenteert geen geplande taken, dus plan timed herinneringen met een externe trigger zoals beschreven in hoe draai je achtergrondtaken.

Veelgestelde vragen