Highlights from the API Spec Conference 2019 in Vancouver

As Decathlon Canada developers, we get to attend to a few conferences a year. So I decided to go to one of the most sought after conferences in the API space: ASC 2019 in Vancouver, which is hosted by the OpenAPI initiative and organized by the Linux Foundation.

Canada doesn’t get a lot of tech conferences compared to our neighbours to the south, so we’re always really happy to be able to attend/organize conferences right here at home.

More about the nerdy stuff though; the API Specifications Conference (like the name says) is all about API specifications, tooling and standards being used and/or drafted for APIs. It also covers topics like monetization of APIs, entrepreneurship etc..

The talks were particularly interesting to our team, because at Decathlon Canada, we’ve been building an API-first platform to help developers get their apps up and running as quick and easy as possible.

Now, we’ve been focused on adopting standards and following specifications since the beginning, as you can see on my previous post we’ve adopted JSON:API for the Intelligence Sports API and GeoJSON for the Sport Places API, amongst others.

Talking to other engineers during coffee breaks between talks at the conference, I soon realized that there’s a trend happening in the community, and according to the talks and what I’ve heard from fellow developers, these are the upward trends on the API space:

⬆️ OpenAPI 3.0 (Formerly Swagger)

⬆️ GraphQL

⬆️ JSON Schema

And these are losing a bit of traction/popularity:

⬇️ XML

⬇️ Swagger 2.0

⬇️ REST * (watch out for that big asterisk)

Most of the conference was focused around OpenAPI 3.0+, it seems to be all the rage these days. A few speakers tried to preach the good word on JSON schema, but despite the enthusiasm around type checking, it didn’t get much traction. Partly, I believe, because these features are already supported by OpenAPI 3.0. JSON Schema and OpenAPI can operate together though, major difference being that OpenAPI assumes that your data is flexible whereas JSON Schema is more strict about types.

Moving on to the debate of the century though (and by century, I mean the last 4 years).

GraphQL vs REST

Most early-adopters of GraphQL (keep in mind that this is a technology developed at Facebook and published as recently as 2015!) are slowly gravitating towards moving their entire stack to a more flexible structure where clients receive only what they’re asking for and nothing more; resulting in lighter payloads and in some cases, fewer calls.

The problem with that is, like I mentioned before, GraphQL is a new technology and despite a lot of optimism around it, adoption has been slow and backwards-compatibility is still poor.

Some pundits also argue that there’s no real benefit to switching from a REST architecture to GraphQL, because of where the latter falls short (caching, shared architecture etc…)

The consensus among GraphQL speakers during the conference is that it’s not supposed to be a REST replacement in any way, but to be an an alternative to it.

Speakers covered a few notable differences, and made the following points:

REST and GraphQL differ on basic concepts.

GraphQL isn’t a magic bullet, nor is it “better”.

You can definitely use both at the same time.

GraphQL is awesome if used for the right thing.

Github maintains both architectures for their APIs and were firm on warning developers that REST is not fading away nor being deprecated. GraphQL is their alternative here, not the other way around.

OpenAPI (formerly Swagger)

Another hot topic during the conference was the use (and benefits) of OpenAPI 3.0+ to describe your API. I discovered a whole ecosystem of tools to make the transition easier and migration a little less painful.

Most of these tools are aggregated on this list: https://openapi.tools

Some of my favourites (and the ones that we’ll be trying out on the Sports / Sport Places APIs) are:

• Swagger Editor (for definition file manipulation)
• CodeGen (automated SDK generation in multiple languages)
• RSwag (Ruby library to generate definition based on your controllers)
• Dredd (HTTP API Testing Framework)

API Monetization

Switching gears a bit here, let’s talk about another conversation I’ve had with other developers and CTOs from projects in companies like eBay, Google, SmartBear etc..

The conclusion that I reached is that, this is a lengthy process, most of these companies worked on these APIs for years before they became profitable. eBay now makes north of $500M/year with their API offerings, and being one of the first players in the field, they started off all the way back in 1997.

The key to make an API profitable is not just the technology you pick or how big your team is, but finding a feature that your customers find indispensable, and then they become dependant on it.

Conclusion

The thing I love about going to conferences is that I always get to meet smart people and learning from them. There’s just so much I need to catch up on, and so much that can be done to make our lives easier.

In the next few months we’ll be working on implementing our API definitions with OpenAPI 3.0+ and testing for type check, improve our documentation, follow new standard specifications and look at how GraphQL can improve the usability of our APIs based on feedback.

Let me know if there’s anything you’d like to discuss, or if you have any suggestions. I would love to hear your feedback: developers@decathlon.com

Also, we’re always looking for talent. Check out our openings at https://developers.decathlon.com/careers