1

Topic: Who does that think about GraphQL?

The link: http://graphql.org Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. Someone already picked? Perhaps, used?

2

Re: Who does that think about GraphQL?

Hello, scf, you wrote: scf> the Link: http://graphql.org scf> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. scf> Someone already picked? Perhaps, used? For a long time I look narrowly. And it is how much good, what the client comprises business logic? I.e. requests to basis upon are made on the client. A jamb! That they are broadcast and that not directly is all special effects.

3

Re: Who does that think about GraphQL?

Hello, Gattaka, you wrote: G> Hello, scf, you wrote: scf>> the Link: http://graphql.org scf>> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. scf>> Someone already picked? Perhaps, used? G> for a long time I look narrowly. And it is how much good, what the client comprises business logic? I.e. requests to basis upon are made on the client. A jamb! That they are broadcast and that not directly is all special effects. I would not be so categorical.

4

Re: Who does that think about GraphQL?

Hello, swimmers, you wrote: S> Hello, Gattaka, you wrote: G>> Hello, scf, you wrote: scf>>> the Link: http://graphql.org scf>>> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. scf>>> Someone already picked? Perhaps, used? G>> for a long time I look narrowly. And it is how much good, what the client comprises business logic? I.e. requests to basis upon are made on the client. A jamb! That they are broadcast and that not directly is all special effects. S> I would not be so categorical. It why? At you the client forms requests and in case of removal of essence from the domain it is necessary to change a heap of the code in the client.

5

Re: Who does that think about GraphQL?

Hello, scf, you wrote: scf> the Link: http://graphql.org scf> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. scf> Someone already picked? Perhaps, used? Very long ago I think to find/make something similar, but not absolutely. You describe in Hibernate/JPA data model, sideways by itself there is a JSON-service of type of it GraphQL with all CRUD operations over my entities. At once it is possible from DHTML to work the client dataful, without suffering various DAO layers/business logic on the server. This business of the logician practically it is always simple CRUD. The question of control of access rights too should be somehow solved. Anybody similar did not meet/tried in practice?

6

Re: Who does that think about GraphQL?

2/16/2017 11:43, sr_dev writes:> scf> the Link: http://graphql.org> scf> Briefly: the New approach to creation network API, giving the data type JSON. It is interesting simple, including in implementation, and powerful language> requests.>> scf> Someone already picked? Perhaps, used?>> very long ago I think to find/make something similar, but not absolutely. You describe> in Hibernate/JPA data model, sideways by itself there is a JSON-service> type of it GraphQL with all CRUD operations over my entities. Heard about any jhipster, but itself did not look. Under the description just something like - WBR, Serge. Posted via RSDN NNTP Server 2.1 beta

7

Re: Who does that think about GraphQL?

Hello, Gattaka, you wrote: G> Hello, swimmers, you wrote: S>> Hello, Gattaka, you wrote: G>>> Hello, scf, you wrote: scf>>>> the Link: http://graphql.org scf>>>> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. scf>>>> Someone already picked? Perhaps, used? G>>> for a long time I look narrowly. And it is how much good, what the client comprises business logic? I.e. requests to basis upon are made on the client. A jamb! That they are broadcast and that not directly is all special effects. S>> I would not be so categorical. G> it why? At you the client forms requests and in case of removal of essence from the domain it is necessary to change a heap of the code in the client. I do not say that it always correctly or always is not correct. In each case the nuances connected to productivity, cost of support and development, presence of those or other experts etc. In an example with removal of essence from the domain can, I suspect, without alteration of a heap of the code all the same not to manage.

8

Re: Who does that think about GraphQL?

As far as I understand, it is a certain piece which opened  and a problem that is a piece. They did not give the normal server. Current implementations any nurseries, it any more level . Therefore I while sense in it do not see. If they opened the full stack, for example on Java, it would be interesting. Conceptually idea very correct. REST it is very inconvenient. But except the concept also the good implementation here is necessary, most it will write difficult.

9

Re: Who does that think about GraphQL?

Hello, vsb, you wrote: vsb> As far as I understand, it is a certain piece which opened  and a problem that is a piece. They did not give the normal server. Current implementations any nurseries, it any more level . Therefore I while sense in it do not see. If they opened the full stack, for example on Java, it would be interesting. Whether you under the link walked that? Is there both  and  and  only is not present! The link

