APIDays 2018: Gravitywell goes to Paris!
This December, Jesus, Luke and myself were lucky enough to attend APIDays Paris 2018. Billed as the world’s leading API conference series, it was a chance for us to connect with other developers in the field, catch up on the latest research and best practices, and bring home some new ideas and skills. With tracks focusing on everything from emerging API technologies to system design to DevOps and improving developer experience, we had plenty of topics from which to choose.
We already rely heavily on APIs to bring our microservice-based architectures together. We love working this way as it allows us to keep our front and back-end systems separate and modular, making it easy to extend functionality and build optimised apps for different use cases and markets. APIDays was a chance for us to make sure we’re at the cutting edge of the available technologies and take an introspective look at the way in which we manage API-based products and projects.
There was enough information packed into two days of talks to fuel months of research, development, and reports but here are the talks that lit a fire under each of us.
Henry's Highlight: Crafting the Developer Experience
DevEx wasn’t a term I’d specifically come across before and it took a bit of explaining. As you might imagine, DevEx is to developers as UX is to users. Entrepreneur and incredible moustache owner Adam Kalsey explained it from the perspective of both internal (i.e. those on your team) and external (those consuming your API) developers. The focus is on providing tooling and documentation that are not only fit for basic purpose but are delightful to use.
“Delightful in this case” boils down to 6 key principles. You need to make sure what you provide is:
- Easy to understand - clear concepts, jargon-free, and honest in its explanation.
- Easy to use - open, quick onboarding, minimal gatekeeping (who wants to wait hours for an API key?), simple access management (no more “what do you mean the token expires every 10 minutes?!”), guided by relevant examples.
- Easy to build on - simple to understand style guides, consistent conventions throughout, smart and intuitive default system behaviours.
- Easy to get help - don’t skimp on release notes and changelogs! Breaking changes are fine provided they’re always documented.
- Easy to trust - explain new (and potentially daunting) approaches, avoid over reliance on one person or point of failure to limit risks.
- Easy to maintain - if maintenance is hard, it won’t happen! Without regular, clear updates, a platform risks feeling outdated before it’s even had a chance to mature.
Above all, Adam turned the cliché that developers are lazy into a constructive message - if you make it easy to do the wrong thing and hard to do the right thing, sooner or later people will start doing things the wrong way, regardless of their best intentions.
Gravitywell is a constant hub of collaboration on projects, which means there are always a lot of questions, requests, and clarifications flying around the office. While we always take care to apply common sense and good working practice to our systems, Adam’s recommendations for focusing on good DevEx still gave us food for thought. It’s definitely something to keep in mind as we work on growing our microservice architectures and building more complex product APIs.
GraphQL & AWS AppSync
GraphQL is a growing concept of API communication which is being used and supported more and more every day.
It was great to hear how other development teams were using it and their thoughts. The conclusion of GraphQL at API Days reinforced my hunch that I was not going to be replacing REST, but instead be an addition to the API stack with its flexibilities and transparencies for development teams.
Earlier this year, AWS released a product named AppSync. Its purpose was to create a GraphQL endpoint for new and current API’s while offering offline write-through communication between the frontend and server via their new AppSync SDK (via npm). It was amazing to see the possibilities of AppSync with an AWS demonstration and seeing just how secure GraphQL via AppSync can be, bearing in mind that GraphQL security has been a big topic within the industry recently with some development teams putting on the brakes from adopting it themselves.
Its serverless architecture was an added bonus and the ability to use existing RESTful endpoints to act as a GraphQL server via AppSync’s resolvers.
DevOps is being adopted more and more these days, leading to many companies having lots of experience with it. DevOps and the philosophy surrounding it was a main topic during the conference. It was great to hear that Gravitywell was on track within the industry when compared to development teams.
Companies with vast amounts of experience with devOps gave great insight into their procedures and philosophy, especially as devOps has always been seen as a must-have by many developers. Companies who touched on the topic seemed to be asking the same questions as I have surrounding devOps. This has lead to the same philosophical outcome for myself and multiple teams thinking whether they should adopt it for their project.
Below are some of the philosophical examples regarding devOps:
- If there is no product, then there is no money - Code quickly and then devOps once the product exists. Only then you will fully understand what is needed.
- Developers are clever, but as developers we have to protect ourselves from ourselves. Otherwise budget and deadlines will never be meet.
- Keep production simple not complex - You can strangle yourself and others if you give yourself too much rope.
Infrastructure & CI/CD
Serverless was another main talking point during the conference. Companies were demonstrating how they use CI/CD for their serverless functions and how serverless helped them with their Blue/Green deployment issues when using traditional servers and containers.
CI/CD was talked about, however the topic was more about evangelists telling other teams to adopt the process. CI/CD procedures had no breaking changes and reinforced our current methodologies and procedures.
Digital Identities Are Coming
I went to an interesting talk regarding digital identities and how banks are using them more and more for security. Talks fell on the similar lines of Green Motion and issues surrounding identity data and the constant naming conventions throughout its structure.
Two frameworks have been created to address this issue:
- eIDAS (Europe)
- NIST (US)
Digital identities will start to be used to verify the identity of an individual between different API providers. This is to improve security and as a means for consistency of data between the two providers.
SSE & HTTP/2 Multiplexing
Currently websockets and IBM’s MQTT as a HTTP/2 polyfiller remains popular due to old tech which still requires a HTTP/1.1 connection. It is worth noting that currently websockets will not be support HTTP/2 in the future.
Server-Sent Events with HTTP/2 multiplexing was touched on, demonstrating the future of websocket event-like communication but without the negatives of a traditional websocket. However the technology still needs to mature and become more widely supported by browsers such as Chrome and Firefox - What this space.
We found some really good talks at the APIDays conference, so here a handful of useful takeaways from Paris.
Maybe the most important topic of the first day, DevEx is a thing (Henry agrees with this), so take care of it:
- Know your audience and what you want to transmit, not every API can/must be designed the same way. Good examples of this are: Stripe (simplicity) and AWS (complexity but ordering and reliability).
- SDK implementations. Be transparent with your consumers, explain what is the HTTP architecture behind the scenes: caching policies, security control, automated retry system in case of recoverable failure and any other middleware.
- Study your consumers (similar to “Know your audience”). Divide them into sectors – eg. beginners, experts, influences - that will allow you to target them separately.
Some useful topics to keep in mind:
- Biggest attacks often come from known users (a.k.a. authenticated users) whether because an identity has been stolen or because users with low privileges find a gate to execute actions designed for users with more permissions. Keep a rigid control of what users can do in your system and try to avoid generous permissions. If the identity of an user with elevated privileges is compromised this will restrict the damage.
- Take for granted your system will be attacked and… they’ll succeed. Just build up mechanisms to detect it as soon as possible. Artificial Intelligence and Machine Learning can help you to keep your API Security.
- Apps that are subject attack with XSS (cross-site scripting) should consider storing authentication tokens using Cookies. Reason: successful attackers would have access to the data your app trust in local storage.
Large subject in the second day. Different companies generously provided their experiences with this technology. Although at Gravitywell we had already played with it, the insights from different people has helped us to understand how we could take advantage of its options in future projects, really promising. Complementing Luke’s points:
- GraphQL makes your life easier if... you are a frontend developer, but more complex if you are a backender!
- Prevent breaking changes in your API with graphql-doctor.
- Control the information accessed from GraphQL requests. Queries can be quite expensive and they might trigger several calls behind the scenes so include resource limitations. See GitHub nice example.
- Following the last point… Build an API Gateway to control what is accessed and by who.
Other non-technical topics worth noting:
- Celebration! This was repeated several times throughout the conference: celebrate achievements with your team, especially after high intensity periods of work. It is important to keep the group motivated :)
- Technology and environment: the future of the world is in our hands… or at least at the moment. Interesting the point of view provided by Jean-Marc Jancovici and team at The Shift Project. What I think: technology could and should help humanity keep the sustainability of our progress.