Notas de quickstart
Cuándo mover tu script del sondeo al stream de caídas
Si tu bucle de sondeo existe para detectar caídas de precio, el stream de caídas ya hace ese trabajo. Las señales de que debes cambiar, y lo que pierdes.
El punto de inflexión es fácil de ver en tu propio código: si tu bucle de sondeo gasta la mayoría de las líneas comparando snapshots consecutivos para encontrar caídas de precio, estás reimplementando una detección que el stream de caídas ya hace. Mueve esa parte al stream. Mantén el sondeo solo para lo que realmente sirve: estado completo del tablero en un horario.
La señal en tu propio código
Abre tu sondeador y cuenta las líneas que no tienen nada que ver con pedir datos. Si la mayor parte del trabajo tras cada respuesta es comparar el tablero nuevo con el viejo, quedarte solo las caídas y aplicar un umbral, tu script es un detector de caídas con un problema de sondeo adjunto. Cada línea de ese diff es código que el stream borra.
La otra señal es el desajuste de cadencia. Sondeas cada vez más rápido para captar los movimientos antes, y cada paso de frecuencia multiplica solicitudes mientras tu tasa de aciertos queda plana.
Lo que el stream te da
Una solicitud HTTP que se queda abierta, y una línea data: por cada lote de caídas igual o superior a tu min_drop, como el quickstart de Python muestra el mismo oyente. La detección ocurre en el lado del feed: la bajada, el umbral y el momento se deciden antes de que la alerta te llegue. Tu código se reduce a parsear, filtrar, reaccionar.
La primera línea que recibes es un objeto de control, y dobla como comprobación de plan: una clave cuyo plan no tiene stream recibe plan_lacks_sse en lugar de alertas, según el mismo quickstart, verificado el 2026-10-03.
Lo que pierdes
El stream solo envía caídas. No te dirá el precio que no se movió, el tablero de un partido que de repente te interesa, o el estado actual tras un reinicio. Si tu aplicación renderiza tableros completos o alimenta un modelo que necesita cada selección, mantén el bucle de sondeo para el estado y deja que el stream maneje los movimientos.
Muchos proyectos acaban con ambos: un sondeador lento para el estado, el stream para los movimientos. La página de precios lista qué planes incluyen el stream y cuáles son solo sondeo, verificado el 2026-10-03, así que la combinación que eliges es tanto una decisión de plan como de código.
La migración en una tarde
Mantén el sondeador corriendo, añade el oyente del stream al lado, y registra ambos durante un día. Cuando las alertas del stream coincidan con los movimientos que tu diff habría encontrado, borra el diff. El código de petición, el manejo del cursor y las rutas de error que ya tienes se trasladan sin cambios.
Sondeo para el estado, stream para los movimientos. El día en que tu lógica de diff desaparece es el día en que la integración se volvió más simple y más rápida a la vez.