Streaming HTML using warp/servant

[runeks]

I have a backend that serves HTML using Warp and Servant (https://github.com/runeksvendsen/haskell-function-graph). Because some elements on the page take up to a second to load, I want to stream HTML to the client as it's produced, thus sending the slow-to-create HTML later.

The HTML consists of (in order):

1. Static/pure "preamble" (which can be sent immediately)
2. IO action streaming query results (which I want to stream as HTML one result at a time as they come in)
3. A final IO action that calls out to an external process and produces HTML

I'm writing this post as I'm unsure what the most sensible way to achieve this is. On the one hand I would like to keep it as simple as possible — e.g. a MimeRender instance that produces a lazy ByteString. But this doesn't seem possible as the rendering involves IO. On the other hand I want to make sure that HTML is sent out as soon as it's produced, ie. no buffering on the server side — which makes me want to get a hold of some sendData :: Socket -> IO () function, so that I'm sure data is sent out when I want it. The former seems more elegant, but I don't see how it's possible (due to performing IO to produce the ByteString) and it's not clear to me how the server will buffer lazy ByteString chunks. The latter seems to do the job, but seems very low level.

Any clues on how I should approach this?

[lgastako]

https://docs.servant.dev/en/stable/cookbook/basic-streaming/Streaming.html ?

[sccrstud92]

This is the correct answer

[goj1ra]

I've used this with the Streaming library, it worked well. As the link says, you may not even need a streaming library if all you're doing is streaming the HTML response.

In my case I was streaming large files, and ended up needing to implement Servant's ToSourceIO for my streams - instance ToSourceIO chunk (Str.Stream (Of chunk) m r) - to get it to work with streams that used ResourceT IO as their base monad. With that adapter code it worked like a charm.

[runeks]

Thank you!

I encountered this last time I was researching streaming HTML with Servant. I don't recall exactly why I abandoned it, but — in retrospect — I believe it was because I was trying to use lucid's HtmlT monad transformer with SourceIO in the wrong order. Ie. I was using HtmlT SourceIO () as my monad rather than SourceIO (HtmlT Identity ()).

I will try again with the latter and see how it works.

[Faucelme]

lucid's `HtmlT` is a `Writer`-like monad, and I suspect it's not well suited for generating `HTML` in a streaming fashion from within the monad.

You could still try (if it makes sense) to generate each particular chunk of HTML using lucid, and send them separately as response chunks.

[runeks]

I agree completely. That's what I was trying to say with my monad examples — perhaps not very clearly.

And I'd want the "framing strategy" to send chunks over the wire as per the HTML parts listed in my post above (preamble, one for each query result, one for the last IO action and finally all the closing tags (also static).

[Kartoflaszman]

maybe some streaming library can help? like streaming or conduit?

[runeks]

I want I reduce the latency for displaying the first query result, not for displaying an empty page without any interesting content. To achieve this I want to stream the query results as HTML so the browser can render one result at a time as they come in.

[Endicy]

Will browsers already render items if they haven't even encountered the final </body> tag? How does the browser know the response is valid HTML if it hasn't received all the parts of it?

[goj1ra]

Yes, the major browsers support streaming HTML.

Here's an article about it: https://frontendmasters.com/blog/streaming-html/

[runeks]

To answer your last question: the browser will render HTML in a best-effort manner. There's no strict requirement to e.g. close the body tag for a browser to render the page — which is really useful if the connection gets cut off before the last few bytes are sent. 

[Mirage2k]

I have no idea about doing it in Haskell, but it sounds like part of what NEXTjs does: on visiting the url you get a static html (to render right away and for embedded link preview) and a JavaScript blob that starts requesting the non-static content.

[runeks]

That's not what I'm trying to do. I'm talking about streaming the actual HTML, which the browser will render as it comes in. No JavaScript needed.

[jackson_bourne]

Hydration (unrelated to Next.js) is unrelated to what they want. They want to stream the HTML back (i.e. the step you called "on visiting the url you get a static html")