3 ms·

Can you elaborate?

manquer 2y ago
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 .
- randomdata 2y ago
  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.
  - manquer 2y ago
    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
    - randomdata 2y ago
      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.
andybak 2y ago
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)
- newzisforsukas 2y ago
  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.
  - int_19h 2y ago
    What is your definition of API?
    - newzisforsukas 2y ago
      The normal definition, I believe. A software interface between entities (components, programs, etc) that allows for communication between those entities. What is yours?

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 .

randomdata 2y ago
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.
- manquer 2y ago
  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
  - randomdata 2y ago
    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.

andybak 2y ago

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)

newzisforsukas 2y ago
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.
- int_19h 2y ago
  What is your definition of API?
  - newzisforsukas 2y ago
    The normal definition, I believe. A software interface between entities (components, programs, etc) that allows for communication between those entities. What is yours?