N nailer  - 4 months ago
> exposes both a RESTful and real-time API automatically through HTTP/HTTPS and over websockets.
Why not both at once with HTML5 SSE?

M Matthias247 - 4 months ago
I think SSE has two limitations that might not make it too useful for some scenarios:
- Each SSE channel would require a separate TCP connection. And as the connections for a browser are limited, you can not support a lot of of different SSE channels. This is mainly a HTTP/1.1 problem, HTTP/2 fixes this. But as browser and server support for HTTP/2 is still limited you might not bet on it.
- SSE can only send chunks of text in each notification, where the possible payload is additionally limited by the SSE encoding (you can't send text with <br /><br /> in it). So if you need binary or abritrary (JSON?) text objects you would need some additional encoding. Like object -> json string -> byte-array representation -> base64 string. This works, but the overhead for your application (must do the encoding) and the browser (must to all the decoding and look for the <br /><br />) is not ideal.
I'm currently experimenting with using HTTP/2 and fetch API with readable streams to stream arbitrary objects on a bigger number of parallel channels from server to client. This seems to work and looks quite promising for the future, but due to missing browser and partly also missing server support the solution is definitely in it's infancy.
So the current safe bet for enabling lots of notification channels or enabling realtime queries would still be websockets.

D daffl - 4 months ago
That sounds like something worth keeping track of. Do you want to create an issue at https://github.com/feathersjs/feathers/issues for it? The nice thing is that you most likely won't have to change your services when adding a new transport layer.