graphql #50
graphql #50
Conversation
| @@ -43,4 +54,69 @@ public WebClient.Builder webClient() { | |||
| return WebClient.builder(); | |||
| } | |||
|
|
|||
| public GraphQLScalarType localDateTimeScalar() { | |||
There was a problem hiding this comment.
@eyakauleva try to make more elegant solution here
| import org.springframework.stereotype.Component; | ||
|
|
||
| @Component | ||
| public class ExceptionResolver extends DataFetcherExceptionResolverAdapter { |
There was a problem hiding this comment.
@eyakauleva nice solution
since GraphQL always throws 200 HTTP status code it's very inconvenient to show errors to the end user
There was a problem hiding this comment.
@h1alexbel GraphQL still returns 200 HTTP status code. This resolver sets status code only as a field to a response body and also sets custom error message there.
As I found out, it's a GraphQL standard to always return 200 OK in such cases, cause non-200 response codes indicate that some issue occurred at the HTTP transport layer, not the GraphQL layer.
So I'm not sure whether it's a good practice to replace GraphQL HTTP status code and whether it's possible at all.
|
|
||
| @MutationMapping("createUser") | ||
| public Mono<EsUser> create(@Argument final User user) { | ||
| CreateUserCommand command = new CreateUserCommand(user, "Liza123"); |
There was a problem hiding this comment.
@eyakauleva what is the "Liza123"?
| }).build(); | ||
| } | ||
|
|
||
| public ValidationSchemaWiring schemaWiring() { |
There was a problem hiding this comment.
@eyakauleva as far I understand this ValidationSchemaWiring also should be represented as Spring Bean
There was a problem hiding this comment.
@h1alexbel I call this method in another method, then why it should be a bean?
There was a problem hiding this comment.
@eyakauleva for code reuse?
There was a problem hiding this comment.
@h1alexbel but I call this method only once
There was a problem hiding this comment.
@eyakauleva I know, but what about future usages?
There was a problem hiding this comment.
@h1alexbel according to YAGNI principle features should only be added when required
There was a problem hiding this comment.
@eyakauleva YAGNI is about features or FR, not about maintainability, which is NFR
try to design all your classes, methods, functions with maintainability in mind
|
|
||
| @MutationMapping("deleteUser") | ||
| public Mono<EsUser> delete(@Argument final String id) { | ||
| DeleteUserCommand command = new DeleteUserCommand(id, "Liza123"); |
There was a problem hiding this comment.
@eyakauleva the same goes here
close #49