Our great sponsors
-
-
service-engine-template
Template: REST, GraphQL & gRPC services for CRUD to Popular Databases. Supports Schema Migrations and built using service-engine Docker Image.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
trustfall
A query engine for any combination of data sources. Query your files and APIs as if they were databases!
-
-
-
Hot Chocolate
Welcome to the home of the Hot Chocolate GraphQL server for .NET, the Strawberry Shake GraphQL client for .NET and Banana Cake Pop the awesome Monaco based GraphQL IDE.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
orval
orval is able to generate client with appropriate type-signatures (TypeScript) from any valid OpenAPI v3 or Swagger v2 specification, either in yaml or json formats. 🍺
https://github.com/Netflix/dgs-framework#readme
There's an "awesome" list in the graphql-java org, too: https://github.com/graphql-java/awesome-graphql-java#readme
"... 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
There's an interesting tension here. On one hand, GraphQL is versatile and can simplify frontend data handling code. On the other, as schema and data sizes grow, query expressiveness is limited and performance can be quite difficult to maintain.
I've put GraphQL in front of TB-scale data sources with X00,000 tables, and it was clear that (a) GraphQL wasn't designed for anything that big, and (b) if we could get it there, it would be transformational.
This is why I built Trustfall[0]: a system that keeps the elegant GraphQL syntax, and tweaks the semantics to ensure great performance and better expressiveness: left joins / recursion / aggregations / arbitrary filters etc. Trustfall flips the proposition around: acknowledge we're wrapping a database around every data source (API server / database / filesystem / ML etc.) and make it the best possible database it could be.
I gave a talk on it titled "How to Query (Almost) Everything" at the HYTRADBOI'22 conference: https://www.hytradboi.com/2022/how-to-query-almost-everythin...
I also recently used it to build cargo-semver-checks[1], a semver linter for Rust crates where each semver rule is implemented as a query using Trustfall's GraphQL + custom directives syntax.
[0]: https://github.com/obi1kenobi/trustfall
[1]: https://crates.io/crates/cargo-semver-checks
https://github.com/Netflix/dgs-framework#readme
There's an "awesome" list in the graphql-java org, too: https://github.com/graphql-java/awesome-graphql-java#readme
