𝗘𝗲𝗻 𝗲𝗲𝗳𝗼𝗱𝗲𝗹𝗶𝗷𝗸𝗲 𝗹𝗶𝘃𝗲 𝗰𝗵𝗮𝘁 𝗵𝗲𝗲𝗳𝘁 𝗱𝗲𝘇𝗲 𝗿𝗲𝗹𝗲𝗮𝘀𝗲 𝗯𝗶𝗷𝗻𝗮 𝗱𝗼𝗲𝗻 𝗺𝗶𝘀𝗹𝘂𝗸𝗸𝗲𝗻

Een basis live chat-systeem heeft mijn laatste release bijna verpest.

Het klinkt simpel. Je laat gebruikers in de buurt zien en laat ze met elkaar praten. Maar de technische realiteit is veel complexer. Ik moest de live chat koppelen aan geolocatie en een beoordelingssysteem. Dit zorgde voor enorme complexiteit onder de motorkap.

De architectuur:

• Frontend: React en TypeScript. • Backend: Node.js met Express en WebSockets. • Database: PostgreSQL voor gebruikers en beoordelingen. • Cache: Redis voor actieve sessies en aanwezigheid.

Het geolocatie-probleem

Gebruikers matchen op basis van locatie is niet eenvoudig. Ik moest rekening houden met veel randgevallen:

  • Het opslaan van breedtegraad en lengtegraad.
  • Het gebruik van Postgres-extensies om afstand op te vragen.
  • Het omgaan met gebruikers die locatiepermissies weigeren.
  • Het beheren van verouderde gegevens wanneer een gebruiker beweegt zonder de app te openen.

Als ik dit opnieuw zou doen, zou ik de locatieverzameling scheiden van het matchen door middel van verschillende services.

De realiteit van live chat

WebSockets bieden real-time functies, maar ze brengen ook chaos met zich mee. Ik gebruikte Redis pub/sub om berichten tussen verschillende servers te versturen.

De moeilijkste onderdelen waren:

  • Het opschonen van verbindingen wanneer gebruikers onverwacht worden losgekoppeld.
  • Voorkomen dat berichten naar kamers worden gestuurd die een gebruiker al heeft verlaten.
  • Het afhandelen van herverbindingen zonder ghost sessions te creëren.

Ik heb geleerd dat een formele state machine beter werkt dan het gebruik van simpele flags.

Het beoordelingssysteem

Beoordelingen lijken triviaal totdat je ze bouwt. Ik moest het volgende waarborgen:

  • Gebruikers kunnen niet twee keer dezelfde sessie beoordelen.
  • Beoordelingen worden snel geaggregeerd voor profielweergaven.
  • Gegevens blijven consistent in de hele app.

Ik gebruikte unieke constraints op sessie-ID's om duplicaten te voorkomen en cachede de gemiddelden om de prestaties te verbeteren.

Geleerde lessen

Als ik dit vandaag opnieuw zou bouwen, zou ik drie dingen veranderen:

  1. Splits het matchen en de chat in aparte modules.
  2. Gebruik expliciete modellering voor de status van WebSocket-verbindingen.
  3. Voeg vanaf dag één betere logs en metrics toe voor de chat en het matchen.

Software bouwen is een reeks kleine beslissingen. Deze beslissingen bepalen of je systeem schoon of kwetsbaar is.

Heb jij een live chat of een matchingsysteem gebouwd? Wat zou jij anders doen?

Bron: https://dev.to/jaeger974/simple-live-chat-almost-sank-this-release-2pn7