Blog

Meer inzicht in data door gebruik van RabbitMQ en Amazon Lambda

Apps tonen door middel van push notificaties berichten aan de gebruiker, ook op het moment dat de app niet wordt gebruikt. Om dit tot stand te brengen werkt E-sites vrijwel altijd met Firebase Cloud Messaging (FCM). Dit is een gratis dienst van Google waarbij gebruikers zich met de Firebase SDK eenvoudig op topics abonneren. Voor apps die slechts een aantal topics hanteren, is FCM een hele goede oplossing. Voor de applicatie van Voetbal International is E-sites afgeweken van deze standaard push notifications service. Nieuwsgierig naar de oplossing en het effect ervan? Lees dan snel verder!

Amazon SNS is de oplossing voor Voetbal International

Als een gebruiker geabonneerd is op een topic, wordt er bij belangrijk nieuws een pushbericht gestuurd. Bij het versturen van zo’n notificatie, zorgt FCM ervoor dat deze naar de juiste gebruikers gaat. Het nadeel van FCM is dat het weinig tot geen inzicht biedt in verstuurde notificaties, geabonneerde apparaten op bepaalde topics of überhaupt het aantal topics. FCM is een goede oplossing als een applicatie maar een klein aantal topics hanteert. Maar als er meer inzicht en controle gewenst is, biedt dit niet het gewenste resultaat.  

Dat het bij de Voetbal International-app om 300.000 actieve gebruikers gaat, maakt het implementeren van push notificaties net even anders. Deze casus werd een interessante uitdaging. In deze app abonneren gebruikers zich op een onbeperkt aantal topics, waarvan deze ook nog eens uit een x-aantal subcategorieën bestaan. Door de complexiteit, de hoeveelheid topics en het feit dat VI inzicht wil krijgen in de gebruikersaantallen en de topic registraties heeft E-sites gekozen voor Amazon. In het bijzonder voor haar Simple Notification Service (SNS). SNS is vergelijkbaar met FCM, maar biedt volledige controle en inzage. In het dashboard wordt duidelijk hoeveel topics er zijn, hoeveel apparaten er zijn geregistreerd en op welke topics gebruikers zich abonneren. Kortom SNS was dé oplossing voor de VI-app.

Meer controle door SNS

Bij de meest simpele implementatie van SNS, registreert een gebruiker zich via de app automatisch bij SNS. Bij het abonneren op een topic, gaat dit verzoek ook rechtstreeks van de app naar SNS. VI werkt met een eigen CMS om artikelen in de app te plaatsen. Aan een artikel zit een push notificatie gekoppeld. Op het moment van opslaan, stuurt E-sites de notificatie naar SNS, die hem vervolgens naar de juiste gebruikers verstuurt.  

Tot zover gaat alles goed. Alleen de VI app heeft maar liefst 300.000 gebruikers en SNS heeft hiervoor te lage limieten wat betreft het aantal registraties op topics per seconde.  Dit betekent dat wanneer teveel gebruikers zich op hetzelfde moment abonneren op topics, deze registraties daardoor verloren gaan. Daarom is er besloten om de app requests via de API van E-sites te laten gaan en zo door te sturen naar SNS. Op deze manier is er meer controle over het aantal requests dat per seconde naar SNS wordt gestuurd. Ondanks dat dit meer controle geeft, moet de gebruiker van de app wachten op de respons van de API. Vanaf dit punt komt RabbitMQ in beeld.

E-sites werkt met RabbitMQ

RabbitMQ is een ‘messaging broker’, dat wil zeggen dat het verantwoordelijk is voor het ontvangen van berichten vanuit het ene systeem om deze vervolgens door te sturen naar het andere systeem. Hiervoor worden berichten in een wachtrij (queue) geplaatst, waarvoor RabbitMQ verantwoordelijk is. De queue is volledig persistent, wat betekent dat berichten nooit verloren gaan. De berichten in de wachtrij worden afgehandeld door zogeheten ‘consumers’. Een queue kan meerdere consumers hebben. Handig als de wachtrijen oplopen, want dan kan het consumer-aantal worden verhoogd.

