Questions & Feedback + Seed tutorial

[MartinKavik]

Hi @obmarg!

I'm a Seed maintainer. And I think your project has a great potential. That's why I've integrated it into a larger app example while I was writing a Seed tutorial. Cynic-related content starts from this page.

Could you answer a few questions, please?

1. Is it ok to include cynic in that tutorial?
2. What's your plan with this library? Is it an experiment or a serious long-term project?
3. I'll need to write mutations with input objects and I saw related issues in this repo. Do you have an idea when they will be implemented/documented (weeks, months, .. ?)
4. It would be nice if cynic would we able to download a schema by itself. I would use it from build script to download and update schema.graphql.
5. I had problems with a function with parenthesis in a query in your Rust code generator - it fails on something like queryClient(), however queryClient passes.
6. Derive macros require to add serde_json into the app's Cargo.toml. Perhaps it should be included in cynic deps. (?)
7. Link to the cynic repository is hidden under Homepage and more detailed content is missing in the crates.io page. I would point Homepage to https://cynic-rs.dev/ and Repository to, well, repository.
8. As you can see on the referenced Seed tutorial page, I had problems with multiple queries and the Rust generator. It generates conflicting type names. I've resolved it by splitting types related to each query to a standalone module with an ugly name.

Thank you!

[obmarg]

Hi @MartinKavik, thanks for getting in touch. Saw you star the repo a few days ago and got very curious. Definitely a fan of seed - used it for the Rust parts of the generator and really enjoyed it.

I'll answer your questions first, and then have a proper read of your tutorial:

Is it ok to include cynic in that tutorial?

Yeah, please do. Not got round to writing a proper tutorial for cynic myself, so I'm extremely happy that there's something I can point people at if they ask.

What's your plan with this library? Is it an experiment or a serious long-term project?

Good question. Certainly started as an experiment, but I've got fairly into it now. I'm running it in production at work and I'm keen to fill in the missing features, documentation and fix the various rough edges. So farily serious.

I'll need to write mutations with input objects and I saw related issues in this repo. Do you have an idea when they will be implemented/documented (weeks, months, .. ?)

So fixing input object support is next on my list, and I think that's really the only blocker for adding mutation support. Don't want to give too strong a promise, but hopefully in the next couple of weeks.

It would be nice if cynic would we able to download a schema by itself. I would use it from build script to download and update schema.graphql.

Yeah, this is a good idea. I've kind of been making the assumption that people would commit schemas to their repositories but this is not always what you'd want. Have raised #89 so I get round to this at some point.

I had problems with a function with parenthesis in a query in your Rust code generator - it fails on something like queryClient(), however queryClient passes.

