Support for server-sent events (EventSource)

[adamchel]

Introduction

Server-sent events are a standard W3C-specified and WHATWG-specified feature that supports processing real-time events from a server over an HTTP text streaming protocol.

All modern browsers (except Edge) have supported this feature for years, and for Edge it is a feature request with 6.7k votes.

There is no support in React Native, nor could I find any open issues for it. I believe React Native should have built-in support these types of streaming requests just like it supports fetch and WebSockets.

The Core of It

The introduction covers the gist of the issue and the proposal, but I will also point that while there are existing polyfills for this feature, they are not sufficient, and I think built-in support is the best solution. Below, I've outlined why I think the existing polyfills are insufficient.

Existing Polyfill 1 : eventsource

With 4.9M weekly downloads, this is the definitive EventSource polyfill and it works well on browsers and Node.js, but unfortunately it uses the node standard library, which is not supported by React Native.

[16:03:52] The package at "node_modules/eventsource/lib/eventsource.js" attempted to import the Node standard library module "url". It failed because React Native does not include the Node standard library. Read more at https://docs.expo.io/versions/latest/introduction/faq.html#can-i-use-nodejs-packages-with-expo

Existing Polyfill 2: react-native-event-source

This library specifically supports React Native with its EventSource implementation, but it is based on a polyfill that wraps XmlHttpRequest, which is not optimal for network streaming.

