This is technically the second time this meetup group has met although the first time was well over a year ago and Zach Lendon and Scott Silvi who are the keepers now were not the keepers then. It's interesting that a new group is spun up while tying back to a one-off meeting of yore. I guess you can send notifications to all of the "members" that way. In theory, this thing will meet again and this will not be more flash-in-the-pan fluffiness and it is easy for me to believe that as GraphQL itself is not going anywhere. Its footprint in our lives should only grow. A programmer since 1977, and namedropping esoteric things like the Ada scripting language which I had never heard of (it's an extension from Pascal apparently), Tamara Temple uses GraphQL with React which seems to be where most of the adoption is thus far. Her environment is also on top of Ruby and she uses both the graphql-ruby gem inside of her Ruby on Rails application and also Webpacker, an independent API which lets you put all of your assets in a bundle and send them off/elsewhere. Some of the notes that follow come directly from Tamara, but others were just said by the crowd and I do not mean to suggest that any one person said any one particular thing as this tech talk would quickly evolve into a group discussion. Do note that I use the word evolve and not the word decay. There were maybe twenty of us in a side room at 612Brew (a bar/brewery in Minneapolis) and it was loose and chatty. It is important to note that GraphQL is just a specification, an idea. There has to be technology beyond the idea that actually implements it and instantiates it. You may use Apollo Server to serve up GraphQL and, in a React app, Apollo Client to catch what the server coughs up in your JavaScript. Apollo was made by the same team that cooked up Meteor which comprehensively has a frontend framework like Angular and a backend architecture in and of Node (see the parallel to Apollo?), and Apollo is open source software and seems to be winning its space. Axios, fetch, and Relay are rivals. The New York Times is apparently stuck on Relay to its detriment. That was a bit of random gossip dropped. There are many challenges with how to do GraphQL and accepted patterns have yet to be defined. Presently we are in an anything goes Wild West. Instead of making a dozen ReST calls for bits of data you can get one big graph but how do you traverse the graph in your JavaScript without writing a bunch of spaghetti code? You can version a ReST API (though as much is really an antipattern) but there is nothing like that in the GraphQL space so that begets a challenge when an initial graph has to be expanded to accommodate another consumer. How do you make it grow without growing pains? You may aggregate in other web service calls with GraphQL and as a graph grows fat and loops in more and more stuff there will naturally be a performance hit to be had. TypeShift is a library for generating TypeScript types for what GraphQL provides. A fragment is the data definition part of a subquery (the assignment half) and you may use a predefined fragment in multiple places in a query. (Queries for getting the right stuff back from a graph are often going to be complicated and unclean.) The term query implies a read and the term mutation implies a write in the nomenclature. It might be smart to whitelist queries so that not just anything may be queried opening the door for an extremely expensive query. You will need to hand in something for authentication when you use GraphQL in the name of security. Mark Soule was the opening act. He had a slideshow which posed a bunch of questions and in many ways set the tone to invite a group discussion ahead during Tamara's time. One of the things he mentioned, for example, is that you may have a nested tree of errors come back from calling GraphQL implementations all while the greater request ultimately returns a 200 response, so the pass/fail mindset of a ReST call does not apply in this new space. Some of what is above stems from Mark.
No comments:
Post a Comment