Hacker News Reader

Comment by OutOfHere | Hacker News Reader

GraphQL actually holds value in my view as it gives custom SQL-like functionality instead of basic JSON APIs. With it, you can do fewer calls and retrieve only the attributes you need. Granted, if SQL were directly an API, then GraphQL wouldn't hold too much value.

Langchain has no such benefit.

View on HN

SQL has sophisticated WHERE clause support, GraphQL doesn't. It should be called GraphPickL.

Surely SQL is an API? The line between language and API is fairly blurry.

Can you elaborate?

What GP means is it is a Programmable Interface, any interface you can interact against is an API. That means any programing complete language is an API, so are sign languages or human languages.

While nobody does it , SQL implementations have network API, authentication, authorization, ACL/RBAC, serialization, Business logic all the things you use in RESTful apis can all be done with just db servers.

You can expose in theory a direct SQL API to clients to consume without any other language or other components to the stack .

Most SQL servers use some layer on top of TCP/IP to connect their backends to frontend .libpq is the client which does this in postgreSQL for example .

You could either wrap that in Backend SQL server with an extension and talk to browser and other clients in HTTP[1], or you can write a wasm client in browsers to directly talk to TCP/IP port on the SQL server

Perhaps if you are oracle , that makes sense, but for no one else, they do build and push products that basically do parts of this .

[1] projects like postgREST basically do this .

SQL (as an API) and databases are orthogonal, though. In fact, I work on an application that uses SQL for its API even though it doesn't even have a database directly attached. All of its data comes from third-parties that only make the data available using REST services.

In theory, the app servers that sit in front of those databases could just as easily use SQL instead of GraphQL. Even practically: The libraries around working with SQL in this way have become quite good. But they solve different problems. If you have a problem GraphQL is well suited to solve, SQL will not be a suitable replacement – and vice versa.

I didn’t say it was a good idea , just elaborated that it is possible.

Even if it was easy and solved it all the things say GraphQL does it is still a bad idea .

Scaling app servers is relatively easy especially if stateless and follow some of the 12f principles, scaling SQL server horizontally is hard.

Multi master , partitioning, sharding even indexing very large tables , de-normalization is ripe with pitfalls and gotchas and many times what works for one app won’t work for the next , keeping the store simple and as less logic as possible saves a lot of pain

Of course it's possible. But you are not beholden to using a database server to use SQL. The app servers can speak SQL too. And, in some cases, should. It is sometimes the right tool for the job.

But if GraphQL is a good fit for your situation, SQL is not. Aside from both enabling ad-hoc execution, there is little overlap between them. They are designed to solve different problems.

I was curious whether you were using "API" as shorthand for something like "HTTP API" or something like that. It seeemed odd for you to say "Granted, if SQL were directly an API, then GraphQL wouldn't hold too much value" when you actually can use SQL directly in this sense. The reasons that people generally don't are interesting in their own right.

(If I recall - one of the criticisms of GraphQL is that it's a bit too close to actually just exposing your database in this way)

You can implement a GraphQL service in anyway you desire. There is no inherent relation to the storage solution you use.

GraphQL isn't anywhere close to being similar to SQL, so I find the desire for an analogy very confusing.

To me, these are grammars for interacting with an API, not an API.

To me, it is like calling a set of search parameters in a URL an API or describing some random function call as an API. The interface is described by the language. The language isn't the interface.

What is your definition of API?

The normal definition, I believe.

A software interface between entities (components, programs, etc) that allows for communication between those entities.

What is yours?

> if SQL were directly an API

Isn't that what SQL/CLI is for? https://publications.opengroup.org/c451

Sql IS an API, as in android programming, you just use sql as an API to access SQLite, literally.

Reply on news.ycombinator.com