
Why Graphiti? - geordee
https://www.graphiti.dev/guides/why
======
onlydnaq
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
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
it is unlikely that all the data sources you will be querying now are directly
available in an SQL database.

~~~
siscia
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
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.

~~~
siscia
So we invented a query language (GraphQL) to solve an orchestration problem?

Sorry but I don't buy this reason. Especially not to the question: "Why we
don't use SQL as a query language?" especially because REST was around way
earlier than GraphQL.

Your reasoning could be great to answer the question: "Why we like GraphQL
where there are a lot of microservices?"

BTW, there is nothing inherent in the language in itself, if each
microservices would be speaking SQL, you would simply need to _optmize your
SQL query_ , decompose your optimized SQL query creating simpler queries one
for each microservice, send each of those queries to the relative
microservices, compute back the final result.

If you replace "microservices" with "table" here you get the standard way an
SQL engine works :)

Please, it is not that I am against GraphQL, but it honestly seems like some
engineer at facebook was annoyed by SQL, and decide to re-invent it. And that
we are all following him or she just because they worked at facebook, which
seems unwise.

Maybe the use of types? But what is the difference between a type and
something that belong to a table?

Anyway, I am looking now at [GraphQL: The Documentary (Official Release)][1]

[1]:
[https://www.youtube.com/watch?v=783ccP__No8&feature=youtu.be](https://www.youtube.com/watch?v=783ccP__No8&feature=youtu.be)

~~~
bryanrasmussen
There is nothing about GraphQL that makes me think someone invented it because
they were annoyed by SQL and decided to reinvent it, generally reinvention
means a lot of similarity only badly done. You might argue GraphQl is badly
done in comparison to SQL, but surely not that it is similar.

~~~
siscia
Honestly I don't use it so often, but it seems that any query in graphql could
be easily and automatically translated to a SQL query. Am I wrong?

There are definitely trying to solve the same problem, aren't they? What are
the advantages of GraphQL over SQL?

Please, I really want to know the answer to this question.

The previous answer was "the infrastructure we build around GraphQL is better
for microservices", ok I can see that. But it is the only answer? It seems
like a little weak reason to create a language so that later you can create a
new infrastructure around it.

Am I missing something?

Why you don't find GraphQL similar to SQL?

~~~
bryanrasmussen
Normally when I see a language that was created to fix problems somebody had
with another language, then the two languages tend to be syntactically
similar. I don't see any syntactic similarity.

Secondly I don't believe that GraphQl is meant to map to the relational
algebra, which is the genesis of SQL.

GraphQL's benefit seems to be that you should be able to get all the data you
need and nothing more with one query, and get it back in the form you want it.
In the earlier comment that started this thread the commenter said something
like that's what SQL gives you, but from my experience if you want to get back
complicated data (3 joins, many properties with same names) your SQL statement
is going to be a lot more difficult to write and organize than your GraphQL
query. Writing the queries is generally really straightforward and it is quite
quickly clear how to structure a query to get what you want, and indeed if it
is even possible to structure the query. Ease of declaring what you want is a
valid reason for having a new language.

Structuring a query in SQL or most query languages are generally more
difficult than in GraphQL - in my experience. This of course does not mean
there are not places where it can get complicated - just generally not at
query construction time.

I can't really say if having a new infrastructure is a weak reason for
creating a new language, I guess that depends on the infrastructure that one
needs. Languages are generally really powerful tools for doing things, so if
you want to do difficult things with higher productivity than previously you
might feel encouraged to create a new language as part of your endeavors.

~~~
siscia
I really like your reasoning, thanks.

While I agree that GQL queries are simpler to write, it is also true that they
are much less powerful.

I personally don't believe that it is a valid reason for creating a new
language and all this infrastructure, but for some kind of project I can see
the attractiveness.

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

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

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

------
xwowsersx
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
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
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
No idea. gif makers are a plenty on the web nowadays.

------
intellix
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

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

------
goblin89
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
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
> move away from what we know and love

I didn't get the memo where we decided that we love JSON.

~~~
The_rationalist
Especially when there are almost consensual better alternatives
[https://hjson.org](https://hjson.org)

~~~
vertex-four
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.

------
foobar_
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
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).

