Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
GraphQL Configuration Options #5782
Not yet tested - this is essentially a functional, but work-in-progress RFC.
Further the discussion here, I have implemented a set of config options that briefly speaking, allow:
Please see the exact configuration in /src/Options/index.js
Internally, the only non-backwards compatible change is due to the introduction of input types,
The one config option that is yet to be implemented is
I welcome comments for improving this PR before I begin working on unit tests!
@omairvaiyani I liked a lot the features you designed. I just wanted to discuss further what is the best way to setup them. I didn't review before because I actually spent the whole day digesting the setup you suggested and trying to think the pros/cons.
I think we need to address 3 things:
So, talking about the first item, I am wondering if it would be better to store the GraphQL options in the database's Schema collection. The advantage of this approach: we could then allow the developer to setup the GraphQL API through the Parse Dashboard. What do you think about it?
@davimacedo I think it's perfectly sensible to stagger the feature flexibility, although internally we may wish to maintain the code paths for future use?
I'll address the potential steps as you've outline above, and then touch on the idea of storing the configuration at the database level below.
The way I've structured the PR, the fields and operations are altered using the custom resolver in Step 2. Currently, only the inclusion/exclusion of classes are provided in a static manner. The PR can be adjusted to instead provide the class-specific configurations as static data as well, though obviously this would significantly increase the Parse Server config file/json maintained by developers.
If we are to make this a separate step, we may have to make Step 1: "Allow developers to include or exclude classes.", and use this step to introduce field and operational type customisation. I am not against this idea, though the manner in which we expose the config (in-memory vs. database) may change the ideal delineation of these steps.
This step is definitely the one to keep last and I would rely heavily on your experience having done this in the past. I've personally not dealt with schema merging before - my idea was to build on the nested nature of the Parse GraphQL schema and allow custom types and operations to live under the user's own namespaces, where
Storing the config in the database
I'll hold off making any further changes to the PR until you've had a chance to digest this, appreciate it's a long one!
So let's go with steps 1 and 2 now and we can address step 3 later.
My idea of step 2 is more in-depth. I was thinking to allow the customization of any type (not only the ones generated from classes) like File, for example. But it can be a step 4.
I loved the idea of
@@ Coverage Diff @@ ## master #5782 +/- ## ========================================== - Coverage 93.74% 93.74% -0.01% ========================================== Files 148 150 +2 Lines 10301 10682 +381 ========================================== + Hits 9657 10014 +357 - Misses 644 668 +24
davimacedo left a comment •
It actually looks pretty good to me. Great job!!!
I've just added minor comments to discuss about. Besides I think it is only a matter of creating more test cases and we are ready to merge. Try to keep at least the same average of test coverage that the project currently has.
@davimacedo @douglasmuraoka I believe the first 3 steps are now complete and ready for unit-tests. I could do with some help here as I'm running into some errors with the jasmine suite. I have not changed any of the settings but am getting this error when I run
referenced this pull request
Jul 12, 2019
@omairvaiyani Nice progress so far! For testing on Postgres in your local machine you need to run
Ignore this comment - problem fixed!
But receiving this error in all the tests:
I do want to crack this so I can be helpful in future PRs given that postgres is clearly a core feature in parse-server, but for this PR, I'm conscious that its going to become more difficult to manage the merge conflicts the longer behind it gets. Could you sub in for me here and work out the failing tests? I'll continue reading up on setting up postgres with parse in the mean time for future PRs!
@omairvaiyani I've just pushed a new commit to your branch merging the latest version of master and fixing some tests due to the change of ClassFields to ClassCreateFields. The PR overall looks good to me. But, since it is a lot of code, I'd love to also hear from @douglasmuraoka mainly regarding the changes in the GraphQL API and from @dplewis mainly regarding the new controller and cache that the PR is introducing to the Parse Server.