{nonsensecodes}
Published in

{nonsensecodes}

016: GraphQL Contributor Days

This is a continuation of a series following along with my learning journey for GraphQL + Insomnia. Find the source code to follow along with here.

GraphQL

ThisDotMedia (twitter), in partnership with Hasura (twitter), put on a virtual GraphQL meetup where GraphQL community develops gathered in a public forum to discuss the current state of GraphQL and future considerations for the spec and related tools. The event lasted about four hours and provided some insight on things that are being looked at and how some of these things might be addressed. Rather than dive into code for the day, I joined in to listen and learn. And while I didn’t learn anything that would be immediately useful to me, it was a step in the right direction toward becoming a contributing developer to the GraphQL ecosystem.

These things matter. Especially when the landscape is currently littered with abandoned projects and outdated lessons.

One of the biggest messages put forward at the beginning of the session regarding the further development of the spec and relevant tools was a sort of hanging up of a “help wanted” sign. There was some discussion about how to bring new developers up to speed with GraphQL, and how best to onboard new contributors to GraphQL-related projects. Urigo summed it all up when he said, “come help us. Now the doors are open.”

There was a pretty big discussion surrounding microservices and best practices regarding the wrangling of multiple APIs. While some of this discussion centered around how this issue was being approached, there was a strong suggestion that applications should be built inclusive of the services they offer as opposed to building out microservices and then working to unify them. It seemed this was a defining point of the difference between REST and GraphQL. Because REST is built to deliver data over multiple endpoints, unifying microservices is moot. Extra steps need to be taken to harness the power of GraphQL when unifying microservices, and there is currently no standard for doing so: different organizations and developers are tackling the issue differently.

Piggy-backing on the discussion of unifying microservices was the idea that “separation costs,” and it gets expensive. There was some talk of duplicating code, and how initially this is okay to quickly get up and running, though this would eventually have to be taken care of. I diverged from the general consensus on this point. For one, there’s a strong culture of bringing a product or service to market as quickly as possible at whatever cost is necessary, and this has numerous ill-gotten side effects: problems that start off small grow very quickly and require much more work later on to be corrected — this idea of “tech debt”; and this also perpetuates the “fast food” culture, that products and services can be delivered quickly, never mind their efficacy and longevity. Furthermore, it’s this culture that pushes budding developers into only learning what they need to know to ship something and to simply accept they’ll spend most of their developer lives troubleshooting. In the words of Kyle Simpson, “you should know your tests will pass before you run them.” This kind of competency doesn’t happen when you’re trying to get something out ASAP. As I tell my clients and students in yoga and fitness, “do it slow and do it right.” We need more “learn to do it right,” and less “get it out as fast as possible.” We need to begin building a culture of patience.

Moving on, the idea of “Schema Design Anxiety” was brought up as part of the discussion of unifying microservices, and this served as a segue into discussing the API lifecycle. Versioning was discussed at length with more vocal parties advocating for versioning. GraphQL is, by nature, version-agnostic. Or it’s supposed to be, from what I understand. Because Schema design builds on the field level, it shouldn’t be necessary to redesign the schema. Apps, however, are not version-agnostic, and I think this is where the concept of versioning GraphQL instances stems from. The best argument I heard in favor of versioning is that new versions provide a point upon which better communication can be built between clients and GraphQL API developers.

Documentation was discussed, and I was happy to hear a suggestion brought up about creating documentation to assist in entry points for an API. Documentation that exists within a schema is only so useful — a consumer of the API would already have to have some familiarity with the API to make use of it. Entry level documentation and tutorials would provide better onboarding for developers looking to create applications that would consume data through a GraphQL API. This would be of major help to those developers seeking to learn GraphQL as well.

There was much more discussed, and of course in far more detail than I can comfortably include here. Though this is all very high-level and more than I can presently make use of, this does provide me with some vision: knowing what to look for will help me make better decisions in the routes I take for learning. First thing’s first though: as any proficient gamer would tell me, I’ve got to “Get Güd.” Competency first, building and disrupting shit next.

You can watch the replay here.

016/100

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store