2.0.x Roadmap

[bmoscon]

Continued from the 1.9 roadmap:

• more tests + code coverage
• Performance metrics code + published results
• Integrate in orderbooks C module (completed)
• Integrate in new Cython Classes for all the datatypes returned to user (completed)
• Revamp REST endpoints. They have been integrated into the main exchange classes but issues remain (lots of code duplication, some missing basic endpoints)
• Add async REST endpoints (completed)
• Documentation Overhaul

[mchangun]

I would love some examples on how you would structure an application to use cryptofeed. You have alluded a few times in other threads that it is up to the library user to design the overall application, but I think many of us would greatly benefit from some simple examples. E.g. setup a 'good design' to process the feed and then have another process consume the market data and send simple TWAP buy orders at the mid price.

[bmoscon]

at some point I'd like to go into more detail about that (i.e. in the docs) but there are too many higher priority things in the way. You can take a look at cryptostore, which does some of these things already if you want to look at some other code as a guide

[ibmua]

Please, when you're making code-breaking changes, first make relevant examples / fix the existing examples, such as with the case of "book" method. My guess is that 80% of usefulness of cryptofeed for it's users is in book updates, but since the updates to book updating methods the examples range from low usefullness, because they show only basic functionality of the new undocumented "'order_book.SortedDict' object" which looks completely unpythonic (at least with current level of documentation), total pain to work with and simply not a good choice, to ones that just don't work, such as https://github.com/bmoscon/cryptofeed/blob/master/examples/demo_kucoin_authenticated.py , demo_gemini_authenticated.py , demo_existing_loop.py .
(More examples don't work, I just listed ones that have the book update method that doesn't work.)

Would also help if there was a doc on code-breaking changes that would also include instructions on adapting old code to the updated library. First should come the docs, then the changes. Not vice-versa.

If that sounds like too much work, maybe, avoid making breaking changes so often, especially when they don't improve functionality.

[bmoscon]

thanks for pointing out those issues. I deleted some of the superfluous examples and fixed a few others.

In general, I'll probably never have time to write up documentation that pertains to differences between versions. I'm one person working on this, and I don't get paid to do it, and there just isn't time. There are other contributors of course, but there haven't been many that have contributed long term, so I'm mostly on my own here. There should be better documentation around the new Cython data objects, so I will need to add that and I will try and do so in the short term. You of course do not need to use the SortedDict, you can call the to_dict() method on it and receive a normal (in sorted order) python dictionary.

[ibmua]

Ok, thanks, will use to_dict(), please, do add it to examples.

[bmoscon]

yep - already did that :) https://github.com/bmoscon/cryptofeed/blob/master/examples/demo_existing_loop.py#L31

[bmoscon]

@ibmua - what about allowing the user to build the library using either the python sortedcontainers or the existing sorteddict, or allowing them to control that at runtime (via some sort of kwarg to the exchange object). Would either work for you?

[ibmua]

For me personally to_dict() is enough.