- Issue created by @donquixote
I see that a new major branch 3.x is in progress, to bring Drupal 11 support.
I wonder if this would be the time to also simplify some of the architecture.
Or maybe this should be done in a 4.x branch, to not delay the Drupal 11 support.
I notice that:
- The JwtTranscoderInterface exposes lots of getters and setters that I would consider implementation details.
- The JwtTranscoder is quite stateful, and also has invalid states where it won't work (if configuration is empty or incomplete, or if it is not initialized yet).
An interface describes what the consumer code can expect from an object that is passed in as a dependency.
The smaller the interface, the easier the service / object is to replace or decorate.
I think there are two relevant methods, encode() and decode().
The rest can be kept out of the interface.
To avoid the statefulness, we could have a transcoder class that receives everything it needs in the constructor.
Then we can have other code that prepares these values from config.
This transcoder itself could be a service, or the service could be some kind of wrapper that takes care of the initialization.
All of this is TBD, for now I just want to open up the topic.
This would impact modules that directly interact with the other methods in JwtTranscoderInterface.
Active
3.0
Code