6 ms·

Why Graphiti?

154 points by geordee 7y ago

goblin89 7y ago
This looks like an effort to bring to REST APIs some of the benefits GraphQL offers, mainly by adding extensive conventions on top of traditional HTTP endpoints. Comes with an implementation in Ruby. The idea has some merit. That said, I am not sure I have spotted the discoverability features equivalent to what’s possible in GraphQL world with a GraphiQL console.
- diroussel 7y ago
  I must admit the main thing that puts me off GraphQL is that it's not built on JSON. Maybe that's silly, but it just seems like a move away from what we know and love. Also the graphql tools seem to be based around the idea of a fixd schema, and I'm looking for something a little more flexible.
  - cuddlecake 7y ago
    > move away from what we know and love I didn't get the memo where we decided that we love JSON.
    - deleted 7y ago
      [deleted]
    - The_rationalist 7y ago
      Especially when there are almost consensual better alternatives https://hjson.org https://hjson.org
      - vertex-four 7y ago
        Uhh, no. Part of the reason JSON is useful is that it's easy to write a correct parser in comparison to most other things - adding a bunch of the complexity of YAML back to JSON seems a bad idea. This makes it possible to use JSON as a serialisation layer for network protocols without introducing too much additional risk of parsing-related vulnerabilities.
    - tylerl 7y ago
      Sure, but there are tradeoffs to consider: JSON may be difficult and inconvenient to use for human interaction, but on the other hand it's also really slow for machine reading and writing. Plus you have the added bonus of it being an inefficient use of bandwidth.
  - seniorsassycat 7y ago
    The schema is not defined in json, which is good, json can't have comments. Graphql requests and responses are json, and you can get a json representation of the schema using the introspection api. I for one do not like json, the only formats I can think of that I like less are xml and yaml. I'd prefer a protocol with a binary implementation, it must support comments, I like type annotations, and a schema language would be great. I've been working with Amazon's ion lately and I've enjoyed it. It has text and binary representations, fields have types (in binary), it can be represented as json (you lose annotations)
- smoll 7y ago
  > This looks like an effort to bring to REST APIs some of the benefits GraphQL offers, mainly by adding extensive conventions on top of traditional HTTP endpoints. This was my take-away as well. There are a couple of full-featured frameworks in GraphQL land -- Hasura[0] and Prisma[1] spring to mind, among others -- that enforce conventions and in exchange allow you to specify a sort_by array and operate on a standardized payload without exposing too much non-essential configuration. --- [0] https://hasura.io/all-features https://hasura.io/all-features [1] https://www.prisma.io/with-graphql https://www.prisma.io/with-graphql
onlydnaq 7y ago
When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. Inserting multiple objects in the same transaction?, already implemented. Updating several fields at the same time as well? Getting only the entities you are interested in together with their subentities?, well that’s what a relational database does. As I said, I’m not a web developer, and I haven’t touched on use cases where a lot of different things need to happen on server operations, but all the examples in the article would be easily solvable with SQL.
- siscia 7y ago
  I completely agree! I really don't understand why we don't simply ship SQL queries around, maybe a very simple subset of SQL so that it either works on most vendors or that it can be easily manipulated and adapt to different storage backend. Can somebody enlight me?
  - bryanrasmussen 7y ago
    it is unlikely that all the data sources you will be querying now are directly available in an SQL database.
    - siscia 7y ago
      For sure they are not available in a /rest or GraphQL engine neither. SQL should be only the syntax used to communicate with the backend, the real implementation would be in whatever make sense.
      - notus 7y ago
        That would require you to map the SQL to something else which would then map back to SQL or mongo or w/e. For example if you're trying to join data from multiple microservices you can't execute the join because most microservices setups are not going to allow joins. The joins would have to be mapped to service to service calls and at this point you're just rebuilding an orchestration layer which has already been solved by graphql.
tpetry 7y ago
The biggest reason for graphql is in my opinion the enforced schema. REST apis so often had a nice written document describing the api and its fields, but nowhere was stated that some attributes can be null in some rare edge cases. In graphql the spec states an attribute can be null and i will not get some code crashing in a few months because of some undocumented behaviour.
- dsun180 7y ago
  I also miss that in GraphQL. With swagger I can exactly define how an object looks like. Not only if something is null or string, but also what the minLength the string is or what enum-values it can have.
