Replies: 7 comments 3 replies
-
|
@leebyron @benjie @IvanGoncharov @BoD @twof @michaelstaib @sachee @fotoetienne @yaacovCR @joeynenni |
Beta Was this translation helpful? Give feedback.
-
|
If I can throw in one more that I think deserves a mention SQL is a domain-specific language used in programming and designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS). |
Beta Was this translation helpful? Give feedback.
-
|
I think you're right that SDL deserves to be named in the spec. Last I checked it isn't mentioned as "SDL" at all even though that's the commonly used terminology. |
Beta Was this translation helpful? Give feedback.
-
|
I fully agree with using SQL as a role model. |
Beta Was this translation helpful? Give feedback.
-
|
Also, it makes a lot of sense to use SQL as a reference since GraphQL was developed as the successor of https://en.wikipedia.org/wiki/Facebook_Query_Language |
Beta Was this translation helpful? Give feedback.
-
|
About
Since we already lost a moment, we community maybe it worth just changing TSDL to SDL in a spec. |
Beta Was this translation helpful? Give feedback.
-
I didn't do full research on them but if I remember right all of them:
GraphQL doesn't specify those things so it can't be a "protocol" or "framework". |
Beta Was this translation helpful? Give feedback.
-
GraphQL does not specify these things?! GraphQL spec does not specify fully request format?! Isn't the query/request language is in fact the request format? Serialization - the spec suggests json for data returned (and variable values) as de facto most used, but mentions that other formats/transports are possible. Absolutely the same situation for other 'protocols' - gRpc et all. gRPC states that serialization and underlying transport might vary: I do not see the logic here, at all, in this objection and comparison to other 'things'. GraphQL is not a framework (we do not ship code generators like gRPC). But GraphQL clearly more than just 'language to build client apps', 'language' is just one chapter in the spec (2 if we count type system), but has way more stuff. What makes GraphQL so fundamentally different from Thrift that it cannot be called protocol like Thrift? What seems really strange to me is this resistance to any change in spec's definition. For me, the current definition ("language for building client apps") is absolutely 'unsatisfactory', to put it lightly. Can we at least agree on that to some degree? And then try to come up with something better? instead what i hear is - it's fine, don't change anything. |
Beta Was this translation helpful? Give feedback.
-
|
regarding SQL + ODBC |
Beta Was this translation helpful? Give feedback.
-
|
Regarding SQL as a model I agree, SQL is an interesting case to look at and maybe to 'borrow' from. And it is also interesting in its 'failures'. I would point out SQL explicitly states that it has several sublanguages (up to 4 or 5) but commonly recognized just 2: DDL (Data Definition Language) - schema; and DML (Data Manipulation Language) queries and data updates. That's the idea I try to promote here, that GraphQL has two sublanguages, SDL and request language, but meet some serious resistance - that GraphQL is one language, no divisions. I think explicitly recognizing the two sub-languages in GraphQL would help a lot to new-comers. It took me a while to understand this, and that an expression A : B means completely different things depending on 'sub-language'; in SDL it is 'field:fieldType' or 'argName:argType'; in query language it is 'field:value' or 'arg:value'. And many other syntactic/semantic differences that are nicely grouped in sublanguages. I was extremely confused several times, about syntax, until I finally realized that there are in fact two languages here, looking alike but in fact quite different. There is something else to learn from SQL case - the failure lesson. SQL completely failed as a standard. We do have a Standard, multiple versions over the years. But at the same time - a bunch of incompatible SQL dialects from different vendors. Most dialects are not even SQL-99 compliant! - and will never be. This recent Editorial explains the situation very well I think: https://www.sqlservercentral.com/?na=v&nk=84778-5c996c01ce6c2&id=1265 Among other things, as causes of failure, it lists 'over-complexity', and also being late to standardize -
I think we have similar situation now, when GraphQL frameworks developers can't wait and implement things like appliedDirs, custom scalars (Map, Any) way before WG gets to it - because they just need it. We need to learn from SQL's lessons I think and speed it up. |
Beta Was this translation helpful? Give feedback.
-
Formal GraphQL Definition
Problem Statement
We have two definitions in the spec:
Problems:
1st definition:
a QUERY language? - what about updates/mutations?
and execution engine - so this engine can be downloaded from somewhere?
2 nd definition:
a QUERY language? - same as with previous, see above
a LANGUAGE ? - but many things in the spec are beyond the language (introspection, response structure, etc)
NB: we have in fact 2 languages in GraphQL - SDL and Request language
to build CLIENT applications - then server folks do not need to bother? is it like React, client-only? Can you have GraphQL app without a service/server?!
Looking at other similar technologies
gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment.
Source
Thrift is an interface definition language and binary communication protocol used for defining and creating services for numerous programming languages. Wikipedia
Avro is a row-oriented remote procedure call and data serialization framework developed within Apache's Hadoop project
Wikipedia
Open Data Protocol (OData) is an open protocol that allows the creation and consumption of queryable and interoperable REST APIs in a simple and standard way. Wikipedia
SOAP ... is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Wikipedia
Common patterns:
X is a Framework
X is a language (IDL) and a protocol
X is a protocol
Note: Framework identifies that the tech includes actual tools or executables in addition to specs. Apparently GraphQL is not a framework
Suggestion
Here is my initial draft version of suggested new definition.
GraphQL is a client-server communication protocol commonly implemented over Http, with Json as data format. It defines a language for describing the data model and API of the service, and a request language for expressing the requests from the client to the service.
Possible variations:
Remove "commonly implemented ..."
Add something about Introspection as means of self-description.
Beta Was this translation helpful? Give feedback.
All reactions