service-engine-template VS graphql-java

"... rough edges ... complex"

I've put a couple GraphQL services into production and have similar thoughts.

What suprised me most were the range of views from colleagues when they needed to integrate into one of their products. Some people were happy to work with something new, while others didn't appreciate the tax involved with the learning curve.

That said, I published an app that auto-provisions a CRUD service in GraphQL. So while I may not use it for most apps, I use this for general data-access.

https://github.com/sudowing/service-engine-template

I published an app via docker that can be used for db migrations with all dbs supported by knex.js

I'm pretty sure the core migration functionality provided by knex is supported -- along with some project specific features which support more modular schema migrations via batches of SQL files held within specific directories.

Shameless plug... sure. But it may be useful to anyone interested in the topic of this post.

https://github.com/sudowing/service-engine-template#schema_m...

https://youtu.be/84D8_--K5cs

graphql-java Github

I am planning to consume a graphql service in a java dropwizard microservice. I would like to know whether there are some easy plugin types of libraries available out there. I tried using apollographql, the automatically created schema files are not serialized, which makes the parsing tough. Planning to explore graphql-query-builder and graphql-java, any other suggestions are welcome.

graphql-java/graphql-java: GraphQL Java implementation

Domain Graph Service (DGS) is a framework created internally at Netlfix that simplifies the implementation of standalone and federated GraphQL services for Spring Boot. The framework is built on top of graphql-java. Despite most of the DGS's code is written in Kotlin it's primarily designed to be used with Java and its key features include things like: