Comparison to Expedia's spring boot plugin?

[jillesvangurp]

We've been using the Expedia graphql plugin for Spring boot for the last half year or so. I just stumbled on this project, which looks like it was open sourced only recently (?) . So, I was wondering about how the two compare and whether it makes sense for both projects to join forces or whether one has a clear benefit over the other.

From a brief look at what is there a few things jump out:

• both generate a schema from code but Expedia graphql does it at run time (through introspection) and DGS generates the schema at build time. This is of course a killer feature because it means you can focus most of your time on just writing business logic.
• DGS seems currently based on webmvc. Expedia is based on web flux and thus more easy to use with co-routines and flows. However, this makes harder to use with blocking things like e.g. hibernate (which we don't use). For us co-routines and web flux were very desirable as we were looking to use that in any case.
• Both are using the same graphl-java framework underneath.
• Both are doing subscriptions, federation, etc. Subscriptions without webflux / co-routines seems like the wrong thing to do at this point. It seems both support very similar feature sets.
• Both are Spring Boot centric and won't work with e.g. KTor or other frameworks popular with Kotlin.

[srinivasankavitha]

As you pointed out already, the Schema-First approach is what we've focused on for the DGS Framework. We widely adopt this approach within Netflix as well, and has several advantages since it ensures proper schema design upfront. The Expedia plugin is more applicable for code-first approach. While we do add the capability to generate schema from code, it is not the primary focus.

For context, the DGS Framework was initially developed for use within Netflix to integrate with the Netflix ecosystem, but has evolved to more general usage. We internally add on Netflix-specific integrations on top of the OSS framework. Having our own framework allows us more control over what we can enhance and customize for our internal use within the company.

Regarding webflux - we do plan on adding support for webflux in the future: #28

Hope that answers your question.

[paulbakker]

@jillesvangurp Disclaimer, I haven't actually used the Expedia project. Both frameworks were developed in parallel (Netflix has been working on the DGS framework for about 18 months).

From what I know about it is two main differences:

• DGS is primarily targeted at usage in Java. Kotlin works just as well, but we don't use any paradigms that wouldn't work well in Java. The Expedia project is targeted at Kotlin. I guess this can be either a pro or con, depending on if you use Java or not.
• DGS is focused on "schema first" development. You actually do have to provide a schema file. There's support for providing a schema at runtime through code as well, but that's for pluggability and specialized use cases. The Expedia project is code-first. Both can work well, but at Netflix, we strongly prefer schema-first development for GraphQL.

As @srinivasankavitha pointed out, we do plan to support WebFlux at some point. Although I agree subscriptions would technically be better based on WebFlux, we do use subscriptions successfully at reasonably high volume based on WebMVC.

[jillesvangurp]

Thanks both for the clarifications. I'm at this point solidly in the Kotlin camp, so Java is less of a priority for me.

Of course webmvc scales just fine as well; I've used it for many years. It's just that the reactive programming model is a good fit for subscription related use cases. Kotlin and co-routines make this quite nice. I'm not sure I'd want to deal with Webflux without that.

As for schema first, I guess that makes sense if you have a lot of depending teams that are going to use the schema. Getting it right might be worth the extra work as it will prevent changes down the road. Also, with federated services, I guess it matters to align the schemas instead of having people just add to it in an uncontrolled way.

On the other hand, I like being able to iterate fast and spin up new graphql endpoint simply by adding classes and functions. There's basically no ceremony or friction around this. Extend Query, add a suspend function. Done. Great for rapid iterations. But it does demote graphql to yet another way to do RPC over a network.