Streaming API

[mithrandi]

I have some code implementing the streaming websocket API which I'd like to contribute, but it probably needs some more cleaning up. Also I used type-level symbols for pairs rather than value-level constants, so the API will probably need to be changed. Filing this so I hopefully don't forget forever.

[tebello-thejane]

Hmm... I only use DataKinds when I need static guarantees. But please do share; we can most certainly adapt it for the library.

And thank you so very much. 😊

[mithrandi]

I'm using https://hackage.haskell.org/package/safe-money in this application, and having the compiler keeping all my different currencies and different precisions (Dense vs Discrete in various scales) straight has been very handy. However, all the symbols are somewhat clunky when you don't care about it so much; probably easier to layer that on top of a lower-level API that doesn't involve them.

Thinking about it some more, the most basic API is one that takes two IO callbacks (one for the initial book, and one for when an update is received); I currently have something that is maintaining the current state of the book in a TVar, but that logic can be separated out making it easier to put other things on top (like the same thing but with plain ol' Rational or Scientific values instead of the Discrete' values I have now).

[tebello-thejane]

Ah! I have a better idea of what you have in mind now!

You're simulating the order book locally, and would like to have changes streamed to you automatically, instead of polling and diffing.

On second thought, the Luno WS API is small enough that it would be a good idea to include it. We must just be careful about how we design it.

First question that pops to mind: what should the interface look like? Should it expose a websockets Connection, or something more general, like a stream (pipes or conduit), or just a simple pair of (T)Chans?

[mithrandi]

What I have at the moment at the bottom is something like this:

runClientOnce :: LunoAuth -> CcyPair -> (OrderBook -> IO a) -> IO b

However I'm converting the book values (in Scientific) to Rational (or actually Discrete currency scale), and it turns out that reconverting the whole book each time is relatively expensive. I think being able to maintain it directly in Rational might be better; and on the other hand some use cases may not be interested in the whole order book like this.

So instead I think the lowest level could be something like:

runClientOnce :: LunoAuth -> CcyPair -> (OrderBook -> IO a) -> (a -> OrderUpdates -> IO b) -> IO c

(Note that the second callback gets to pass a value back to itself, similarly to iterateM_) The logic of maintaining a full book locally can easily be plugged into this, while still allowing other things.

I think the above is also good enough to make a conduit source, a TChan, etc.