We interview William Lyon of Neo4j, a speaker at the upcoming Austin API Summit 2019.

William Lyon is a Developer Relations Engineer at Neo4j, the open source graph database. With experience working in several nimble startups, William’s current work is focused on GraphQL integrations — in fact, he’ll be joining our “Diving into GraphQL” LiveCast later this month.

Currently, I’m working on GraphQL integrations for Neo4j, with a focus on making it easy for developers to build GraphQL APIs on top of Neo4j. As a result of this work I maintain
neo4j-graphql.js and am a contributor to GRANDstack.io.

See William at the Austin API Summit

If you’re interested in the topic of GraphQL, you’ll be glad to know that William will be dedicating his session at the 2019 Austin API Summit to just that: building and consuming GraphQL APIs. Needless to say, it’s a topic he’s pretty passionate about.

I’ll be talking about building and consuming GraphQL APIs, with a focus on using serverless and cloud services to build scalable GraphQL APIs – basically how to do fullstack GraphQL. I’ll cover some lessons I’ve learned about working with GraphQL over the last few years, and why it’s a complete game changer for those building APIs, and for developers building applications that consume APIs. It’s really a new way of thinking about data in the context of APIs.

This talk should be interesting for those who are considering building a GraphQL API, or anyone who has heard about GraphQL but doesn’t yet understand what all the hype is about. I’ll also talk about some of the emerging tools that make it easier to build GraphQL APIs and how you can leverage them.

Our Neo4j-GraphQL integration is just a small part of that community, there are lots of amazing tools available for building GraphQL services in many different languages and frameworks as well as awesome client side tooling for building applications on GraphQL.

Moving Forward with APIs

Moving on, we asked William about the API design trends he’s looking out for in 2019. Needless to say, GraphQL is pretty high on his list — and a big part of that is due to the community’s efforts to push development forward!

Well, I’m certainly excited about GraphQL and how the GraphQL ecosystem is evolving.
GraphQL is still fairly new and there’s certainly growing interest around it, but the ecosystem of tools in the GraphQL community has exploded as well. When GraphQL was open-sourced by Facebook in 2015 it quickly became clear that the community was interested in building tooling to make working with GraphQL more streamlined. We’ve seen tooling to make it easier to build GraphQL APIs on top of databases, add authentication, and even ways to extend GraphQL while still being compatible with the ecosystem tooling.

In terms of the strategies we can use to propel APIs into up-and-coming industries such as IoT and AI, there’s no single answer. William looks at the example of IoT, explaining how device compatibility and network speeds should be two of the biggest considerations when developing APIs for this market:

For IoT, versioning and backward compatibility of APIs will become even more critical as the number of outdated devices not being updated grows exponentially. It’s much more difficult to ensure an API’s clients are updated when we’re talking about smart toasters connected over a legacy cellular network. Being able to maintain API backwards compatibility to ensure these devices still function as intended even years after receiving updates is key to evolving the IoT space.

A related point for IotT is that I think it’s especially important to consider offline first and poor-network environments when designing APIs, as devices are not always connected to fast neworks. Indeed these considerations were at the forefront of GraphQL’s initial design — minimizing the number of network requests and reducing the data sent to only exactly what the client requests, so as to optimize mobile app performance over low quality wireless networks.

When we asked William for his take on where the API economy is heading, he drew our attention to the changing profile of personal data usage. William says that businesses who previously relied on user data for their business model will now have to tread carefully.

I think we’ll be seeing impacts in this space from the increased awareness and concern over data privacy and increased regulation (such as GDPR). Businesses have realized for a while now that they can monetize user data by packaging it up and selling access (think of Facebook’s now-neutered Graph API) or by building services on top of this data (such as targeted advertising), but the backlash over data privacy and increased costs of complying with regulation are making these practices potentially less valuable and more risky.

For these companies that are offering access to user data as part of the API economy they need to reconsider how to extract value from this data. Is it still worthwhile to sell access, even at an aggregated level? Could they instead find value by using this data internally? As a result I think we’ll see more APIs reducing the amount of user data they’ll expose, instead choosing to be in direct control of how this data is monetized.

