I have a fellow coworker that's jumped on the graphQL band wagon and really
loves the idea though my biggest pet peave with it right now is that it's a
lot of boiler plate code.
In our case most of the relationship 'graph' can be derived from a properly
structured DB model.
(ie. User has a link to an address table can be determined by seeing the
user_id fkey on the address table or however it was implemented).
I end up with code like this:
. Customer.java
public class Customer {
public static Function<String, Field> customerMapToSQLFields =
(String fieldName) -> {
switch (fieldName) {
case "customerName": return CUSTOMER.CUSTOMER_NAME;
case "creationDate": return CUSTOMER.CREATION_DATE;
case "modificationDate": return CUSTOMER.MODIFICATION_DATE;
case "createdById": return CUSTOMER.CREATED_BY_ID;
case "modifiedById": return CUSTOMER.MODIFIED_BY_ID;
case "authType": return CUSTOMER.AUTH_TYPE;
default:
return CUSTOMER.CUSTOMER_ID;
}
};
}
and a sort of Pojo CustomerType . The Customer class it extends in this
case is actually the auto-generated class from Jooq. @Getter/@Setter are
lombok annotations and @GraphQLField comes from
https://github.com/graphql-java/graphql-java-annotations.
The bean doesn't follow java conventions due to graphQL assumptions for the
most part.
public class CustomerType extends Customer {
@Getter
@Setter
protected Long id;
@Getter
@Setter
protected Long createdById;
@Getter
@Setter
protected Timestamp creationDate;
@Getter
@Setter
protected Long modifiedById;
@Getter
@Setter
protected Timestamp modificationDate;
@Getter
@Setter
protected String customerName;
@GraphQLField
public String customerId() {
return String.valueOf(getCustomerId());
};
@GraphQLField
public String customerName() {
return customerName;
};
@GraphQLField
public String creationDate() {
return GraphQLHelpers.formatJSONDate(creationDate);
}
@GraphQLField
public String modificationDate() {
return GraphQLHelpers.formatJSONDate(modificationDate);
}
@GraphQLField
public String createdById() {
return String.valueOf(createdById);
}
@GraphQLField
public String modifiedById() {
return String.valueOf(modifiedById);
}
@GraphQLField
public String clientId() {
return String.valueOf(id);
}
}
What this somewhat specific email is getting to and what I was thinking of
looking at is using Jooq to extend its code generation and generate both
these classes. I wonder if it would make sense to leverage the existing
auto-generation code to build upon it.
Possibly adding dataFetcher that are abstract and make the CustomerType an
abstract entity that requires the user to fill in the details.
Any thoughts on using Jooq in such patterns not limited to GraphQL. I'm
sure you can replace GraphQL with your favorite new technology to do
something similar. The other suggestions that was mentioned was Java Poet
though I haven't looked too deeply at it yet.
https://github.com/square/javapoet
--
Thank you
Samir Faci
https://keybase.io/csgeek
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
