applejag
commented
3 years ago I've started drafting the architecture for this over at https://iver-wharf.github.io/wharf-notes/hide-providers-behind-api
Once it's finished, I will publish an RFC for it. The notes are just to write down my thoughts.
Currently providers can talk to the API, but not the other way around. We want to change that.
Most providers support checks/statuses that can reject PRs and such (see https://github.com/iver-wharf/wharf-provider-azuredevops/issues/5)
The previous attempt was to solve this with a message queue (see https://github.com/iver-wharf/messagebus-go) just to get around the circular-dependency issue. This has since been concluded as overkill.
What we instead can do is use dependency-inversion, where we create a standardized API for the providers that they have to fulfill, and then the main API can talk to them through this standardized interface. By doing this, we can also let the main API do all the redirection of endpoints so the end user does not talk to the provider/import APIs directly, and by doing that we can populate the data that the providers get as well, such as the project name when the user only provided the project ID.
This needs an RFC. Especially regarding how this standardized API should look. If we stick to REST or transition over to an asyncronous protocol like gRPC or websockets is up for discussion. Personally (from @jilleJr's perspective) I find gRPC the most enticing.