Azure

fetch-event-source

TypeScript2020–2025

Azure / fetch-event-source

fetch-event-source

A better API for making Event Source requests, with all the features of fetch()

Systems & Infrastructure DevOps & Cloud

Explore on GitHub Read Hacker News discussions

5Distinct people

5Mentions

0Explicit recommenders

2.9KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A better API for making Event Source requests, with all the features of fetch()

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year5 dated mentions

Observed mentions: 2020-09-26 17:03:44 UTC to 2025-01-05 12:16:46 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	3	3
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1

What Hacker News says

5 sources

CharlieDigital·Jan 5, 2025

Not sure about the default `EventSource` object in JavaScript, but the Microsoft polyfill that I use (https://github.com/Azure/fetch-event-source) supports `POST` and there's an option `openWhenHidden` which controls how it reacts to users tabbing away.

In Back to basics: Why we chose long-polling over websockets

ekojs·Sep 22, 2024

EventSource is really really limited. However, you can instead use Fetch via something like https://github.com/Azure/fetch-event-source to consume SSEs.

In How streaming LLM APIs work

sudodevnull·Apr 20, 2024

Since v0.8.0 more users have been hitting the edge cases, which is great news. Majors changes are.. * More verbose errors [still small](https://bundlephobia.com/package/@sudodevnull/datastar@0.12....) though * `text/event-stream` relies on a modified version of [Azure's fetch-event-source](https://github.com/Azure/fetch-event-source). They handle errors and chunking better than I was. New version has been tested out to 4 billion fragments rendered on a single page with no errors. * Actual spellchecking examples and docs * Brand new getting started guides provided by community, thanks [LiamGaudy](https://github.com/LiamGaudy) and [rphumulock](https://github.com/rphumulock)! * SSE helpers for Go no longer have external deps * `data-merge-store` renamed to `data-store based on community feedback` * More relaxed resolution of store expressi

Read the rest

ons will make it easier to handwrite * Back-end examples for setting up SSE * Every github issue has resulting in more examples * Fetch indicators handle transitions and settling better * View transitions API integration smaller and simpler to use * More essays I think HTMX is wonderful and if you start getting into more complicated UIs where fine-grain signals and a more robust plugin framework makes sense please give it a try!

In Datastar v0.12.0 (Htmx+Alpine Alternative)

makkesk8·Mar 18, 2024

Someone at Azure thought of this[1] [1] https://github.com/Azure/fetch-event-source

In WebSockets vs. Server-Sent-Events vs. Long-Polling vs. WebRTC vs. WebTransport

vishwams·Sep 26, 2020

Websocket is definitely a superior abstraction, but the main problem with it is that a lot of corporate firewalls/network proxies don't know how to handle the upgrade request and drop the connection. We took a dependency on Websockets a few years back and while everything worked fine in the US, a lot of our customers in Asia/Europe simply couldn't access some of the core functionality of our site. The Server-sent-events/EventSource API _seems_ like a better fit for GraphQL subscriptions because it's one-directional traffic anyway, but in addition to the issues you mentioned above, you'll also run into the 2000-character limit most browsers have for URLs [1]. The browser's EventSource constructor does not let you specify request bodies so you're forced to put everything in the URL, which is _not_ suited for the graphql queries which tend t

Read the rest

o get pretty large. I ended up writing an alternate EventSource parser using the fetch() api [2] to get around this limitation. Happily, there seems to be two alternate approaches in the pipeline that seem more robust/better supported: 1. The proposed @defer graphql directive [3] recommends using multi-part HTTP as the standard transport layer, so hopefully all the tooling like GraphQL Playground will support a single-request-multiple-response scenario over plain HTTP 2. For scenarios where we need interactive, bidirectional communication, the proposed WebTransport API [4] seems to solve some of the issues with websockets. [1] https://stackoverflow.com/a/417184 [2] https://github.com/Azure/fetch-event-source [3] https://www.apollographql.com/docs/react/v2.4/features/defer... [4] https://github.com/WICG/web-transport

In Deprecate GraphQL Subscriptions over WebSockets in Favour of SSE/EventSource API