Add support for Jackson

[phillip-kruger]

Example com.fasterxml.jackson.annotation.JsonIgnore

[jmartisk]

How, if we're using JSON-B all over the place? :)

[phillip-kruger]

Just use the annotations as markers for certain things. Like ignore. We don't even need a dependency on Jackson

[t1]

Hmmmm... I understand that Jackson plans to support JSON-B. I think the prio of this is not very high.

[wiradikusuma]

Please consider adding Jackson's @JsonView as well, although I'm not sure how does GraphQL support "views"? Different endpoints?

[phillip-kruger]

Hi @wiradikusuma - I am not sure what @JsonView is, or how support would look like. Maybe you can explain a bit more ? If possible refer back to something similar (if exist) in JsonP or JsonB

[wiradikusuma]

Sure.

Context: I use Quarkus, and it uses RESTEasy, a JAX-RS implementation.

Let's say I have 2 REST API endpoints that return the same MyModel but have different @JsonView annotation:

@GET
@Path("/public")
@JsonView(MyView.Public.class)
public MyModel public() {
    return ok(Shared.dummy()).build();
}

@GET
@Path("/admin")
@JsonView(MyView.Admin.class)
public MyModel admin() {
    return ok(Shared.dummy()).build();
}

public class MyModel {
    @JsonView(MyView.Public.class)
    public String username;

    @JsonView(MyView.Admin.class)
    public String secret;
}

public class MyView {
    public static class Public {
    }

    public static class Admin extends Public {
    }
}

When I call GET /public, it will return {"username": "..."} and when I call GET /admin, it will return {"username": "...", "secret": "..."}. Basically, I can create a "fat" model and selectively return the fields by simply annotating them. In my case, I have MyModel table and I don't want public views to see secret column.

I understand that in GraphQL the client/caller can choose the fields themselves, but I don't want the client to even be able to choose secret in the first place! That's why I said maybe we need to be able to expose multiple GraphQL endpoints (one for public, one for admins) so that public endpoints won't even show `secret in its schema.

What do you think?

[phillip-kruger]

Mmm, interesting. We currently support RolesAllowed, but only on top level. Let me sleep on this a bit :) I also think this would be good discussion in the next MicroProfile GraphQL meeting.

Thanks. For now, it's not supported, except with using a combination of RolesAllowed and Source fields.

[t1]

I'd rather use @RolesAllowed etc. to limit access to some fields/methods. As an advanced feature, users should see only the fields they can access... on input as well as on output.

[t1]

I also think this would be good discussion in the next MicroProfile GraphQL meeting.

tomorrow! ;-)

[phillip-kruger]

Nice ! Let's discuss it.

[wiradikusuma]

I use @RolesAllowed as well for my REST APIs, but as @phillip-kruger said, it's too high-level (method level)

@GET
@Path("/admin")
@JsonView(MyView.Admin.class)
@RolesAllowed(ROLE_ADMIN)
public MyModel admin() {
    return ok(Shared.dummy()).build();
}

It also means creating multiple DTOs. Maybe it's not best practice, but it's certainly convenient to have 1 DTO instead of multiple versions of it. Lo and behold, my monstrous DTO:

@Entity // JPA
@Data // Lombok
public class User {
    @Ignore // GraphQL
    @JsonIgnore // Jackson
    private String username;
}

[t1]

We actually just got exactly this requirement: nested @RolesAllowed. Is that a new ticket or should we rename this one?

[phillip-kruger]

Please create a new one