search

irufus / gdax-java

Java based wrapper for Coinbase Pro (Formerly known as GDAX API and Coinbase Exchange API)
MIT License
177 stars 131 forks source link

Package separation #28

Closed jbaconsult closed 4 years ago

jbaconsult commented 6 years ago

This is a great project and helps me a lot, thank you very much for all your work. Still I would like to make a small proposal: after checking out it is a bit difficult to separate the actuall API packages from your own application. Maybe you can create an com.irufus.gdax.app package and move all the code that is not the actuall api over there? That would be awesome.

Kind regards Johannes

irufus commented 6 years ago

@JohannesBayerAlbert Could you elaborate on the difficulties that you have had with being able to distinguish the API packages?

jbaconsult commented 6 years ago

Well if we take a look at com.coinbase.exchange.api we find several things: a lot of packages containing the actual REST-Api, but also: a main-Application, a GUI, a GUI-Model and several services implementing the actual communication. From a software architectural view I would recommend to not only separate the different thins in different packages but even several projects. This is mainly because different things have a different focus, they have a different lifecycle and they have different implementation strategies. This pattern is called separation of concerns and is widely used and actually anticipated by most developers.

So for example: One project containing only the REST-Template and entities in the com.coinbase.exchange.api-Domain. This project should have no business logic at all. It is a representation of the REST-ressources one would find looking at the Coinbase/GDax-API documentation. The second project would be the main communication project (like com.irufus.coinbase.service). The idea of the separation is, that you can easily change the communication implementation without touching the api! And the third project could then be the GUI-Implementation (f.e. com.irufus.coinbase.gui). And since you already have a spring boot project up and running it would be a nice idea to create your own web application that one could use, to controll the coinbase-api.

What do you think about that idea?

irufus commented 6 years ago

Basically you're not saying that it is difficult to separate the api. You're just providing feedback because you saw @robevansuk's order book gui within the library. I left it this way on the merge temporarily as I'm trying to work through the issues and get the project more organized.

jbaconsult commented 6 years ago

Yeah you could say that. I was only a bit surprised finding everything in one place. If you need some help, hit me up!

robevansuk commented 6 years ago

the Gui is only activated if you enable it in the config. Initially the gui.enabled parameter is false. I take your point though. Was hoping by committing it someone would ask about it and help finish it off - no such help as yet though! I'm looking into resolving the issues with it and thing I have the right terminology / approach to fix it very soon. Valuable because when the exchange web interface goes down, the API (back end) often remains live ... wanted it to be available for further development.

robevansuk commented 4 years ago

Gui has now been removed due to a lack of tests and difficulty maintaining it alongside other changes. The codebase is now more modular and I'd like to look at publishing library/jar artefacts to maven next. This should hopefully resolve this issue.