Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Graphiti?

graphiti.dev

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Why Graphiti?

#11

Post by t0astbread »

onlydnaq wrote: post #7

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. In…

You'd have to keep users of your application in sync with database users though. And you wouldn't get complex backend logic out of the box without something like PL/(pg)SQL or database extensions (all of which are a bit unwieldy compared to an HTTP server).

Re: Why Graphiti?

#12

Post by bryanrasmussen »

siscia wrote: post #10
onlydnaq wrote: post #7

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. In…

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?

it is unlikely that all the data sources you will be querying now are directly available in an SQL database.

Re: Why Graphiti?

#13

Post by thrower123 »

siscia wrote: post #10
onlydnaq wrote: post #7

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. In…

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?

Exposing that much of your internal implementation details could be very problematic.

Re: Why Graphiti?

#14

Post by siscia »

bryanrasmussen wrote: post #12
siscia wrote: post #10

Earlier quoted context omitted.

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?

it is unlikely that all the data sources you will be querying now are directly available in an SQL database.

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.

Re: Why Graphiti?

#15

Post by vertex-four »

The_rationalist wrote: post #9
cuddlecake wrote: post #5

Earlier quoted context omitted.

> move away from what we know and love I didn't get the memo where we decided that we love JSON.

Especially when there are almost consensual better alternatives https://hjson.org

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.

Re: Why Graphiti?

#16

Post by siscia »

thrower123 wrote: post #13
siscia wrote: post #10

Earlier quoted context omitted.

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?

Exposing that much of your internal implementation details could be very problematic.

Sorry, I realize my first message wasn't as clear as I wanted.

You would not expose the internal implementation, you would simply accept SQL queries, maybe against a separate view of your SQL database, or maybe against a custom backend.

SQL shuould be the query languange, not the implementation.

Re: Why Graphiti?

#17

Post by onlydnaq »

siscia wrote: post #16
thrower123 wrote: post #13

Earlier quoted context omitted.

Exposing that much of your internal implementation details could be very problematic.

Sorry, I realize my first message wasn't as clear as I wanted. You would not expose the internal implementation, you would simply accept SQL queries, maybe against a separate view of your SQL database, or maybe against a custom backend. SQL shuould be the query languange, not the implementation.

That’s exactly what I meant as well. SQL may be the implementation, but if so with a well designed exposed schema, not with the application internals.

Re: Why Graphiti?

#18

Post by notus »

onlydnaq wrote: post #7

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. In…

Doesn't work that well when your databases are distributed and you're using microservices. You don't want to be doing join's across microservices and most setups wouldn't allow you to anyways. GraphQL provides that orchestration layer for you.

Re: Why Graphiti?

#19

Post by yodon »

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

Re: Why Graphiti?

#20

Post by 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.

Post reply on HN