gorcon consists of a notable amount of internal parts that need to communicate with each other in order to carry out the main task of managing a game server.
To keep those parts as abstract and general as possible without directly linking them, we need some kind of internal API for them to communicate.
This is the foundation for offering both the rpc based cli interaction as well as external gRPC/HTTP based control of gorcon's functionality through web interfaces and services.
The internal API basically would require a way for all those parts inside gorcon to register their functionality with it and then expose invocation through it.
This means, the API needs to be as general as our services are and offer some kind of internal access path to make finding the required services possible.
In a final state, all functionality should be executed through this channel and after initialization every part of gorcon should solely be called through the API.
Acceptance Criteria:
- Internal API Service for
- Registering Functions to be called by other services inside gorcon
- Calling Functions previously registered via their known access path
- Plug-ability for rpc/gRPC and REST Mappers to later expose this internal API to external services
Open Questions:
- Final API Architecture and Design
- Choice of Implementation (Event Driven?, Sync?, Channels?)
- How to map registered functions
- How to find mapped functions
Steps to the final vision:
To reach the final vision, several reference implementations and experiments might be required. Without trying out several approaches no informed decision can be concluded.
Therefor the suggestion might be to first implement a very basic API Service which get's handed all services it is able to call as pointers and then use this Service inside other parts of gorcon like the cli interface. This way we might get a working implementation at least in some way representing what we need, while keeping it decoupled from other services as well as possible.
This would already be a huge improvement to gorcon-arma which required the used services to provide special functions for exposing them to e.g. the scheduler.
This issue might be subject to further discussion and radical changes in the near future.
gorcon consists of a notable amount of internal parts that need to communicate with each other in order to carry out the main task of managing a game server.
To keep those parts as abstract and general as possible without directly linking them, we need some kind of internal API for them to communicate.
This is the foundation for offering both the rpc based cli interaction as well as external gRPC/HTTP based control of gorcon's functionality through web interfaces and services.
The internal API basically would require a way for all those parts inside gorcon to register their functionality with it and then expose invocation through it.
This means, the API needs to be as general as our services are and offer some kind of internal access path to make finding the required services possible.
In a final state, all functionality should be executed through this channel and after initialization every part of gorcon should solely be called through the API.
Acceptance Criteria:
Open Questions:
Steps to the final vision:
To reach the final vision, several reference implementations and experiments might be required. Without trying out several approaches no informed decision can be concluded.
Therefor the suggestion might be to first implement a very basic API Service which get's handed all services it is able to call as pointers and then use this Service inside other parts of gorcon like the cli interface. This way we might get a working implementation at least in some way representing what we need, while keeping it decoupled from other services as well as possible.
This would already be a huge improvement to gorcon-arma which required the used services to provide special functions for exposing them to e.g. the scheduler.
This issue might be subject to further discussion and radical changes in the near future.