Why Graphiti?

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.<p>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.<p>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.

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.

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

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

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.

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

I&#x27;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.<p>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&#x27;t want to rewrite that boilerplate a bunch.<p>From what I&#x27;ve seen, there&#x27;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&#x27;s only a matter of time before a structured alternative to GraphQL comes out.

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.<p>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.

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