You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Once it's finished, I will publish an RFC for it. The notes are just to write down my thoughts.
applejag
changed the title
Create unidirectional communication between API ↔ providers
Create bidirectional communication between API ↔ providers
Sep 1, 2021
applejag
changed the title
Create bidirectional communication between API ↔ providers
Fix communication between API ↔ providers
Sep 1, 2021
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 iver-wharf/wharf-provider-azuredevops#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.
The text was updated successfully, but these errors were encountered: