Proposal: Extract main package logic into a dedicated function #931
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The main function of the main package that builds the krakend binary contains too much logic, witch makes it a bit harder for users to build krakend by themselves. This commit extracts the orchestration done by the main function into `krakend.Main`. This way, the main package is greatly simplified, making it easier for clients to build the krakend binary.
|
As a side note, I could recall other toolings that have a similar approach: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the use case for the company I work for, the krakend plugins are built in docker.
The final artifact used for deploying krakend is a docker image containing the krakend binary plus the custom plugins. So in this scenario, I could have a better control of dependencies versions by building both krakend and my custom plugins together.
As an example of how this could be useful, we have an internal library that we would like to use in our custom plugins. However, that library had defined OTEL version to 1.29, and we couldn't use it because the krakend binary has it fixed at 1.28.
We would probably have 2 options for this. The first one could be building krakend by ourselves, making it sure that both the plugins and krakend share the exact same version, by building them together and putting them in the same go module. The second approach would be downgrading the dependency specification in our internal library.
The second option imposes a challenge, because those are 2 different repos, so we reached for the first one (buildling both the plugins and krakend together).
To make this possible, all we had to do is copy/sync the contents of main.go. But this involves making sure that our "main.go" version is always compatible with future versions of krakend.
By moving that logic into an importable function, this process is greatly simplified.