Alternative event stream mechanisms

Aperta
  • Qualcosa non va?
#245 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
api, backend

Direzione di ricerca

L’issue non indica file né test; inizia individuando il sistema Webhook esistente, i meccanismi degli eventi annunciati e i payload JSON delle notifiche. Confronta gli approcci proposti long-poll e WebSocket opzionale con i casi d’uso elencati, quindi definisci il comportamento dell’API scelta e i relativi criteri di completamento.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Context
The current Webhook system is, in my opinion, not the ideal solution for event notifications, for several reasons:

  1. they require clients that are addressable/reachable from the server
  2. they are hard to use for short-lived clients
  3. they add potential security hazards (like documented)
  4. they are difficult to use in a fault tolerant way

To 4. In reality a client would often have to poll the webhooks endpoint to check for errors and potentially handle missed pieces of information by itself (e.g. missed segments)

Description
Introduce some other event mechanism that avoids the pitfalls mentioned above.
E.g. what about a long-poll mechanism:

  1. The client sends a flow-request with it's latest timestamp or (metadata) version
  2. The server only responds once the timestamp/metadata differs from what the client sent

Basically similar to Consul blocking queries
Way easier to implement on the client-side and would even work in the browser. Would also be super useful for one-off notifications.

or an optional websocket mechanism (potentially better suited for multi-flow events). Could probably use the same json payloads like the existing notifications and would just need a type of registration query/payload.

Use Case

  • eliminate issues outlined in Context
  • enable more clients that depend on live-data to avoid polling

I assume you have already thought about alternative mechanisms as the service can explicitely advertise them.

Lingua principale
Makefile
Stelle
117
Fork
13
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bbc/tams

Tutte le issue di bbc/tams

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.