The first-ever GraphQL summit is already over, and I was lucky enough to attend and hear all the great things people have to say (including from one of the authors of the specification, Lee Byron). It’s hard to boil down all the knowledge into a single post, but I’ll do my best to distribute what I saw as incredibly valuable in both maintaining and starting a GraphQL service.
There’s a lot of talk and open questions on the web about how to handle intricate and mission-critical things like auth, access, and privacy. The answer that came from one of the major GraphQL contributors was to lean on existing infrastructure in your environment and not attempt to do everything in GraphQL.
This really resonated with me, as one of the key benefits of GraphQL is it’s ability to be incrementally adopted. You don’t have to replace your whole application/API with GraphQL. As a matter of fact it might be a wrong move to do in certain circumstances. In any case, keep your implementation thin; call to existing services and let the deal with hard work. Chances are (hopefully) you’re using something battle-tested and don’t have to be up late at night when things inevitably go awry.
GraphQL has an amazing set of tools. Use them. There’s an open door, as well, for creating even better tools as well. Things like code instrumentation, finding breaking schema changes on PR’s, and more that I probably can’t even think of. The ecosystem has a lot to offer, and a lot that’s still lacking, but utilization is key when writing and maintaining a GraphQL service.
This was the first time I’ve heard of predefined queries, so I can’t really point to any resources of value (I know, I’m sorry). However, the basic premise is this: as your UI/client code grows, so will the cost of computing all your queries (combining, aggregating them, referencing fragments and so forth). Eventually you’ll reach a point where your client becomes the bottleneck due to all the aggregation that goes on. Predefined queries aide in this matter by hashing a query into a pre-defined set so your client can just ask for data with a hash.
More on this as it grows and becomes ubiquitous, but an interesting concept to know about!
One of the things the very exciting things about GraphQL is that it’s possible to not have breaking changes in your API. Because of how the protocol works, it’s possible to monitor field usage and, when something isn’t used anymore, you can easily remove it. Once a field is out there and frequently used, it’s hard to remove.
You can generally get around this by letting the data itself drive your schema design, and not the relationship itself. Maybe a related post, or the parent author, is better used in a new object-type as opposed to flattening it in with the parent object. This lets you scope fields into a new namespace so you don’t have to worry about potential collisions later on.
With all the great mocking tools and other stubbing capabilities in GraphQL, developers can operate more agile in their workflows if they agree on one in the initial planning: the schema. Once you have a concrete schema, both back-end and front-end teams can work independently and more easily marry up their work when it comes time to deliver. This is such a powerful concept!
When dealing with raw DB access, it’s possible to create a lot of queries when you naively standup a GraphQL server. This is due to how resolvers work, and more specifically, how they’re isolated in way. To get around this, most implementations will batch, or really delay, execution of the queries until the next cycle of a of the event-loop (at least in Node’s case). Libraries like DataLoader will help with this, and projects like join-monster are more tailor-fitted for solving the problem holistically.
This was a great piece of advice from the conference that I personally am going to observe going forward. It really can be summed up by saying: don’t build for the hypothetical future, you aren’t going to need it then. Build against solid, real use-cases first, and then work from there. It’s all too easy to get caught up in over-engineering, yak-shaving, and whatever other metaphor you can think of for this. Martin Fowler has a great post on this for further exploration.
SO MANY great projects were shown off in talks or demo’d, and folks really should check them out. In no particular order, here’s the ones I found very incredible:
Lee Byron gave one of the best talks I’ve seen in a conference, and had a great list of questions to ask yourself when building stuff in general. I’m going to blatantly copypasta the here for your benefit:
Questions:
- Would a new engineer understand this?
- What might version 2 look like?
- Will this work for all future clients?
- What if the implementation changes?
Think about these things when writing your implementation, designing your schema, and really just building anything. They’re not easy ones to answer, but they’ll generally keep you on track and crystalize what needs to be done.
I hope this has been helpful to someone somewhere, and I look forward to the GraphQL Summit in 2017!