Support schemas in JAR files #98
Comments
|
@paulbakker did y'all ever implement something like this? I'm interested in splitting a dgs app into a multi-module project split by service boundary so there would be extended types we would want to collect and merge in the main application |
|
I'm actually looking into this feature currently. Will post an update on
this thread.
…On Wed, Sep 14, 2022 at 12:18 PM James Baxley ***@***.***> wrote:
@paulbakker <https://github.com/paulbakker> did y'all ever implement
something like this? I'm interested in splitting a dgs app into a
multi-module project split by service boundary so there would be extended
types we would want to collect and merge in the main application
—
Reply to this email directly, view it on GitHub
<#98 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ5JPXMD6FO7BNKDSJ2J5F3V6IQJDANCNFSM42VXQMEQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
@jbaxleyiii we do exactly that, we have a few schemas containing "common" types, which are shipped in JAR files. Both the Intellij plugin and the framework support this if the schema is in META-INF/schema. I don't think we ever added it to codegen, because it is less of a common need. We could bring that up again though. |
|
Gotcha! Any recommendations for setup in a multi-module project? One thing I was considering was having a single schema module that creates the generated code for all schemas sourced in the repo but could be used by other modules but not sure how that would scale. Mainly so since the schema needs to be checked against all other parts for global consistency (i.e. extending a type and not having collisions) so having schemas be part of modules doesn't seem like it would create the ability to do extensions. edit: |
|
For our internal use cases with multi-module projects, we've generally
recommended that code generation plugin be configured for each module
separately with the schemas treated independently. We haven't yet explored
having all the schema in a separate module with the generated code due to
lack of use case. That approach could work I think, but as you mentioned,
it would depend on how large the schema is.
…On Wed, Sep 14, 2022 at 12:53 PM James Baxley ***@***.***> wrote:
Gotcha! Any recommendations for setup in a multi-module project? One thing
I was considering was having a single schema module which creates the
generated code for all schemas sourced in the repo but could be used by
other modules but not sure how that would scale
—
Reply to this email directly, view it on GitHub
<#98 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ5JPXJYUTF4I3UC4OQJPYTV6IUK7ANCNFSM42VXQMEQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@srinivasankavitha how do you handle shared interfaces? typeMapping doesn't allow you to link to the generated interface |
|
The current solution we have is not ideal at all from a devex perspective
(hence the ticket to have the ability to generate types based on schemas in
JAR files). Our federated graph includes a "CommonTypes DGS" that hosts the
schema for such shared types. For code generation purposes, folks end up
downloading that schema from the schema registry to be treated as part of
the local file (purely for code generation). This is then used to generate
common types that are required for code generation. Any common interfaces
are handled the same way.
Having the ability to specify schemas from JAR files for code generation
will eliminate this step and generate all the corresponding types for the
shared/common schema.
…On Sun, Sep 18, 2022 at 5:51 PM James Baxley ***@***.***> wrote:
@srinivasankavitha <https://github.com/srinivasankavitha> how do you
handle shared interfaces? typeMapping doesn't allow you to link to the
generated interface
—
Reply to this email directly, view it on GitHub
<#98 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ5JPXPHZVGURCYOZXKDHJ3V662KNANCNFSM42VXQMEQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Merged this PR: #468 |
At Netflix we ship common types as libraries, with schemas in
META-INF/schema.Currently we can't add these schemas to the code generation configuration, so these types aren't known during generation. This requires a workaround with
typeMappings.Ideally we should also support a mechanism to provide a
typeMappingin the JAR file, e.g. with a mapping file inMETA-INF, so that we can extend the typeMappings based on libraries.The text was updated successfully, but these errors were encountered: