Increase client coverage, godoc & breaking out into own repo?
decentral1se opened this issue · 2 comments
Something that https://dev.scuttlebutt.nz/#/golang/?id=muxrpc-support-table helped me understand is how few endpoints are supported directly from the https://github.com/ssbc/go-ssb/tree/master/client API bindings (querying stuff over MUXRPC directly in your Go code).
I thought 1) it'd be great to increase the coverage 2) document that code well so the godoc is helpful for developers 3) potentially split that out into it's own repository!
3 is particularly interesting to me because I think removing some of the code from the monorepo could be helpful for maintenance purposes. Working with a client outside of the go-ssb might be an easier entrypoint for development and onboarding also (you can wire up a script which speaks MUXRPC easier than dive into the core...).
Also we get to come up with a cool new name 🙃
Opening to flag my intentions, please raise concerns and/or share thoughts, much appreciated ✌️
Honestly, from the perspective of a newbie to this, at this stage I would disagree. The fact that this is a little more of a monolithic unit makes it much easier to work on than the JS stuff. I never could really get the hang of where all of the code for the JS SSB stuff came from and it seemed like I was just constantly hunting between multiple different barely-documented projects that were all inter-linked in ways I didn't understand. Without a decent overall architectural diagram of everything, it was too much of a hurdle to try to overcome for an occasional developer - it felt like you really had to be part of the "club" already of people that knew everything about every component and how they interact already. Having this project all together in one place made it a lot friendlier to a new developer like myself trying to help rather than having to chase down bugs in multiple sub-packages to fix a bug.
It might make sense to split it up after it's stabilized a bit more, just for ease of reuse as you mentioned. For right now, though, some of the bugs are so bad that a fix for them very well might require changes in several different sub-packages at once.
Thanks for weighing in on this, gonna close for now, makes sense ✌️