Skip to content
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

GraphQL integration #118

Closed
radekmie opened this issue Oct 25, 2016 · 8 comments
Closed

GraphQL integration #118

radekmie opened this issue Oct 25, 2016 · 8 comments
Assignees
Labels
Type: Feature New features and feature requests

Comments

@radekmie
Copy link
Contributor

Note: Created as a successor of this comment in #112.

More and more projects are using graphql, so some kind of integration would be nice. Some research about parsing graphql schemas would be nice (and I'll probably do it in some free time), but further customizations directly in schema might be an overkill.

Ideas? Thoughts?

@radekmie
Copy link
Contributor Author

@radekmie
Copy link
Contributor Author

OK, I have some very basic implementation here. We have few problems to solve, in order to make it real:

  1. How to handle custom scalars?
  2. How to handle IDs?
  3. How to validate plain objects? (some kind of (object + schema) -> mutation + mutation validator)
  4. How to pass initial values?
  5. How to pass additional props?

@serkandurusoy
Copy link
Contributor

https://github.com/kuip/meteor-schema-graphql-bridge could spark some ideas
perhaps

sorry I'm on my phone but I'm really excited about this and will post more
soon!

Sent from my iPhone

On Oct 25, 2016, at 21:48, "Radosław Miernik" notifications@github.com
wrote:

@MacRusher https://github.com/MacRusher @macrozone
https://github.com/macrozone @serkandurusoy
https://github.com/serkandurusoy @zeroasterisk
https://github.com/zeroasterisk


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#118 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEbz3HEmkOSM4LUsilUNnmok021_dzRqks5q3k8XgaJpZM4KgV6Q
.

@radekmie radekmie self-assigned this Oct 26, 2016
@radekmie radekmie added the Type: Feature New features and feature requests label Oct 26, 2016
@radekmie
Copy link
Contributor Author

radekmie commented Oct 26, 2016

There's also graphql-forms. As I looked into the source, they simply ignore custom scalars.

@radekmie
Copy link
Contributor Author

radekmie commented Nov 2, 2016

Here are my conclusions:

  1. GraphQLBridge can't really validate a model because it have no other knowledge than the type of the field and it requireness.
  2. Because 1., you'll have to create GraphQLBridge instance by hand.
  3. Because 1., you'll have to implement your own validation (you should do it anyway, yes?).
  4. Using QuickForm (and other self-generated forms) is making almost no sense because there's no way to provide additional field props in the schema (we could: keep reading).
  5. If you want to have a form with custom scalar type, then you can't rely on AutoField, because it won't guess your field type.

Example:

const schema = new GraphQLBridge(`
    type Author {
        # Label
        id:        ID!
        decimal:   Float
        firstName: Int
        lastName:  String
        posts:     [Post]
    }

    type Post {
        id:     Int!
        title:  String
        author: Author
        votes:  Int
    }

    # This will be used as the form schema.
    type Query {
        posts: [Post]
    }
`, model => {
    if (!model.posts || model.posts.length === 0) {
        // This is just example.
        // Structure inspired by ValidationError.
        throw {
            details: [
                {field: 'posts', message: 'At least one post is required.'}
            ]
        };
    }

    // More validation...
});

Looks good, huh? Now, let's take a look at additional props. We can pass it to the schema, as a third parameter:

const schema = new GraphQLBridge(graphQL, validator, {
    posts: {
        minCount: 1,
        maxCount: 4
    },

    // Again - it's just an example.
    // Notation inspired by SimpleSchema.
    'posts.$.title': {
        placeholder: 'Some creative title...'
    }
});

What do you think? If you think, this will work (and it's enough), then we have it! My experimental bridge is almost it!

But wait, there's more!

If you don't like the idea of passing raw schema to the GraphQLBridge, we can also do it like this:

import {makeExecutableSchema} from 'graphql-tools';

const executableSchema = makeExecutableSchema({...});

// Any type can be passed to the form.
const schema = new GraphQLBridge(executableSchema.getType('Post'), ...);

@serkandurusoy
Copy link
Contributor

Wow, indeed I like the new GraphQLBridge() approach. It looks like a good
balance between flexibility and structure. That being said, perhaps we can
actually look into abstracting the third parameter a little bit such that
perhaps it can accept multiple "schema formats" thus aligning it with your
original vision, right?

On Wed, Nov 2, 2016 at 9:23 PM, Radosław Miernik notifications@github.com
wrote:

Here are my conclusions:

  1. GraphQLBridge can't really validate a model because it have no
    other knowledge than the type of the field and it requireness.
  2. Because 1., you'll have to create GraphQLBridge instance by hand.
  3. Because 1., you'll have to implement your own validation (you
    should do it anyway, yes?)
    .
  4. Using QuickForm (and other self-generated forms) is making almost
    no sense because there's no way to provide additional field props in the
    schema (we could: keep reading).
  5. If you want to have a form with custom scalar type, then you can't
    rely on AutoField, because it won't guess your field type.

Example:

const schema = new GraphQLBridge(type Author { # Label id: ID! decimal: Float firstName: Int lastName: String posts: [Post] } type Post { id: Int! title: String author: Author votes: Int } # This will be used as the form schema. type Query { posts: [Post] }, model => {
if (!model.posts || model.posts.length === 0) {
// This is just example.
// Structure inspired by ValidationError.
throw {
details: [
{field: 'posts', message: 'At least one post is required.'}
]
};
}

// More validation...

});

Looks good, huh? Now, let's take a look at additional props. We can pass
it to the schema, as a third parameter:

const schema = new GraphQLBridge(graphQL, validator, {
posts: {
minCount: 1,
maxCount: 4
},

// Again - it's just an example.
// Notation inspired by SimpleSchema.
'posts.$.title': {
    placeholder: 'Some creative title...'
}

});

What do you think? If you think, this will work (and it's enough), then
we have it! My experimental bridge
https://gist.github.com/radekmie/9c228b5ad55fec927efb768eb0d697e7 is
almost it!
But wait, there's more!

If you don't like the idea of passing raw schema to the GraphQLBridge,
we can also do it like this:

import {makeExecutableSchema} from 'graphql-tools';
const executableSchema = makeExecutableSchema({...});
// Any type can be passed to the form.const schema = new GraphQLBridge(executableSchema.getType('Post'), ...);


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#118 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEbz3JIICFM-P0puHEtS3pkoGeFeBikkks5q6NUpgaJpZM4KgV6Q
.

@radekmie
Copy link
Contributor Author

radekmie commented Nov 6, 2016

Every form is already abstracted from the schema. This logic is placed in createSchemaBridge(schema). The only limitation here is that form have a schema prop - we can't pass multiple parameters in there. I think, that creating the bridge by hand is the best and the cleanest solution.

@radekmie
Copy link
Contributor Author

Good news!

GraphQL support just landed in 1.6.0-beta.1! Go and try it! Bugs reports are welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature New features and feature requests
Projects
Archived in project
Development

No branches or pull requests

2 participants