1

I´m having a relative complex, hierarchical data model in my Spring application and I need to query it as well as update all entities by letting the client pass the changed entity to the server.

Using GraphQL for querying solves exactly my needs, but to enable update and create capabilities however, I´d need to duplicate all my entities as *.graphqls files won´t support using "type" elements as "input" elements.

For the newly created Input element, I´d need to define a Java Object matching it too.

For queries I´d end up with

Portfolio.java

@Entity
public class Portfolio {

   @Id
   private int id;

   private String name;

   ....

}

and portfolio.graphqls

type Portfolio {
    id: ID!
    name: String

    ....
}

But for updates I´d end up with

Portfolio.java

@Entity
public class Portfolio {

   @Id
   private int id;

   private String name;

   ....

}

PortfolioInput.java

@Entity
public class PortfolioInput {

   @Id
   private int id;

   private String name;

   ....

}

portfolio.graphqls

type Portfolio {
    id: ID!
    name: String

    ....
}


input PortfolioInput {
    id: ID!
    name: String

    ....
}

type PortfolioMutation{
    updatePortfolio(input: PortfolioInput):Portfolio
}

My problem with that is, I need to keep 4 entities in sync with their fields now, just because GraphQL does not allow using the type as input and I´d need to do that for many other entities as well.

Is there any other solution, or do people go the extra mile and accept the additional complexity, or do you simply switch to REST for POST/PUT operations and only use GraphQL for GET?

Marian Klühspies
  • 15,824
  • 16
  • 93
  • 136
  • 1
    Related: [What's the point of input type in GraphQL?](https://stackoverflow.com/a/55881719/6024220) Only very simple models will have identical *looking* types and inputs. In reality, types will generally have fields that inputs won't and vice versa. Even when fields are shared, they may have different nullability requirements, arguments, default values, and so on. – Daniel Rearden Jul 01 '19 at 14:04
  • 1
    Having to maintain separate classes for each GraphQL definition is a symptom of the Java implementation -- implementations in other languages are not necessarily burdened in this way. For example, services built using [Apollo Server](https://www.apollographql.com/docs/apollo-server) don't suffer from the same overhead since the underlying classes are built from the SDL and field resolvers are just injected into them. – Daniel Rearden Jul 01 '19 at 14:06
  • @DanielRearden True, but the majority of fields are overlapping in my case. Sadly Node is no option in our case, so we probably will stick with REST – Marian Klühspies Jul 16 '19 at 08:35

0 Answers0