10

Re: Who does that think about GraphQL?

Hello, scf, you wrote: scf> the Link: http://graphql.org scf> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. How much I understood, it something similar with ODATA. It would be interesting to see normal comparing. But the returned format is very similar on structure (the same meta data): http://www.odata.org/documentation/odat … ON-format/ From this that was not pleasant (in examples graphql) - line feed as a field delimiter in request.

11

Re: Who does that think about GraphQL?

Hello, Somescout, you wrote: S> How much I understood, it something similar with ODATA. It would be interesting to see normal comparing. Heard, but did not read. Authorship OASIS is already the counter-recommendation to learning It is worthy of it? S> from this that was not pleasant (in examples graphql) - line feed as a field delimiter in request. In requests gaps, line feeds and commas are considered as whitespace characters. I.e. it is possible here so: {a b, c, d}

12

Re: Who does that think about GraphQL?

Hello, scf, you wrote: scf> Hello, Somescout, you wrote: S>> How much I understood, it something similar with ODATA. It would be interesting to see normal comparing. scf> heard, but did not read. Authorship OASIS is already the counter-recommendation to learning It is worthy of it? I do not know, too I deliberate over learning of all of it is pure REST wildly bothered. S>> from this that was not pleasant (in examples graphql) - line feed as a field delimiter in request. scf> in requests gaps, line feeds and commas are considered as whitespace characters. I.e. it is possible here so: {a b, c, d} And here it is asked - ?! They really consider that to the developer wants to be played with separators - "here line feed, here commas we separate, and here and gaps suffices"? Brad any.

13

Re: Who does that think about GraphQL?

Hello, Gattaka, you wrote: G> Hello, vsb, you wrote: vsb>> As far as I understand, it is a certain piece which opened  and a problem that is a piece. They did not give the normal server. Current implementations any nurseries, it any more level . Therefore I while sense in it do not see. If they opened the full stack, for example on Java, it would be interesting. Whether G> you under the link walked that? Is there both  and  and  only is not present! The link Is not present there anything. Is https://github.com/graphql-java/graphql-java but it is a hand-made article any it is not known from whom in state Working Draft, expect changes, and he/she is the client, instead of the server. And all remaining the same level.

14

Re: Who does that think about GraphQL?

Hello, vsb, you wrote: whether G>> you under the link walked that? Is there both  and  and  only is not present! The link vsb> Is not present there anything. Is https://github.com/graphql-java/graphql-java but it is a hand-made article any it is not known from whom in state Working Draft, expect changes, and he/she is the client, instead of the server. And all remaining the same level. With C# the same history. And for some reason links to client libraries lie in section "Server". Similar server is only on nodejs. That is useless enough.

15

Re: Who does that think about GraphQL?

scf> New All is clear - is postponed away, in a year we look.

16

Re: Who does that think about GraphQL?

Hello, scf, you wrote: scf> the Link: http://graphql.org scf> Briefly: the New approach to creation network API, giving the data in the form of JSON. It is interesting simple, including in implementation, and powerful language of requests. scf> Someone already picked? Perhaps, used? I used graphql-java (it is a server part for Java - the interpreter of requests and their performance). You write subject model and fasten itself (in my case it there was simply a graph of invariable objects in storage). GraphQL it is faster not language of requests (as, for example SQL), it is faster language of a filtration of the data. You give the universum of the data, and the client can select that slice which is interesting to it. In it there is a concept of parameters which can influence the returned data (that does it a bit similar to language of requests), but the request structure is beaten by nails (circuit). For example, the client cannot pull out or do the arbitrary pieces any join. For example, if your circuit contains a field "user" at which there is a field "company" you cannot to make request at once since a field "company" if it in the circuit explicitly it is not set. Allows to solve a problem of nonoptimal requests (N+1 or too a considerable quantity of the data) in REST thus without leading to one million possible parameters (type "includeUsers=true/false") or to nonoptimal answers (it is returned everything, and the client understands). In my opinion, it well approaches and to interactions the server-server. For example, we had a project to do integration with indirect systems through GraphQL. For a client - server (for example, a web application - the server) is fashionable to think now of more generalized protocols (ideas can be peeped, for example, here: http://tonsky.me/blog/the-web-after-tomorrow/), but it so while it is more  than a manner, in my opinion (though I similar now just do something that is amusing, atop REST API).