GraphQL MN on Wednesday night had Christopher Bartling speaking on simple introspection.

The event was hosted in the same building as sdg, though not in their offices. We sort of went into a communal conference room that anyone who officed there could use. Ashley Sime, a recruiter for sdg, brought us pizza and the like, and there was some talk of this being the last sdg-hosted event. A different consultancy called Agosto gets to host next month. Christopher Bartling seems to be head-of-state of GraphQL MN and he seemed to speak by default without anyone else to speak at first until another presenter emerged at the eleventh hour of this one hour event. There was also some discussion of maybe falling into an every-other-month pattern for the meetup in the name of having more meaty presentations and speakers lined up to present. Another challenge here is that when Christopher asked us to put our hands up to show off who was actually using GraphQL less than half of the audience raised their hands. Everyone is interested in the future but not everyone is living in it yet. ILM had me at Thomson Reuters for two months and I was exposed to it a bit there myself, but I have since moved on from ILM Services. My new gig... promises/maybe/eventually... We shall see, eh? Christopher suggested that there are four things that could make up a payload being handed into a GraphQL posting. It is not fair to think of the payload as a query, but instead, the query is one of the four things. Another of the four is a mutation, right? This is how one writes records back in the GraphQL space. A query, in contrast, is a synchronous read. One can mix queries with mutations and one could mix queries and mutations with the other two things I am about to mention too, but Christopher asserted that he doesn't really see stuff that complicated in real life. I asked about the ReST convention of doing a POST and having a package come back to you with the id of the newly database-hydrated object appended to the object you just wrote a record for and if such a trick would demand a query in tandem with a mutation and another woman in the audience suggested that feedback from a mutation is just a part of a mutation. Subscriptions in contrast to queries are sort of like deferred queries as opposed to synchronous ones, kinda like Observables. Christopher described these as sever-sent events (SSE). Beyond what I was once told by Chander Dhall about how you could use Observables in Angular to listen at length to a web socket and the reality in contrast of people using Observables in Angular client-side to listen at length to the NgRx store, I think subscriptions are going to be used to listen at length to the server-side of things. (The Flask framework for Python does not let you do subscriptions. That is not a part of its graphing stuff.) Beyond mutations, queries, and subscriptions, the fourth thingamajig you might find in a payload is a simple introspection query. These are like other queries only they request type data from the server. In some code that Christopher showed off, we saw an introspection query like so for learning more about an enum named CollegeYear:

import {gql} from '@apollo/client';
let COLLEGE_YEAR_ENUM_VALUES_QUERY; = `
   query CollegeYearEnumValues {
      __type(name "CollegeYear") {
         name
         enumValues {
            name
            description
         }
      }
   }
`;
export default COLLEGE_YEAR_ENUM_VALUES_QUERY;

 
 

Resolvers are endpoints for resolving the various needs of GraphQL on the server-side. Christopher's resolvers in Ruby look like so. (I think he may have been using RubyMine as his IDE.)

module Types
   class CollegeYearType < Types::BaseEnum
      value *args 'FRESHMAN', description: 'Freshman'
      value *args 'SOPHOMORE', description: 'Sophomore'
      value *args 'JUNIOR', description: 'Junior'
      value *args 'SENIOR', description: 'Senior'
      value *args 'GRADUATE', description: 'Graduate'
   end
end

 
 

Random thoughts in wrapping up: Per Christopher, AWS AppSync has a way to approach GraphQL that is both so custom and so intrusive that it is hard to imagine ever decoupling from AppSync when you roll stuff with it. You use Velocity templates to define resolvers with AppSync. AWS Lambda is Amazon's serverless-functions-in-the-cloud things. Hasura, a company, offers tooling for making APIs friendly to GraphQL. Prisma is sort of an ORM that is more friendly to GraphQL than other ORMs.

Vivek Kalyanakrishnan of Target also spoke at this event and in the code he demoed he had breakouts for a resolver layer, a schema layer, and a service layer. It seemed logically while being a bit hard to follow. My eyes are not so great at age forty-five. Was the resolver layer in the server-side stuff and the service-layer in the JavaScript vein of things?