I think this is expected: you can only put parenthesis on a field in graphql if you're providing arguments to that field. Or at least that's how most tooling I've used has worked - please correct me if I'm wrong (or I'm misunderstanding the issue).

Derive macros require to add serde_json into the app's Cargo.toml. Perhaps it should be included in cynic deps. (?)

Another good idea - think I'd avoided this as the apps code needs to use serde_json and adding it as a cynic dep wouldn't make it available to the app. Could possibly re-export it from cynic though - I'll have a look into it.

Link to the cynic repository is hidden under Homepage and more detailed content is missing in the crates.io page. I would point Homepage to https://cynic-rs.dev/ and Repository to, well, repository.

😆 yeah - will do, thanks for pointing that out.

As you can see on the referenced Seed tutorial page, I had problems with multiple queries and the Rust generator. It generates conflicting type names. I've resolved it by splitting types related to each query to a standalone module with an ugly name.

Yeah, definitely a lot more work to be done on the generator. For now I see it more as a tool to provide a starting point, rather than something that gives you the exact code you'll want. Deduplicating types is one of the items on #13 although not sure how much that would have helped with your specific case: each of your queries is just different enough to require a different set of structs.

I'd imagined one of the advantages of the cynic approach would be that you could easily share structs between queries (which is basically impossible with the existing graphql-client approach) though maybe that'll always be tricky given how easy graphql makes it to build slightly different types.

From a quick skim I think what you've ended up with is reasonable: is there anything you think I could change to improve your code?

[MartinKavik]

I think this is expected: you can only put parenthesis on a field in graphql if you're providing arguments to that field.

I don't have too much experience with GraphQL - I've written some PRs for Elm and Elixir GraphQL libs and written some Seed examples, but I don't know all GraphQL specs and all supported features. So you are probably right and it isn't a problem, it was just the first "blocker" when I was trying the Rust generator.

is there anything you think I could change to improve your code

Once the cynic is stable enough (i.e. mutations, subscriptions and schema downloader are implemented) I can try to wrap it to a new Seed service to remove some boilerplate from the app code. But I haven't found any ugly APIs while I was writing that tutorial. I'll create an issue when I find something.

Thanks and enjoy the weekend!

[obmarg]

I don't have too much experience with GraphQL - I've written some PRs for Elm and Elixir GraphQL libs and written some Seed examples, but I don't know all GraphQL specs and all supported features. So you are probably right and it isn't a problem, it was just the first "blocker" when I was trying the Rust generator.

👍 There's probably some room for improving the graphql-parser error messages. I've been tripped up by this several times myself, and a rust compiler style fix suggestion would be really nice to have. Though there's a lot of things to do before I'll even think about attempting that 😄

[lunaryone]

What you think about adding discord server for the cynic project?
It would help newcomers (like me) to communicate and participate in project.

[obmarg]

@lunaryone I was just thinking about that last night actually, think it's a good idea. Will try get something set up today

[obmarg]

@lunaryone There's now a discord link in the readme & on the website.

[obmarg]

@MartinKavik I released v0.9.0 of cynic the other day by the way, it includes mutation & input object support along with a few other things from your list. Made a PR to update your guide here: seed-rs/seed-rs.org#83

[MartinKavik]

@obmarg Thank you! I would like to finish that Seed tutorial ideally in the coming weeks. I'll write another batch of questions / feedback or close the issue once the tutorial is done.

[MartinKavik]

Hi, I'm trying to write mutations but there are two blockers:

• Can't write recursive structs because cynic doesn't support pointers (Box, Rc, &..). It can be also problem for InputObject because it requires cloneable properties (why?) and we can't make non-cloneable things cloneable by Rc.

• I don't know how to create/use *Ref types properly. Also they don't implement Debug, Clone or cynic::Scalar so I don't know how should I include them in InputObjects.

See mod mutations in MartinKavik/seed-app-time-tracker@788a6d9 for the example.

[obmarg]

Hi @MartinKavik

I’m on holiday right now (and on my phone) so apologies if this isn’t the most useful response, but:

• Good point about pointer types, haven’t yet considered supporting them. Definitely want to support recursive types so I’ll have a think about how to implement this.
• InputObject needs cloneable properties as an alternative to requiring users to derive clone manually (which I assume would have the same limitations). We need to clone input objects to avoid putting argument lifetimes on cynic::Operations. I tried it at one point and it complicated things more than I’d like. Might be that I need to rethink this a bit in the face of Box etc. though.
• Did the generator put out those *Ref types? Think that might be a bug in the generator actually, I’ll look into it when I get back to my laptop tonight.

[MartinKavik]

Enjoy your holiday!

We need to clone input objects to avoid putting argument lifetimes on cynic::Operations.

I don't know internal cynic requirements, but my intuition just tells me that it shouldn't require Clone. Could we create a new input object lazily when needed instead of cloning? This approach helped us to eliminate many Clone requirements in the Seed API.

Did the generator put out those *Ref types?

I didn't use the generator. I was just trying to follow and resolve compiler errors.

I’ll look into it when I get back to my laptop tonight.

Don't hurry, enjoy your holiday, it can wait 🙂 Thank you!

[obmarg]

Enjoy your holiday!

Thanks! I'm back now, so let me answer your questions a bit better.

Re: recursive type support, I'm going to get on that first. Hadn't considered recrusive types, but seems a pretty essential feature for a GraphQL library. Hoping it won't be too much work, so hopefully land in the next week or two.

I don't know internal cynic requirements, but my intuition just tells me that it shouldn't require Clone. Could we create a new input object lazily when needed instead of cloning? This approach helped us to eliminate many Clone requirements in the Seed API.

Could you point me at an example of doing lazy object creation in seed? I'd be really happy to get rid of the Clone requirement, so any inspiration would be great.

(Feel free to skip this next blob if you want, I'm mostly thinking out loud.) The difficulty here is that I generate code that looks something like this:

fn select_a_field(some_input_object: &SomeInputObject) -> SelectionSet<...> {
   selection_set::field(..., vec![Argument::new(some_input_object.clone())], ...)
} 

That Argument::new call needs to store some_input_object till the point that we want to serialize it. I can see a few ways to do this:

1. Take a reference to SomeInputObject, store that in Argument::new. This works, but means that SelectionSet is tied to the lifetime of some_input_object. I have this implemented on a branch somewhere, and felt that it made the API quite painful to use.
2. Serialize SomeInputObject at the point of building the SelectionSet. I did use this approach at one point, but it didn't feel like the right thing to do.
3. Just make SomeInputObject derive Clone, and then clone it.

Currently I've gone with option 3, though I agree it's not great. May switch back to option 2 if I can't come up with a better solution, as I think supporting Box etc. is probably more important than serializing things in the right place...

I didn't use the generator. I was just trying to follow and resolve compiler errors.

Sorry - I see what's going on now, couldn't quite read your code properly on my phone. I see that the *Ref types are input types in your GQL schema so you'll need to define structs for them and put a derive InputObject on them, similar to the input types you already have. The query_dsl::*Ref types are marker types that cynic uses for enforcing type safety, but you can't really use them yourself. Do you remember how you came across them? Wondering if I can make it harder to stumble across them, or maybe make the documentation a bit clearer...