After few hours of playing with framework, it's quite clear for me that graphcool.yml file is growing quickly when you add new custom functions and permissions settings.
I think it'd soon become harder and harder to maintain.
I think it'd be great to have some kind of 'small' config files (eg. in the same folder as custom mutation files itself) and then to 'merge' all of such configs together.
Consider you have new resolver function. You create folder for it in path/to/my/function and create 'small' graphcool.yml config there that define schema and resolver files location.
Lete on in root graphcool.yml you'd simply do something like:
functions:
- "path/to/my/function" #note its folder, not file
- "path/to/my/function2"
It'd keep same domain code 'closer' and reduce risk of remaining 'dead' config. Also, in case of removing/modifying such function, there is only single place of 'source of truth'. It also could be recursive, so you could potentially have big modules of your apps represented by single line of code in root config file that would be very handy to enable/disable
yaml-with-import can only be used in code. If you really want this, you could use https://github.com/alexlafroscia/yaml-merge. You have to run it to merge your yaml files before executing any graphcool commands though.
What about name collisions? Is it a reliable way to import multiple .yml files? I wonder if that mechanism really lets you scale your app without risks.
It would be really awesome if we could define our own modules by just creating a new folder and writing a local .yml file, being each module a small, simple 'service'.
@pie6k commented on Fri Oct 27 2017
After few hours of playing with framework, it's quite clear for me that graphcool.yml file is growing quickly when you add new custom functions and permissions settings.
I think it'd soon become harder and harder to maintain.
I think it'd be great to have some kind of 'small' config files (eg. in the same folder as custom mutation files itself) and then to 'merge' all of such configs together.
Consider you have new resolver function. You create folder for it in
path/to/my/functionand create 'small'graphcool.ymlconfig there that define schema and resolver files location.Lete on in root
graphcool.ymlyou'd simply do something like:It'd keep same domain code 'closer' and reduce risk of remaining 'dead' config. Also, in case of removing/modifying such function, there is only single place of 'source of truth'. It also could be recursive, so you could potentially have big modules of your apps represented by single line of code in root config file that would be very handy to enable/disable
What do you think about that?
@eruby94 commented on Fri Oct 27 2017
I haven't done this personally, but there is a package that claims to handle something like this: https://www.npmjs.com/package/yaml-with-import
@kbrandwijk commented on Fri Oct 27 2017
yaml-with-importcan only be used in code. If you really want this, you could use https://github.com/alexlafroscia/yaml-merge. You have to run it to merge your yaml files before executing any graphcool commands though.@benseitz commented on Mon Nov 13 2017
I would also enjoy splitting the graphcool.yml It quickly gets to big and confusing.
@albertoblaz commented on Mon Nov 20 2017
What about name collisions? Is it a reliable way to import multiple .yml files? I wonder if that mechanism really lets you scale your app without risks.
It would be really awesome if we could define our own modules by just creating a new folder and writing a local .yml file, being each module a small, simple 'service'.