Try out tokens #631
Draft
Try out tokens #631
Conversation
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This is a quick example of what a token implementation might look like. It was mostly mechanical however the most interesting changes where to BoxService, and all the middlewares that have more than one backing service (I gave up entirely with balance as it's current structure just doesn't work with this form of Token).
The most interesting takeaway I had is that currently you can only get one "Token" at a time per Service instance, which means that services can store readiness state in the service itself; with a Token you have to store readiness in the token as you can give out more than one at a time. That forces tokens to allocate if the number of backing services isn't known at compile time.