yodon 7y ago
At the risk of being a language advocate I wish the reference server implementation had been in Typescript rather than Ruby.
acjohnson55 7y ago
I'm not sure how this differs from some of the more fully thought through hypermedia frameworks. Although it is nice that there's convention for flattening included linked resources down to something a bit more manageable. For me, GraphQL really shines when going beyond CRUD. In my experience, many client applications aren't just querying and filtering, they're acting as a gateway for complex server processes and need to present a lot of data at once. These advantages aren't going to come through in simple CRUD examples. GraphQL, in its current state, has some frustrating limitations, but I still think the future looks more like it than REST.
intellix 7y ago
The amount of times I've used APIs claiming to be RESTful but actually aren't consistent... If you use something like Prisma you don't need to worry about the boilerplate or having to maintain consistency when creating a GQL API. I love the ability to browse introspection via playground most of all. My two annoyances right now are: lack of input unions and lack of recursive fetching for tree/node based resources
xwowsersx 7y ago
Without remarking on the substance of this post, I just wanted to say I enjoyed the writing style and the design of this post tremendously. I was actually quite surprised by how much I enjoyed it haha.
- iamwil 7y ago
  On the other hand, I'm on the other side on this. I kept thinking, "get to the point, what are you trying to say?"
  - xwowsersx 7y ago
    Haha, I hear you. If I was in a different mood, I might feel the same way. In general, though, I liked the tone of the writing and the little gifs - how did he make those btw?
    - iamwil 7y ago
      No idea. gif makers are a plenty on the web nowadays.
foobar_ 7y ago
GraphQL doesn't not have support for dictionaries and JSON. I'd rather just use JSON schema + Mongo directly. If there is a way to batch multiple HTTP requests ... then GraphQL would be an overkill.
- halostatue 7y ago
  Neither of those is exactly true. GraphQL has support for user-defined scalars and we’ve defined a `JSON` scalar that is used to transfer arbitrary JSON objects as JSON-encoded strings (we also have a `map` scalar that renders as a JSON object at its field, but accepts a JSON-encoded string for input formats; we are shifting away from that because _some_ clients don’t have the flexibility of producing inputs like that).
_hardwaregeek 7y ago
I've wanted this for a while actually. GraphQL is great, but it lacks convention. Which makes it hard for API discovery and code generation. I noticed that the author uses Ruby, which makes total sense, as Rails is a shining example of how conventions in REST can make generating an API incredibly easy. I actually tried to make a GraphQL based framework in Ruby a while back that emphasized convention. By having convention, I was able to generate, say, a field that searches for a resource by ID. Not revolutionary stuff, but nice if you don't want to rewrite that boilerplate a bunch. From what I've seen, there's a cycle of structure vs less structure in paradigms. SOAP was too unstructured, so REST was more structured. REST is too structured so now GraphQL. I suppose it's only a matter of time before a structured alternative to GraphQL comes out.

154 points by geordee 7y ago

This looks like an effort to bring to REST APIs some of the benefits GraphQL offers, mainly by adding extensive conventions on top of traditional HTTP endpoints. Comes with an implementation in Ruby. The idea has some merit. That said, I am not sure I have spotted the discoverability features equivalent to what’s possible in GraphQL world with a GraphiQL console.

diroussel 7y ago
I must admit the main thing that puts me off GraphQL is that it's not built on JSON. Maybe that's silly, but it just seems like a move away from what we know and love. Also the graphql tools seem to be based around the idea of a fixd schema, and I'm looking for something a little more flexible.
- cuddlecake 7y ago
  > move away from what we know and love I didn't get the memo where we decided that we love JSON.
  - deleted 7y ago
    [deleted]
  - The_rationalist 7y ago
    Especially when there are almost consensual better alternatives https://hjson.org https://hjson.org
    - vertex-four 7y ago
      Uhh, no. Part of the reason JSON is useful is that it's easy to write a correct parser in comparison to most other things - adding a bunch of the complexity of YAML back to JSON seems a bad idea. This makes it possible to use JSON as a serialisation layer for network protocols without introducing too much additional risk of parsing-related vulnerabilities.
  - tylerl 7y ago
    Sure, but there are tradeoffs to consider: JSON may be difficult and inconvenient to use for human interaction, but on the other hand it's also really slow for machine reading and writing. Plus you have the added bonus of it being an inefficient use of bandwidth.
- seniorsassycat 7y ago
  The schema is not defined in json, which is good, json can't have comments. Graphql requests and responses are json, and you can get a json representation of the schema using the introspection api. I for one do not like json, the only formats I can think of that I like less are xml and yaml. I'd prefer a protocol with a binary implementation, it must support comments, I like type annotations, and a schema language would be great. I've been working with Amazon's ion lately and I've enjoyed it. It has text and binary representations, fields have types (in binary), it can be represented as json (you lose annotations)
smoll 7y ago
> This looks like an effort to bring to REST APIs some of the benefits GraphQL offers, mainly by adding extensive conventions on top of traditional HTTP endpoints. This was my take-away as well. There are a couple of full-featured frameworks in GraphQL land -- Hasura[0] and Prisma[1] spring to mind, among others -- that enforce conventions and in exchange allow you to specify a sort_by array and operate on a standardized payload without exposing too much non-essential configuration. --- [0] https://hasura.io/all-features https://hasura.io/all-features [1] https://www.prisma.io/with-graphql https://www.prisma.io/with-graphql

onlydnaq 7y ago

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. Inserting multiple objects in the same transaction?, already implemented. Updating several fields at the same time as well? Getting only the entities you are interested in together with their subentities?, well that’s what a relational database does. As I said, I’m not a web developer, and I haven’t touched on use cases where a lot of different things need to happen on server operations, but all the examples in the article would be easily solvable with SQL.

siscia 7y ago
I completely agree! I really don't understand why we don't simply ship SQL queries around, maybe a very simple subset of SQL so that it either works on most vendors or that it can be easily manipulated and adapt to different storage backend. Can somebody enlight me?
- bryanrasmussen 7y ago
  it is unlikely that all the data sources you will be querying now are directly available in an SQL database.
  - siscia 7y ago
    For sure they are not available in a /rest or GraphQL engine neither. SQL should be only the syntax used to communicate with the backend, the real implementation would be in whatever make sense.
    - notus 7y ago
      That would require you to map the SQL to something else which would then map back to SQL or mongo or w/e. For example if you're trying to join data from multiple microservices you can't execute the join because most microservices setups are not going to allow joins. The joins would have to be mapped to service to service calls and at this point you're just rebuilding an orchestration layer which has already been solved by graphql.

tpetry 7y ago

The biggest reason for graphql is in my opinion the enforced schema. REST apis so often had a nice written document describing the api and its fields, but nowhere was stated that some attributes can be null in some rare edge cases. In graphql the spec states an attribute can be null and i will not get some code crashing in a few months because of some undocumented behaviour.

dsun180 7y ago
I also miss that in GraphQL. With swagger I can exactly define how an object looks like. Not only if something is null or string, but also what the minLength the string is or what enum-values it can have.

yodon 7y ago

At the risk of being a language advocate I wish the reference server implementation had been in Typescript rather than Ruby.

acjohnson55 7y ago

I'm not sure how this differs from some of the more fully thought through hypermedia frameworks. Although it is nice that there's convention for flattening included linked resources down to something a bit more manageable. For me, GraphQL really shines when going beyond CRUD. In my experience, many client applications aren't just querying and filtering, they're acting as a gateway for complex server processes and need to present a lot of data at once. These advantages aren't going to come through in simple CRUD examples. GraphQL, in its current state, has some frustrating limitations, but I still think the future looks more like it than REST.

intellix 7y ago

The amount of times I've used APIs claiming to be RESTful but actually aren't consistent... If you use something like Prisma you don't need to worry about the boilerplate or having to maintain consistency when creating a GQL API. I love the ability to browse introspection via playground most of all. My two annoyances right now are: lack of input unions and lack of recursive fetching for tree/node based resources

xwowsersx 7y ago

Without remarking on the substance of this post, I just wanted to say I enjoyed the writing style and the design of this post tremendously. I was actually quite surprised by how much I enjoyed it haha.

iamwil 7y ago
On the other hand, I'm on the other side on this. I kept thinking, "get to the point, what are you trying to say?"
- xwowsersx 7y ago
  Haha, I hear you. If I was in a different mood, I might feel the same way. In general, though, I liked the tone of the writing and the little gifs - how did he make those btw?
  - iamwil 7y ago
    No idea. gif makers are a plenty on the web nowadays.

foobar_ 7y ago

GraphQL doesn't not have support for dictionaries and JSON. I'd rather just use JSON schema + Mongo directly. If there is a way to batch multiple HTTP requests ... then GraphQL would be an overkill.

halostatue 7y ago
Neither of those is exactly true. GraphQL has support for user-defined scalars and we’ve defined a `JSON` scalar that is used to transfer arbitrary JSON objects as JSON-encoded strings (we also have a `map` scalar that renders as a JSON object at its field, but accepts a JSON-encoded string for input formats; we are shifting away from that because _some_ clients don’t have the flexibility of producing inputs like that).

_hardwaregeek 7y ago

I've wanted this for a while actually. GraphQL is great, but it lacks convention. Which makes it hard for API discovery and code generation. I noticed that the author uses Ruby, which makes total sense, as Rails is a shining example of how conventions in REST can make generating an API incredibly easy. I actually tried to make a GraphQL based framework in Ruby a while back that emphasized convention. By having convention, I was able to generate, say, a field that searches for a resource by ID. Not revolutionary stuff, but nice if you don't want to rewrite that boilerplate a bunch. From what I've seen, there's a cycle of structure vs less structure in paradigms. SOAP was too unstructured, so REST was more structured. REST is too structured so now GraphQL. I suppose it's only a matter of time before a structured alternative to GraphQL comes out.