4 ms·

I have a question I have been trying to figure out for a while. All the examples of clients that use GraphQL seem to be javascript; is there any support for wri

I have a question I have been trying to figure out for a while. All the examples of clients that use GraphQL seem to be javascript; is there any support for writing, for example, a Java client to talk to a GraphQL backend? This would really help make it easier to port infrastructure over piece by piece.

hackerboos 11y ago
https://github.com/chentsulin/awesome-graphql#lib-java https://github.com/chentsulin/awesome-graphql#lib-java
- kazagistar 11y ago
  I found that link before, but aren't those all backends?
  - lkrubner 11y ago
    You can write the server in any language, and you can also write the client in any language. As a point of comparison, consider SQL databases such as MySQL or Oracle or MongoDB. There are clients written in dozens of different languages.
e1g 11y ago
GraphQL defines the query language, but uses simple HTTP as the transport. It's not like like redis or mysql - those use custom protocols and so require special clients to use them. GraphQL backends are like Elasticsearch backends - you access them by hitting the exposed HTTP endpoint with your query in plain text. You could do this with any HTTP client library in any language, or even with curl.
- kazagistar 11y ago
  Thats true, but in a typed, structured language, you generally build some kind of data structure to deserialize responses into. With REST endpoints, each response can be translated to a specific predefined object in a client library. GraphQL seems to, by design, ignore this kind of usage in favor of the "heterogenus untyped dictionary responses"... do I really have to write custom data types for every single different query?
  - e1g 11y ago
    I think get this now - with SOAP/RPC/REST we can establish the interaction contract by explicitly defining inputs and outputs. With that contract, we can draw clearly defined system boundaries, give better assurances to the developer that they are doing the right thing, and improve testing. You're right - in the scale of app-level problems, GraphQL is just a low-level protocol. It requires language-specific libs to address these higher-level problems (provide interfaces, structs, query typing, etc). As a very basic example, programatically building a GraphQL query is unnecessary complex outside of JS because many languages don't yet have a QueryBuilder for the GraphQL syntax. There are some community efforts, but as of yet no heavy corporate players to drive GraphQL-specific dev (e.g. like Pivotal/Sensio/Sencha did for their respective fields).

hackerboos 11y ago

https://github.com/chentsulin/awesome-graphql#lib-java https://github.com/chentsulin/awesome-graphql#lib-java

kazagistar 11y ago
I found that link before, but aren't those all backends?
- lkrubner 11y ago
  You can write the server in any language, and you can also write the client in any language. As a point of comparison, consider SQL databases such as MySQL or Oracle or MongoDB. There are clients written in dozens of different languages.

e1g 11y ago

GraphQL defines the query language, but uses simple HTTP as the transport. It's not like like redis or mysql - those use custom protocols and so require special clients to use them. GraphQL backends are like Elasticsearch backends - you access them by hitting the exposed HTTP endpoint with your query in plain text. You could do this with any HTTP client library in any language, or even with curl.

kazagistar 11y ago
Thats true, but in a typed, structured language, you generally build some kind of data structure to deserialize responses into. With REST endpoints, each response can be translated to a specific predefined object in a client library. GraphQL seems to, by design, ignore this kind of usage in favor of the "heterogenus untyped dictionary responses"... do I really have to write custom data types for every single different query?
- e1g 11y ago
  I think get this now - with SOAP/RPC/REST we can establish the interaction contract by explicitly defining inputs and outputs. With that contract, we can draw clearly defined system boundaries, give better assurances to the developer that they are doing the right thing, and improve testing. You're right - in the scale of app-level problems, GraphQL is just a low-level protocol. It requires language-specific libs to address these higher-level problems (provide interfaces, structs, query typing, etc). As a very basic example, programatically building a GraphQL query is unnecessary complex outside of JS because many languages don't yet have a QueryBuilder for the GraphQL syntax. There are some community efforts, but as of yet no heavy corporate players to drive GraphQL-specific dev (e.g. like Pivotal/Sensio/Sencha did for their respective fields).