-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] New configuration parsing model to manage everything with Symfony services #1072
Comments
Progress updates:
I work on tests passing. |
Progress updates: So, plans:
|
And I would like to consider namespaces changing of new configurations packages.
@mcg-web How do you think? |
@mcg-web Why are generated types defined as services? I see that it is the initial idea, but what are the main pros of it now? As I can see, this is only for injecting them together with all other types defined in any bundle. If it so, I'd like to refactor this part. It permits to avoid getting of the service |
@Vincz |
Hi @Aeliot-Tm! |
Hi @Aeliot-Tm! Are you still working on this? I'm planning to dedicate a bit of time working on it. Did you commit what you did somewhere? |
I creates this issue to have single place to collect information about the new model of the parsing and caching of GraphQL types configs. As I know, the work was started by @Vincz and this was discussed and validated by @mcg-web at the time. But I cannot find comprehensive information about it to help with the finishing of the work. The code base only.
So, below is the information collected so far.
It would be nice when somebody provide me more information.
The common API
At the moment, the configuration parsers parse configuration and generate an array of config. This array of configuration is then validated with a Yaml configuration.
The idea of the new way to do it, is to describe an API. This API describe a schema (all the classes under https://github.com/Vincz/GraphQLBundle/tree/master/src/Configuration).
The various parsers are considered as
ConfigurationProvider
. We don't know how they work, we just want them to generate aConfiguration
.For example, the Metadata parser (https://github.com/Vincz/GraphQLBundle/tree/master/configuration/GraphQLConfigurationMetadataBundle) will use annotations and attributes to generate this Configuration object while the YAML parser (https://github.com/Vincz/GraphQLBundle/tree/master/configuration/GraphQLConfigurationYamlBundle) will read a YAML file to generate this configuration.
So if we want to create a new type of Parser or whatever service that can generate a Configuration object we can.
We do not duplicate anything. The parsers currently in https://github.com/Vincz/GraphQLBundle/tree/master/configuration will be distinct packages, and we install only the ones we want.
An other advantage of doing it this way, is the ability to use various type simultaneously (like YAML + Annotations for example) and use type of others parsers. It is not possible with the current version.
Use a service
With the current version, the parsing is part of the cache warming process. It prevents us from using all Symfony services related stuff. The idea of the new configuration is to manage everything with Symfony services and to generate the Configuration object when it's needed (and cache it). You can check here https://github.com/Vincz/GraphQLBundle/blob/master/src/Resources/config/configuration.yaml for the declaration of the main
Configuration
object. It is generated by theConfigurationProvider
using all configured providers.You can check the latest version by @Vincz here : https://github.com/vincz/GraphQLBundle
And my work it here: https://github.com/Aeliot-Tm/GraphQLBundle/tree/dynamic_config_parsing
The text was updated successfully, but these errors were encountered: