GraphQL is facebook's baby. Their argument is that given some type of REST
entity.
/users/{id}
you'll have some use cases where you want just id and name, or N number of
different use cases, so rather then having to live with the much fatter
payload especially when you multiply that by Y for a listing page and the
payload becomes very large. Especially @ a facebook scale.
So rather then doing REST they provide a POST generic endpoint where the
response depends the JSON payload you send it that drives the service.
But what I was essentially getting to, graphQL constructs a model file only
returning the fields requested. You can then also use something like the
Customer class I included in my previous email to dynamically query
the table for the fields requested. (Making something like Fkey, and PKey
always required for instance ).
Since all the relationship are heavily tied to the DB model, I was thinking
of using Jooq to help generate some of this code.
I'll look at the jooq-meta API. I was mostly looking for feedback and
suggestion and making sure I wasn't going on a completely different tangent
that Jooq was never designed for.
--
Samir Faci
On Tue, Mar 21, 2017 at 9:53 AM, Lukas Eder <[email protected]> wrote:
> Hi Samir,
>
> Thanks for sharing. That library sounds very interesting. Does that mean
> you can query your Java domain model using something like GraphQL /
> CypherQuery or similar?
>
> Sure, you can hook into the jOOQ code generator by extending the
> JavaGenerator class and by creating additional files. The jooq-meta API
> should help you navigate your tables in a transparent way. This isn't
> documented very well, but I think it should be straightforward to get
> started with. I'm very happy to answer any specific questions you may have.
>
> However, I'm not sure if I have answered all your questions yet...?
>
> Lukas
>
> 2017-03-21 14:57 GMT+01:00 Samir Faci <[email protected]>:
>
>> 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/graphq
>> l-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.
>>
>
> --
> 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.
>
--
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.
