Merging and removing duplicate query resolvers.

[beingnoble03]

• In Adds non-nullable type in list and adds first and skip in connection. #1075, it was decided that currently talawa-api has no correct implementation of relay graphql cursor connection. (See the documentation here)
• So, it's better to remove Connection word from the query resolvers having where as a parameter, but there are many pairs of query resolvers like example and exampleConnection which obviously are similar to each other.
• Also, the work of example can be easily done by exampleConnection.
• So, now we need to correctly merge these and then, correct the queries from the client side.

What would be the right strategy to make this change happen?

[beingnoble03]

@palisadoes @xoldyckk @DMills27 the discussion can be continued here. I have summarised the discussion from #1075 in the description.

[beingnoble03]

@xoldyckk @palisadoes continuing the discussion here.

• Should eventsByOrganization and eventsByOrganizationConnection be merged? Considering that both return the same type of data and eventsByOrganizationConnection isn't even the correct implementation of the relay Connection. This will require few changes in documentation and, query and implementation changes in talawa-admin. As it this query is not used in talawa-mobile-app, it should not be an issue there. Should I open corresponding issues?
• Same can be said for getDonationByOrgId and getDonationByOrgIdConnection. It will be easier for this because it isn't implemented in client side yet. So, no changes there.
• Same can be said forpostsByOrganization and postsByOrganizationConnection. This will require changes in all the repos talawa, talawa-admin and talawa-api.

[beingnoble03]

Should I create corresponding issues for these in the respective repos?

[xoldd]

@beingnoble03 I personally think that all objects which are uniquely identifiable in the database should be exposed using node interface and nested relations. So, instead of having a seperate root Query field like eventsConnectionByOrganization you just need to query it within a node interface query field Organization.eventsConnection.

For a graphql server schema like this:-

interface Node {
  id: ID!
}

type Organization implements Node {
  id: ID!
  eventsConnection: EventsConnection
  # ...other organization fields
}

type Event implements Node {
  id: ID!
  organization: Organization
  # ...other event fields
}

type EventEdge {
  cursor: String
  node: Event
  # ...other event edge fields
}

type EventsConnection {
  edges: [EventEdge]
  # ...other connection fields
}

type Query {
  node: Node
  # ...other root Query fields
}

We'd query the events for a particular organization like this:-

query QueryOrganizationNode($id: ID!) {
  node(id: $id) {
    ... on Organization {
      eventsConnection(first: 20) {
        edges {
          node {
            id
            # Event node here
          }
        }
      }
    }
  }
}

You see, we don't need to expose plethora of root Query fields just for every relation of an object. They can simply be queried using the node interface query field.

I think we need a complete overhaul of the currently present graphql schema and reimplement it to better represent relationships between fields and also expose additional fields whereever required which are not represented in the database itself.