squealy

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

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 aft

We hadn't thought about it honestly, mostly because we don't use MSSQL as much with Python. However, it shouldn't be too difficult to add support if we have the right drivers. I've created a ticket here to keep track of it - https://github.com/hashedin/squealy/issues/223.