graphql-query-complexity VS apollo-android

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

very cool! I was looking at https://github.com/slicknode/graphql-query-complexity

There are a couple of techniques that can be used to prevent this kind of problem one of them is GraphQL Query Complexity Analysis which is, as the name suggests, very complex to implement correctly. It requires analysis of how the graphql API is used, and what queries and mutations are most often called. If you get this wrong, there is a danger of the server denying perfectly valid queries.

The problem is that those queries are not prevented by commonly available rate limiters. You can send a single request to a GraphQL server that completely overwhelms the servers. To prevent such queries to GraphQL APIs, I wrote graphql-query-complexity, an extensible open-source library that detects such queries and rejects pathological queries before consuming too many resources on the server. You can assign each field a complexity value, and queries that exceed a threshold will be rejected. In Slicknode this protection is added automatically based on the number of nodes that are being returned.

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/

An example of a Snowflake API request using Java. This example uses Java’s built-in HttpClient and constructs JSON manually, so it doesn’t require additional dependencies; however, in production, you should use a library like Jackson for constructing JSON. Additionally, for stronger typing, you could use Apollo’s Kotlin-based GraphQL client.

Can you elaborate on what you are trying to do? Why do you generate those classes manually? If you are using Apollo Kotlin then it will generate your data classes based on your query.

We continue to rely on Apollo Kotlin (previously Apollo Android) as we migrate to Federation. It has evolved quite a bit since its creation and has been hugely useful to us, so it’s worth highlighting before jumping ahead.

- found Flutter graphql is way ahead , even almost mature as Apollo for JS. apollo-kotlin is several miles behind, a lot of issues, absolutely inconvenient usage after graphql-flutter

The announcement is at https://www.apollographql.com/blog/announcement/introducing-apollo-kotlin/ and the repo at https://github.com/apollographql/apollo-kotlin. Try it out and let us know what you think!

Apollo Client does have a good integration with these frameworks including React, iOS and Android — so, you might want to check that out

Hi 👋Martin from https://github.com/apollographql/apollo-android here. Can you ellaborate more on "created schema files are not serialized" ? For Android app, I usually recommend separating the persistence layer and the network models so that they're not coupled. But maybe it's different from a microservice?