The polyfill does work, but it doesn't have much usage, and it doesn't play nicely with the default jest configuration for react native (see jordanbyron/react-native-event-source#14). I shouldn't have to run through a lot of hoops to test code using such a basic networking feature.

Existing Polyfill 3: react-native-eventsource

A new version of this polyfill hasn't been released in two years, it appears to have only 2 weekly NPM downloads, and it uses native modules, which makes it infeasible to use in simple Expo-based applications.

Discussion points

1. EventSource is a standard web feature that is supported well by most browser environments, and well supported by a polyfill in the Node.js environment. As it is a text streaming protocol, it is also relatively straightforward to implement. For this reason I believe it should be a first-class citizen in React Native networking just like fetch and WebSockets. See Networking in the React Native docs.

[elicwhite]

The main question I always have for proposals like this is why does this feature need to be in core vs a 3rd party library?

[kelset]

(for reference: #83)

[adamchel]

I see in the other discussion referenced that @cpojer says that the "current focus is to reduce the surface area instead of adding to it."

I understand this concern when it comes to non-standard libraries or features that don't exist by default in other JavaScript environments. Redux for instance is an example of a library I would completely agree should remain as a 3rd party library and be out of core.

However,EventSource as I have pointed out is a standard web feature specified by W3C and WHATWG, is well documented by MDN, and is natively supported by browsers.

React Native includes the fetch and WebSocket APIs in core, and your docs even reference the MDN documentation: https://facebook.github.io/react-native/docs/network, (though React Native doesn't support the Streams API for fetch, which would make building a third-party library for EventSource a lot easier).

I'd like to hear from @TheSavior and @cpojer on why they believe EventSource is different from fetch and WebSockets in that it doesn't deserve to exist in the core library.

In my opinion, when JavaScript environments like React Native choose to exclude standard features like this, it further fragments the already messy JavaScript ecosystem, making it a lot more difficult to build universal JavaScript libraries that work across platforms.

I work on a third-party library that intends to support React Native among other platforms (MongoDB Stitch JS SDK), but we've run into many issues along the way with platform-specific bugs and feature gaps, and we've had no choice but to package React Native-specific, Node.js specific, and browser-specific libraries that sit on top of a platform-independent JS codebase that abstracts away features that aren't natively supported by all those environments. Fortunately we have the time and resources to do that, but many independent library developers do not.

If React Native doesn't intend to support features like EventSource, I think it would help library developers a lot if you make your intentions clear on which subset of the standard browser JavaScript ecosystem you intend to support and which you do not.

[cpojer]

Hello @adamchel,

thank you for bringing up this issue. I think @TheSavior's question is a good one, and as you pointed out yourself we are actively trying to reduce the surface area of React Native.

In terms of which standards we intent to support, I think it is too early in the lifetime of React Native to settle on any one standard. However, keep in mind that we are not attempting to build a standards compliant web browser, so we will likely never match features in modern browsers exactly. Absent of having a standardization process or spec to follow, I think we should include features that the majority of people will find useful. This is also why fetch and Web Sockets are available in React Native. I don't think at this time we can claim that server sent events are similarly important to a large amount of users.

I do think the best course of action is to either go with eventsource or react-native-event-source. If eventsource expects a url module, maybe we can make that a separate package and support it from React Native? If we were to go with solution 2, I'm pretty sure we can figure out how to make Jest work with it.

Even if we were to consider including this into core at some point in time, it would most likely be an additional plugin that people would have to enable. This is why I'd prefer to help improve the ecosystem around React Native – if some extensions get significant traction, we should consider shipping them by default.

[adamchel]

Thanks for your input. I really appreciate the quick responses on this. I totally understand that you don't want to clutter the core React Native library with things that most people won't find useful. I'll offer two more counterpoints but I'm getting the sense that you'd prefer we use and improve a third-party library before you'll consider including this in core 😃.

As for your point on

we should include features that the majority of people will find useful. This is also why fetch and Web Sockets are available in React Native. I don't think at this time we can claim that server sent events are similarly important to a large amount of users.

Server-sent events are more more widely used than you might think. The most popular eventsource polyfill has 4.9M downloads on NPM. Meanwhile, the most popular libraries for fetch have 5.5M downloads for the browser polyfill, and 6.9M for the Node.js library. The most popular WebSocket library for Node.js has 9.9M downloads. Yes, you're right that fetch and WebSocket are more widely used, but eventsource is popular on a similar order of magnitude.

My second point is that as far as I know, there is no native mechanism for simple HTTP streaming in React Native, whether it's via EventSource, or the new fetch Streams API. If there were, then it would be very straightforward to implement EventSource as a third-party library without resorting to a hacky wrapper over XmlHttpRequest.

Are there plans to implement the fetch streaming API in React Native, or is WebSocket going to be the only way to natively do streaming? As this StackOverflow discussion shows, there is value in a simple low-overhead one-way streaming protocol. It makes server implementations a lot simpler, and browsers already support consuming the streams.

[elicwhite]

In general I think there are three approaches we could take:

Add this functionality to core
Link a 3rd party module to core by default
Recommend using a 3rd party library in your app

The problem with adding this functionality to core is that we aren’t the experts on this behavior. You really don’t want us to be the gatekeepers for this code. It would move too slowly and not get the attention it deserves. I think one thing you are really asking for in this issue is for Facebook to step in and create a high quality eventstream library because the existing 3rd party ones aren’t good enough. I think it is way less likely that we’d create a good one in core than the community could band together and create a good one themselves from the people who care most about this behavior.

The second approach, linking a well supported 3rd party library by default is more interesting as it would enable the community to iterate freely and then a compatible library would be linked. However, the major downside to this is that it bloats React Native for everyone, including those who don’t use it. We want to decrease the size required by React Native apps and the way to do that is to enable apps to easily add what they need.

This leaves us with the third approach, the one we have today. Use a 3rd party library in your app to add the functionality you need. I think this is likely where we’ll stay on this due to the reasons outlined for the other approaches.

[adamchel]

@TheSavior thanks, that makes a lot of sense. My last question then is, what about implementing the Streams API for fetch? (Usage example here)

Network streaming isn't something that you can just easily implement with a third-party library on top of the network primitives that exist in React Native today. You need more low-level access to the networking, which the existing fetch API in React Native doesn't support. To me, that's the biggest thing getting in the way of creating a high-quality eventsource library without resorting to native modules.

[dkaminsky]

Agreed with @adamchel, if you don't think it's appropriate for you to provide native/bundled eventsource or equivalent, implementing Streams API for fetch would be the minimum needed for the community (or us) to create a workable solution that doesn't rely on XHR.

If you won't implement the standard, please expose the primitives needed for others to do so.

[elicwhite]

I’m not sure what is involved in making that happen but that makes some sense to me.

[adamchel]

@TheSavior would you prefer if we opened a new proposal in this repo for supporting a low-level networking API and/or the fetch streams API? Or should I edit this existing one to reflect that?

And I also just wanted to clarify why we believe XHR is not sufficient. XHR doesn't let you clear the incoming streamed response buffer as data comes in (more context here). This means that as data comes in and your application processes it, it can't clear the buffer without starting a new XHR, which defeats the purpose of streaming data. This has implications for mobile devices, where if you have a long-running stream of data, memory use is going to shoot up unless you restart the stream.

The EventSource library react-native-event-source that works on react native currently implements streaming by where the new incoming bytes (or new events) are retrieved by taking the substring of the partially buffered response from the XHR that the EventSource hasn't seen yet (see https://github.com/jordanbyron/react-native-event-source/blob/master/EventSource.js#L68). What ends up happening is that you store a whole lot of buffered response data that is no longer necessary after those bytes are processed. We can implement our library with this non-ideal solution for now, but long-term we'd love to have access to networking primitives that will allow us make a better React Native EventSource library.

[adamchel]

As for what needs to be done to make this happen, I'm not too familiar with the React Native source code, but from some light perusing, it seems like the low-level RCTNetworking API (https://github.com/facebook/react-native/tree/master/Libraries/Network) can support streaming, the mechanism for doing so just needs to be exposed.

Interestingly, you implement fetch using the whatwg-fetch polyfill (source here) which just sits on top of your XmlHttpRequest implementation. whatwg-fetch does not support the Streams API because XmlHttpRequest doesn't support streaming. It would probably be a lot of effort on your part to implement the Streams API since you'd actually have to implement all of fetch as well, and I'd understand if you wouldn't want to go down that route.

The low-level RCTNetworking API does seem to support incremental data load:

• https://github.com/facebook/react-native/blob/4148976a83ab96029de1b26b515ff95d3cb58c10/Libraries/Network/XMLHttpRequest.js#L338
• https://github.com/facebook/react-native/blob/1151c096dab17e5d9a6ac05b61aacecd4305f3db/Libraries/Network/RCTNetworkTask.m#L170
• https://github.com/facebook/react-native/blob/1151c096dab17e5d9a6ac05b61aacecd4305f3db/Libraries/Network/RCTNetworking.mm#L519

If Facebook were able to expose a simple request API using RCTNetworking that allowed us to receive data incrementally without keeping the entire response in memory as data comes in (which the XmlHttpRequest implementation does), I think that would be sufficient for us to implement a React Native EventSource library that meets our needs.

[elicwhite]

Thanks for the investigation! I’d recommend repurposing this discussion.

I think we are probably open to the idea of exposing some hooks to RCTNetworking but I wouldn’t expect us to have any bandwidth to make that change. The best way to probably make this happen is to investigate the smallest technical changes to core necessary to enable what you need to happen in user space and make sure that is of reasonable scope to be worth sending a PR or if we need to expand the discussion first.

Does that make sense and seem reasonable?

[adamchel]

I think that sounds reasonable. When we have the bandwidth (probably sometime in the next few weeks), I can work on producing a PR to create the necessary hooks.

As far as scope goes, I'm imagining two possible approaches:

• Implementation of a SimpleStreamRequest JS class in https://github.com/facebook/react-native/tree/master/Libraries/Network that wraps RCTNetworking to support HTTP requests that receive a chunked stream of data instead of a single response body. This wouldn't be following any existing standards, such as the fetch Streams API (since it would be significantly more work), but I think it would simple enough for us to build on top of, and it could also be useful for anyone building applications or libraries that want to make use of simple one-way HTTP streaming. We could build a third-party EventSource library that would exist on top of this SimpleStreamRequest.
• Implementation of an EventSource JS class in https://github.com/facebook/react-native/tree/master/Libraries/Network that wraps RCTNetworking to support the EventSource standard. The advantage of this approach is that we are implementing a standard web feature, and not bloating the React Native core with a non-standard network primitive like SimpleStreamRequest. EventSource is itself a very simple protocol that could probably be written with ~200 lines of code directly wrapping RCTNetworking. The XHR wrapper for EventSource is about 200 LOC: https://github.com/jordanbyron/react-native-event-source/blob/master/EventSource.js

Whatever we end up producing, whether it is SimpleStreamRequest or EventSource, we'd expose it in React Native user land via https://github.com/facebook/react-native/blob/master/Libraries/Core/setUpXHR.js.

I personally would prefer the second approach since it's more standard, but would love to hear your thoughts. We wouldn't want to start any work on this unless we know you'd be open to accepting a PR with the approach we go with.