3 ms·
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 di
by 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 agoI 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 agoOf 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.