-
Notifications
You must be signed in to change notification settings - Fork 304
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
Add graphql-dgs-extended-validation module #659
Conversation
8800b98
to
cd974f7
Compare
Awesome @hantsy! Thinking out loud, I suspect a new |
@setchy I may add such a section later. But I am not a English speaker, writing great English docs is more difficult than coding. |
Thanks for the PR @hantsy. We were just recently looking at adding this. Will review and test it out next week.
… On Sep 25, 2021, at 6:25 AM, Hantsy Bai ***@***.***> wrote:
@setchy I may add such a section later. But I am a none English speaker, writing great English docs is more difficult than coding.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
ceae27f
to
dbda4e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @hantsy, did a quick review and looks great. Will take a deeper dive tomorrow.
...validation/src/test/kotlin/com/netflix/graphql/dgs/autoconfig/BeanValidationSizeSmokeTest.kt
Show resolved
Hide resolved
I see this error when I try it with a spring boot app:
You can reproduce it by adding the schema in your test to the |
import org.springframework.context.annotation.Configuration | ||
|
||
@ConditionalOnClass(graphql.validation.rules.ValidationRules::class) | ||
@ConditionalOnProperty( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get rid of this property? Since the functionality is anyway in a separate module, if the user wants to disable it, he can simply avoid adding it altogether. I'd prefer not having too many configurable properties as much as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to agree, but would that make it inconsistent with the how extended-scalars or micrometer (any others???) are configured?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a general approach to enable features in Spring Boot. For example, in the application I need some feature, but in some tests for some specific reason it can be disabled with a property on tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree that this is a general approach. However, for this particular feature, I didn't see a use case for having the module be present but disabled via a property. That said, I am fine with keeping it as is.
@setchy - as you also pointed out, we do have the properties for those features that are already in separate modules. So I agree with your point about consistency as well.
300eda0
to
19c4a10
Compare
Currently I only tried 16.0 in my Dgs example(4.8.3). The hibernate validator added required deps, no need extra settings. The SmokeTest did not report this error(executed on the GraphQl engine only). You can add an extra EL 4.0 dependency and try again. @berngp But from this error, I found another terrible issue. I checked Hibernate Validator 7.x doc, found it was updated to Jakarta EE 9 API level: https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/, but Spring 5 is still aligned to Java EE 8/Jakarta EE 8, does support the new namespace. This maybe cause other issues in a real Spring Boot application. Hope this graphql-java-validation project will release a version variant based on GraphQL 17 and Hiberante Validator 6.2(Jakarta EE 8 level). |
There is an issue reported the problem when using GraphQL 17 and Spring Boot 2.5.5 together, graphql-java/graphql-java-extended-validation#52 |
I think we'll defer this PR until there is a resolution for the above mentioned issue, agree? We just switched the framework to graphql-java-17 and released already. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes works well with the Spring Boot 2.3.x versions that DGS is currently using,
but we will soon be moving to Spring Boot 2.5. There is a blocker on graphql-java-extended-validation
when used along with Spring Boot 2.5, see issue below. For this reason we will have to wait for this PR.
Thanks for the work @hantsy. I was pretty excited to see this! Too bad about the Hibernate Validator issue that seems to be blocking for now. Hopefully that can be resolved in library. |
Thanks to @berngp I found this thread on the Spring Framework that clarifies why this is an issue: spring-projects/spring-framework#25354 (comment) |
@berngp Current Spring only recognizes the Jakarta EE 8 API and ignore new Jakarta EE 9 API at all, so I think if using this validation extension in a Spring Boot 2.5 application, it could work, but there are some Jakarta EE 8 and 9 API coexisted in the final jar. |
@srinivasankavitha Sent a PR on the upstream project, graphql-java/graphql-java-extended-validation#53, the default source codes are switched back to Jakarta EE 8, and currently I used a I would like a different artifactId for the jakarta build(as some Jakarta EE projects used a |
@berngp When adding all the deps (Jakarta EE 9) into build.gradle, the application starts up without any errors. https://github.com/hantsy/spring-graphql-sample/blob/master/dgs-codegen/build.gradle#L26-L32 But it will fail your application, when you are using validation APIs. |
Is there a particular validation mechanism outside of this one adopted by Netflix? |
@sbilello you can use Bean Validation directly. Generally, when using Dgs framework, if you build the models manually, Bean validation is a good match. If you are using |
Yes, @hantsy but I didn't want to remove the graphql-java-extended-validation module. |
@paulbakker There is no response from the upstream maintainers for weeks, if possible create a fork of graphql-java-extended-validation under Netflix? I think only need a Jakarta EE 8 version here. |
Forking would be a bit of a maintenance burden long-term, so I would really prefer to avoid that. I've asked on twitter who's maintaining the repo, hopefully we'll find someone who can merge/release. |
I spoke to Andi today, and he'll look into it after next week. They obviously have a lot on their plate, so let's just be patient. At least we now know the repo isn't abandoned. |
0cd1286
to
c190ecf
Compare
@paulbakker Refreshed and update the version. |
address #640