4 ms·
Server push is not like long polling because the connection is shared. You could keep a stream open and push messages as needed. This already sort of is possibl
by Touche 9y ago
Server push is not like long polling because the connection is shared. You could keep a stream open and push messages as needed. This already sort of is possible with fetch in the browser, but iirc there are some things the spec authors are working on for this use case.
- manigandham 9y agoYou can't do much with these assets. These are plain network requests as far as the browser is concerned so there's no API logic for your JS code to use. You're limited to just forcing the browser to download more things and it can also choose to ignore these push requests.
- Touche 9y agoYou can do whatever you want with them. For example, let's say you push /api/todos and your client-side code does a `fetch('/api/todos')`. This stream stays open, and the client code can receive each message as they come in, using ReadableStream. Now the server, having this connection open can later push more data into this /api/todos stream. Boom, you have websockets. Without needing a separate port and connection.
- manigandham 9y agoYou just described long-polling: holding the connection open until the response arrives or it times out. Even if you just send push-promises and push-responses while keeping the original response stalled (and the browser accepts the response), the client-side JS still has no idea what those requests were or what was loaded. SSE is the evolution of long-polling so that browsers already include the logic to keep a connection open with streaming updates so that you can avoid all this in the first place.
- Touche 9y agoThis differs from long polling in that http2 doesn't create a new connection. Also long-polling is request and then response, whereas http2 is (like websockets) full duplex.
- jkarneges 9y agoSmall nitpick: long-polling can be done over http/2, in which case the connection is shared.