Voor het VI-project maakten we gebruik van drie verschillende queues. Een voor het abonneren op topics, de volgende voor het versturen van de push notificaties en daarnaast nog een voor het batchen van deze notificaties. De apps sturen automatisch een request naar de API wanneer een gebruiker zich abonneert op een topic. Dit bericht wordt vervolgens in de ‘topics:subscribe’ queue geplaatst. Omdat het bericht wordt ingeschoten in de queue, krijgt de app meteen een respons van de API. Wachten op het daadwerkelijke request, van de API naar SNS, hoeft dus niet meer.

Registraties tegelijk afhandelen

Afhankelijk van het aantal consumers, worden berichten na een aantal seconden opgepakt door een SubscribeConsumer. Deze haalt de benodigde data uit het bericht, zoals de gebruiker van het apparaat en topic. Vervolgens stuurt de SubscribeConsumer een request naar Amazon SNS om het apparaat te abonneren op het topic. Door meerdere consumers in te stellen, worden er veel registraties tegelijk afgehandeld. Zo blijf je toch onder de limiet van aantal requests per seconden dat SNS toe staat.

Op het moment dat er een pushbericht uitgaat, wordt er ook automatisch een bericht in de queue geplaatst. Dit schetst twee scenario’s. In het eerste scenario wordt een notificatie gestuurd naar het topic ‘articles’, die vervolgens naar alle gebruikers gaat die nieuws willen ontvangen. VI heeft echter ook de mogelijkheid om teams te koppelen aan een artikel, zodat een push notificatie ook gestuurd wordt naar gebruikers die nieuws willen ontvangen van team A en/of team B. In het eerste geval hoeft er maar één request aan Amazon plaats te vinden om een notificatie naar een topic te versturen. Het tweede geval vereist extra filtering omdat het niet wenselijk is dat een notificatie tweemaal naar hetzelfde apparaat gaat als een gebruiker geabonneerd is op beide teams.

Geabonneerd op meerdere topics - wat gebeurt er dan?

Het tweede scenario, waarbij wordt gecontroleerd of de gebruiker geabonneerd is op topic A óf B, is iets uitgebreider. SNS kan deze filtering niet uitvoeren, dus wordt dit in de API van E-sites gedaan. Hierdoor kan de notificatie niet meer per topic worden verstuurd, maar dient dit per apparaat te gebeuren. Als de doelgroep te groot wordt, kan het versturen van een notificatie daardoor erg lang duren. Om dit te voorkomen is er een ‘notifications:batch’ queue in het leven geroepen. De consumer achter deze wachtrij is verantwoordelijk voor het filteren van de apparaten aan de hand van topic A of B. Deze apparaten worden vervolgens in groepen van 1000 ingeschoten in de ‘notifications:send:news’ queue. De SendNewsConsumer zorgt er daarna voor dat het nieuws wordt verspreid. Door hiervoor meerdere consumers in te zetten, worden er veel groepen tegelijkertijd op de hoogte gebracht.

Amazon Lambda voorkomt lange wachtrijen

Als het te lang duurt voordat een notificatie wordt verstuurd, blijven er teveel in de queue hangen. Maar ook dit probleem is afgevangen. Amazon Lambda stelt je in staat om code uit te voeren zonder het opzetten van servers. Je schrijft de code lokaal en upload deze als een Lambda functie. Deze functie was in dit project verantwoordelijk voor het versturen van de notificaties per apparaat. De consumer achter de ‘notifications:send:news’ queue, stuurt dus nu de lijst van apparaten met de inhoud van de notificatie naar de Lambda, die vervolgens via SNS de notificatie per apparaat verstuurd. Zo maken we gebruik van de kracht en snelheid van Amazon en zorgen we ervoor dat de queue niet vol raakt.

 

RabbitMQ inzetten voor meerdere doeleinden

Voor Voetbal International heeft E-sites RabbitMQ ingezet voor het versturen van pushberichten en het abonneren hierop. RabbitMQ wordt ook gebruikt voor andere doeleinden. Denk hierbij aan alle acties, waarvan het resultaat ervan niet direct aan de gebruiker hoeft te worden getoond. Zoals het versturen van e-mails aan een grote groep ontvangers, het verwerken van statistieken of het synchroniseren van data tussen twee systemen.

Op zoek naar de juiste ondersteuning voor jouw applicatie?

Vraag jij je af welke ondersteuning geschikt is voor jouw app? Wij brengen alles in kaart en onderzoeken wat het beste geïmplementeerd kan worden. Op basis van dit onderzoek brengen wij een voorstel uit. Wil je graag aanvullende informatie op dit blogartikel? Neem dan contact op met ons!