Functionality-wise:
This might be sth we didn't catch earlier-on:
When I send this payload

{
    limitUsers: users(limit: 1) {
        first_name
        last_name
    }
}

I get this back with the users' alias changed to lowercase

{
    "data": {
        "limitusers": [
            {
                "first_name": "Ikechukwu",
                "last_name": "Eze"
            }
        ]
    }
}

Originally posted by @iykekings in #22 (comment)

@iykekings I'll be creating an issue out of this recent suggestion(s) that you've made. To implement the Responder trait for all the other types that we're making responses from throughout the codebase!

Originally posted by @kolharsam in #30 (comment)

• Support for the ability to track and untrack tables

• #11
• #10
• #9

some/all of the operators that we can support:

Currently, we're using a map that would have the key to be the name of the root of the selection set.

So, if you have a graphql query like this

query {
     user {
          user_id
          name
     }
}

With our current code, support nested queries would be very difficult to achieve. Hence we need to come up with a better plan to tackle the same.

This would eventually need support for supporting nested queries

• add a websocket server that will work alongside the HTTP server
• the server should support the graphql-ws sub-protocol for communication with clients
  • graphql-ws - TS Server implementation https://github.com/enisdenjo/graphql-ws/blob/master/src/server.ts
• extend the same support for query's to subscriptions

Currently, we only have the ability to provide the response to the users if it's a query. Since a selection set is part of a query, we should be able to extend the support here as well.

https://github.com/sfackler/r2d2

https://github.com/BurntSushi/quickcheck

Support queries like this one:

query {
  user(distinct_on: name, limit: 10, offset: 10) {
    name
    uid
  }
}

Completing this feature would enable us to call this project a GraphQL server finally.

GraphQL Schema basics: https://www.apollographql.com/docs/apollo-server/schema/schema/

• Add support for keeping a live schema on the server
• Add support for parsing Fragments

Maybe after #15 is done, we could also have logs for websocket

Some of the options we could potentially support.

The GraphQL spec supports aliases and the current parser that we have also recognises them.

query {
     user: user_table {
          user_id: id
          name: user_name
     }
}

Either we have to

• remap the JSON upon obtaining the result from the DB [which I think is slightly harder]

OR

• update the SQL gen function to accommodate queries with aliases (the magical AS keyword)