[ksri]

I have been working on an idea to leverage SQL + REST APIs instead of GraphQL to solve the similar problems, and I would love to get some feedback on it.

GraphQL is great during development, but in production you often use "persisted queries" to prevent abuse. Persisted queries are also a way to use HTTP GET instead of POST, and thereby leverage HTTP caching. As such, if you swap out graphql and use sql during the development phase, you perhaps can get similar benefits.

My solution (https://github.com/hashedin/squealy) uses SQL queries to generate the API response. Squealy uses a template language for the sql queries, so you can directly embed where clause from the API parameters. The library internally binds the parameters, and is free from SQL injection.

Handling many-to-many relation, or many one-to-many relations is done in-memory after fetching data from the relational database. This provides the same flexibility as GraphQL, but of course requires you to know SQL.

Here is an example that builds various StackOverflow APIs using just a YAML+SQL based DSL - https://github.com/hashedin/squealy/blob/master/squealy-app/...

Squealy is still work in progress, so don't use it in production. But I would love to get some feedback!

[gautambt]

This looks really cool! Particularly for the embedded analytics use case.

Do you have an example of how this would work on the front end with relationships. For example if I want to fetch posts and their comments how would the front code look like?

[ksri]

Yes, following relationships is a key feature of Squealy. Here is an example for a recent-questions API - https://github.com/hashedin/squealy/blob/master/squealy-app/....

In short, with 1 GET API call that uses 3 SQL queries, you are getting a list of questions, related answers and related comments.

You should parse that example as follows - 1. The first SQL query fetches all the questions, filtered by API parameters 2. The second SQL query fetches all comments for the questions selected in the first query. See the `WHERE c.postid in {{ questions.id | inclause }}` part - questions.id is coming from the output of the first query 3. The output of the first and second query is merged together on the basis of the questionid that is present in both the query output. 4. Similar approach is used for all the answers