Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

(Relay) connection codegen #752

Closed
MichaelMure opened this issue Jun 20, 2019 · 6 comments
Closed

(Relay) connection codegen #752

MichaelMure opened this issue Jun 20, 2019 · 6 comments
Labels
accepted enhancement New feature or request

Comments

@MichaelMure
Copy link
Contributor

MichaelMure commented Jun 20, 2019

What happened?

I had a shower-thought.

What did you expect?

Nothing really, but it happened anyway.

Stop having fun, what is this about ?

Ok, here it goes. In my project (https://github.com/MichaelMure/git-bug), I implemented a Relay-compliant set of connections using a code generator (genny). It works but it's a bit crude, in particular because I have to feed it the type of everything (node, edge, connection) and also because I'm not an expert in code generation. It seems to me that gqlgen would be a much better place to do this, because the types are already known and there is a codegen infrastructure.

Here is some pointers to how it works:

There is two types of connections, one that directly paginate the source and one that lazy-load (paginate a list of identifier and load only what is useful). The template is the same, the difference is what data is given to it from the resolver and the implementation of the "connection maker".

Normal connection: https://github.com/MichaelMure/git-bug/blob/master/graphql/resolvers/bug.go#L22-L51
Lazy-loading connection: https://github.com/MichaelMure/git-bug/blob/master/graphql/resolvers/repo.go#L18-L78

Is that something you would consider ? I can relicense my code to MIT if that helps.

@MichaelMure MichaelMure changed the title connection codegen (Relay) connection codegen Jun 20, 2019
@vektah
Copy link
Collaborator

vektah commented Aug 19, 2019

Its something we've been wanting to express via plugins for a while - #228

@stale
Copy link

stale bot commented Oct 18, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 18, 2019
@stale stale bot closed this as completed Oct 25, 2019
@MichaelMure
Copy link
Contributor Author

MichaelMure commented Oct 25, 2019

:-O

@cliedeman
Copy link

cliedeman commented Oct 26, 2019

@MichaelMure I was also interested in this and tried to implement some relay specific codegen.

I thought of 4 ideas that could be implemented

  • Automatically add Node interface (Can be done with Add possibility to hook into modelgen plugin #897 )
  • Automatically decode and encode Relay ID's (Still investigating this)
  • Generate a node retrieval stub (Still investigating but not that useful)
  • Generate Relay connections (Implemented a working version and then decided against it)

After creating a PR with some of the work #851 I managed to get relay connection codegen working but I was not entirely happy with the result. The gqlgen parser will error if any types are missing. E.g. an example I have seen a different graphql implementation:

ships(first: Int, after: String): ShipConnection @connection(for: "Ship")

This fails with gqlgen because the ShipConnection type does not exist. You then have to do something along the lines of this:

ships(first: Int, after: String): ShipConnection @connection(for: "Ship")
type ShipConnection {
  dummy: Boolean // Can't create empty type
}

This is very clunky and probably not worth it.

I then came across this project https://nexus.js.org/ and have decided to try a different approach. Generate the full schema and all relay types with nexus and then feed the resulting schema into gqlgen.

I haven't looked too closely if #851 needs to modify resolvers, but if it is only modifying the schema that can also be done at schema generation time.

Ciaran

@vektah vektah reopened this Oct 27, 2019
@stale stale bot removed the stale label Oct 27, 2019
@vvakame vvakame added the enhancement New feature or request label Dec 25, 2019
@vektah vektah added the accepted label Feb 5, 2020
@frederikhors
Copy link
Collaborator

frederikhors commented Feb 26, 2020

@MichaelMure any news on this?

@MichaelMure
Copy link
Contributor Author

MichaelMure commented Feb 26, 2020

I'm not working on that.

@ermik ermik mentioned this issue Jul 18, 2020
@frederikhors frederikhors converted this issue into discussion #1900 Feb 4, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
accepted enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants