code-first stitched schemas #11
Conversation
|
HA, this is awesome! Actually fits well with an idea I had to write a subservice somewhere in Ruby that pops the JavaScript bubble. |
|
In the example, there are 4 services. I have one vanilla GraphQL JS, second nexus, third I was planning was TypeGraphQL.... Anything you want for fourth service from my end? I think venturing out of JS/TS is a bit beyond my reach, my though is to leave in fourth service for you to possibly convert to a different language? |
|
Nope, those are great! We can merge when you’re ready a polish from there. Leaving the fourth service as-is is fine for now. Will have to see how complex a different language gets on the package management front. |
yaacovCR
changed the title
accounts is now world's first code-first stitched schema using graphql-js
to do:
= convert a service to TypeGraphQL
= convert a service to nexus
= convert a service to...
= simplify type merging configuration to only use simple keys -- as this example is not meant to showcase the more coplex options
= fix the awkwardness with `{ stitchingDirectives: directive } = stitchingDirectives()`
|
Guess I'm done! |
|
ok, now i'm really done. related: Both TypeGraphQL and nexus allow to use specify directive data either natively or via extensions, but they do not let you setup actual new directive definitions. This is not so great, primarily because custom directives might exist in queries, and should really therefore be able to be defined in every schema. Relevant: graphql/graphql-js#1343 Discussion above is about directive usage, but i think all agree that custom directive defs should be possible in every schema framework -- it's certainly possible in graphql-js. Workarounds are to use extendSchema after using these custom frameworks to add in typeDefs. Or -- to have the gateway turn off validation of the subschema SDL. These notes are included within the comments within the implementation. |
|
Ha, you’d be horrified at the support for custom directives in ruby.
Working through it now and it’s really janky. Holiday tomorrow, will
probably merge at the end of the weekend. Thanks for putting it together!
…On Thu, Dec 24, 2020 at 6:50 PM Yaacov Rydzinski ***@***.***> wrote:
ok, now i'm really done.
related:
MichalLytek/type-graphql#351
<MichalLytek/type-graphql#351>
graphql-nexus/nexus#148
<graphql-nexus/nexus#148>
Both TypeGraphQL and nexus allow to use specify directive data either
natively or via extensions, but they do not let you setup actual new
directive definitions.
This is not so great, primarily because custom directives might exist in
queries, and should really therefore be able to be defined in every schema.
Relevant: graphql/graphql-js#1343
<graphql/graphql-js#1343>
Discussion above is about directive usage, but i think all agree that
custom directive defs should be possible in every schema framework -- it's
certainly possible in graphql-js.
Workarounds are to use extendSchema after using these custom frameworks to
add in typeDefs. Or -- to have the gateway turn off validation of the
subschema SDL.
These notes are included within the comments within the implementation.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFRRODJJL4GP3L55QJFTC3SWPHTZANCNFSM4VERPQSQ>
.
|
accounts is now world's first code-first stitched schema using graphql-js!
inventory is now world's first using nexus!
products is now world's first using TypeGraphQL!