Our great sponsors
-
dataloader
DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching.
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
apollo-android
:robot: A strongly-typed, caching GraphQL client for the JVM, Android, and Kotlin multiplatform.
-
-
-
-
-
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.
Dataloader (https://github.com/graphql/dataloader) eliminates many n+1 issues. Basically, entity requests are queued up during evaluation of the query and then you can batch them up for fulfillment. It’s a great addition to other asynchronous contexts as well.
WRT random requests, there are libraries for query cost estimation you can use as a gate.
It replaced Falcor [1] which was extremely similar to GraphQL but also entirely incompatible, and was owned and maintained almost solely by Netflix staff, with GraphQL which has a large community of developers and users. Released to the public at nearly the same time, after several years in the hands of open source communities the verdict seemed to be: Falcor lost, GraphQL won. In theory this saves Netflix continuing maintenance costs of Falcor (which it can now entirely deprecate/stop work on, though there is no current warning in the repo other than maybe a comment in Issue #1016 [2]), and instead externalize more overall maintenance work to the much larger GraphQL community (including teams like Apollo and at Meta).
[1] https://github.com/Netflix/falcor
[2] https://github.com/Netflix/falcor/issues/1016#issuecomment-1...
GraphQL queries are just HTTP POST queries with a JSON body. They're supported everywhere.
If you want specialized tooling for them, Kotlin and Swift both have great strongly-typed GraphQL libraries.
Apollo publishes libraries for both:
- https://www.apollographql.com/docs/kotlin/
- https://www.apollographql.com/docs/ios/
GraphQL queries are just HTTP POST queries with a JSON body. They're supported everywhere.
If you want specialized tooling for them, Kotlin and Swift both have great strongly-typed GraphQL libraries.
Apollo publishes libraries for both:
- https://www.apollographql.com/docs/kotlin/
- https://www.apollographql.com/docs/ios/
> It's simple and straightforward to get around some pitfalls of GraphQL
It isn't
> if you treat it as an enumerated set of RPC-style endpoints.
It's not that.
> I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL
"GraphQL is a query language for APIs" is literally the tagline at https://graphql.org/
And the frankly insane complexity of GraphQL comes from the fact that you now have to implement that query language, often over completely different sources of data.
Which leads to frankly inane solutions like the requirement to inspect the full request and the full response on the fly just to be able to cache responses.
https://github.com/slicknode/graphql-query-complexity
In addition you could introduce CI tools to enforce your devs stop writing such complex queries. Also see the @skip and @include directives that can further be used to control what data is queried. In practice, however, this isn't something that comes up too much. In cases where I have seen this happen, it's usually because a developer is trying to reuse fragments without considering what data they are querying, and whether they should be reusing those fragments.
https://graphql.org/learn/queries/#fragments
I created a proposal for Map type but didn’t make it through.
https://github.com/graphql/graphql-spec/pull/888
The issue with GraphQL is it tries to appease too many masters.
Similar to jsx. The language isn’t evolving.
The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can encompass the flexibility of json schema can do.