As we experimented, we have this incoming import cycle issue* between api and systemservices, systemservices/* packages. We currently use methods from api package inside system services and because of this, we’re not allowed to call methods of systemservices inside api pkg.
I’m not sure if this is an actual issue? It shows us that either we have a design issue or we don’t have a design issue and calling system services inside api pkg is not right anyway.
As I’m experimenting, I think that this is not an issue and we shouldn’t call methods of system services packages inside api package at this point.
Here is the reason why:
The idea behind of having api pkg is to have a single point of entry for accessing functionalities that core provides by combining low level internal packages. So it’s the api package that where we should interact with core, not the other internal packages. The api package is meant to be a wrapper for functionalities of core with a high level api.
To me, having the systemservices manager and its siblings (systemservices/*) shares the same idea with the existence of api package. We should treat systemservices like how we treat api package. systemservices/* packages are the wrappers around system services, like the api package being wrapper for internal pkgs of core. Remember when we talk about splitting parts of api pkg into smallar pkgs under api/*? It is the similar idea of having systemservices/*. So api pkg and system services pkgs are in the same level.
The idea of having system services is splitting core to smaller services in the first place. And this causes the same effect on api package. We required to move some methods of api package to different system services. Of course, splitting the whole core/api package into smaller system services may not be possible because at least for now we required keeping some logic like deploying services inside the core itself.
I’d like to give an example over Workflow System Service:
Let’s say that we’re not going to implement this workflow feature as a separate service but embed it in the core. In this case we were probably create an internal package called core/workflow, have some implementation there and expose this functionality with core/api package. This way intergace/grpc/core pkg can call methods like CreateWorkflow() from api package and expose this feature to network.
As a system service point of view, first, we’re going to have a mesg service as equlivent of core/workflow. Second, we’re going to have a high level wrapper for it under systemservice/workflow and this is the equlivent of code that we put under core/api for workflow. In this case, as third and last, intergace/grpc/core pkg will call the CreateWorkflow() method from systemservice/workflow.
Please note that it’s totally ok for system services pkgs calling methods from core/api because it’s the native part of core that we do service deploying and listening tasks etc. So calling api pkg inside systemservices is a valid approach. In future, if we can make it possible splitting all the parts from api package to different services then we can directly use the api package as a place where we connect all the system services together and expose them as high level features of core like we do today. But since we’re not able to do it in once, I think, it’s acceptable for now to have this two headed dragon.
As a proposition, I think we can rename the api package to something called like native and create a new api package to call methods from native and systemservices. System services pkgs will call the methods from native pkg anymore, not the api. By time, we’ll move all the logic from native pkg as system services and native pkg will get deleted.
This is just a perspective that we can think about it. Let’s have a starting point from here to discuss and see how system services and core will evolve together.