Server-Sent Events in Remix (feat. Moishi Netzer)

[@こんにゃく-n7t]

This is exactly what I've searched for. Using Remix's fetcher.submit, emitting event handler, and listening to updated data with hooks are the elegant solution when making AI Chatbot streaming while using server actions.

[@alfonsocartes]

What a star Moishi! Great video guys! Brooks keeping it interesting always!

[@moishinetzer]

Appreciate that Alfonso! Thanks for the support! Hope you're keeping well

[@MrKeliv]

Wonderful feature of Remix. I love Remix

[@burakcanavc]

I'm surprised with every new video. You are incredible.

[@sihoonkim1502]

I wonder if the loader runs twice, for the client that does the action. I think the loader would run once when action completes and one more time when it receives the event. For a simple optimization, maybe we omit to send event if that client caused the action. I think u could do this by including some sort of session info (userId) in the emitter part in action. Then in the stream route, u can compare that userId with the userId u get from the request. If they are the same, then dont send it to the client!

[@aniforprez]

damn this was fantastic! loved the video

[@mammothoff]

This is crazy 🔥

[@benediktaslaboga3510]

Keep good work guys 🎉

[@jodwbe]

Im just loving this framework more and more. Been using it for my own projects. 💪🏽

[@busbritt]

Great job guys 👍

[@TEMISsX]

It's super cool ! So easy to make it works with Remix ! I'm going to use this at work 💪

[@MonoMario89]

great video! very informative. I was trying to set up this very same flow but I couldn't. Now I know how to do it and removing the need of a WebSocket. Nice

[@gogdarag]

Great video. Remix is ❤

[@jpkontreras]

gold content remix is the future imo

[@Ewooy]

Great talk, thank you. But I am curious how would you tackle horizontal scalability (where 2 clients are potentially connected to 2 different servers). Also I'm not familiar with serverless environments, will there be the same issues?

[@moishinetzer]

Good questions! To sync multiple servers/serverless you would need some kind of common denominator between them. In practice this means hooking your project up to a centralised Redis Pub/Sub or my personal favourite a kafka instance. When events are triggered intead of emitting to the emitter, you enqueue a message or publish to an "events" topic. After that, you create a subscriber/consumer that when it receives a message on the "events" topic it emits to the EventEmitter, this works because now every client connected to every server receives the message from that servers' emitter. It looks something like this: Server 1 Server 2 ... Server N | EventEmitter | EventEmitter | EventEmitter | | | +---------+ +-------+-------+ +----------------------------+ | | | | v v v v +--------------------------------------------------------------+ | Central Message Broker | | (Redis Pub/Sub, Kafka, etc.) | | - Publishes to "events" topic | | - Receives messages from all servers | +--------------------------------------------------------------+ | ^ | | +--+ Emit/Enqueue Messages

[@yarapolana]

Would be great to have short video on polyfills for edge environments so we can use libs like cloudinary/some ai libs on edge

[@ashneilroy]

Amazing!

[@Greybph]

That is awesome

[@theldentity]

this is pretty fucking cool! 😻

[@sihoonkim1502]

Actually although API wise SSE is not bidirectional, networkwise couldnt we say SSE is "bidirectional"? cuz action, loader and SSE all share the same http connection with http2,3 So not only is SSE simple, handles reconnection out of the box, but also no added network cost!