William believes that this shift in the way we share user data could lead to the demise of more small-scale applications unless developers structure their relationship with API providers on a deeper, business-conscious level.

This has significant impact for API consumers and developers building on 3rd party APIs. We’ve seen when providers choose to lock down these APIs (for example LinkedIn and Twitter have both had significant restrictions to their APIs over the years) many developers have seen their applications that depended on these APIs shut-down. That makes it dangerous for developers to build on these 3rd party APIs without formal business relationships, meaning organizations should consider making an investment in developing a robust partner ecosystem to solidify these business relationships.

When we asked about the role of APIs in enterprise-grade cloud architecture, William replied as follows:

APIs are critical for cloud architecture because APIs decouple implementation technology and data model from method of access – without them outside users would have to know too much about the underlying technology and data to make cloud services useful. As we move more and more infrastructure to the cloud, APIs become a way to stitch these services together.

I’ll mention GraphQL again as a way to accomplish this. It’s become a common pattern to use a GraphQL API as a way to stitch together data from various services and domains across an organization. The concept of GraphQL’s idea of “One Graph” with federated implementation, popularized by Apollo’s Principled GraphQL, provides a framework for this idea of stitching together disparate services via GraphQL.

Build Better APIs

Enough on where the API landscape is headed — let’s talk about how we can build and consume better APIs in the present day. Part of that starts with offering a fantastic developer experience, which William says lies in the documentation:

Great documentation is key. I can remember some very grumpy days spent working on integrating our app with new APIs and being so frustrated with poor documentation. Not to point any fingers, but the real-estate and finance industries aren’t exactly known for building beautifully documented APIs. Poor documentation can make it very time consuming for developers to build against your API or troubleshoot when things turn wonky.

Just to make you completely cognizant of how hardcore a GraphQL fan he is, William explains how GraphQL makes documentation easier:

And this is one reason why I love GraphQL so much. GraphQL APIs are said to be self-documenting, through GraphQL’s introspection feature. The GraphQL schema becomes the specification and documentation for the API and with tools like GraphiQL and GraphQL Playground can be searched and explored easily. GraphQL’s type system also ensures the client will receive exactly what it expects.

As for API security, William suggests that we move to using dedicated API management and security services so we can dedicate more time to the products themselves:

One consideration here is to support the move to managed services. For most businesses there’s very little unique business value to be had from implementing security (or managing infrastructure for that matter) – that’s just a standard feature that needs to be taken care of.

Letting organizations that choose to make security and managing infrastructure their core business ensures that the experts are taking care of these functions and we can get back to focusing on building services, applications, and solving business problems. For example, take advantage of database-as-a-service offerings like Neo4j Cloud and identity service providers such as Auth0 as there’s little business value added from managing these in-house.

Useless APIs

Time to lighten up a little — what’s William’s favorite “useless” API? It’s none other than An API of Ice and Fire, the Game of Thrones-inspired API which exposes data about the fantasy’s characters, battles, and so forth.

At Neo4j we’re big fans of working with Game of Thrones data as an example for data modeling, visualization, and how to apply graph algorithms. With this API you could, for example, pull in data about character interactions, run PageRank to find the most influential people and community detection to infer allegiances. Being able to demonstrate that type of data analysis on data from a TV series is fun and engaging, but also a great proxy for how those same processes can be applied to “boring” business data to deliver real world value.

Closing Up

To wrap up our interview with William, we wanted to loop back to the topic of our 2019 API Summit in Austin, where he’s excited to meet new people and eat tacos.

Of course I’m looking forward to meeting lots of new friends at the API Summit and I’m sure I’ll learn a lot about APIs, but Austin is a really fun town. And of course I’m looking forward to the BBQ and breakfast tacos, but one thing I want to do this year is see the bats fly out from under the Congress Ave bridge over the river at sundown. I think about this every time I got to Austin but have never actually done it!