Skip to main content
Category

Blog

OpenAPI Initiative Newsletter – June 2024

By Blog

Welcome to the OpenAPI Initiative June 2024 Newsletter, our regular round-up of the latest stories from across the OpenAPI landscape.

Initiative News

We are excited to announce version 1.0.0 of the Arazzo Specification! Arazzo is the new official name for the Workflows Specification, which was decided on by the community after many rounds of debate. Arazzo is a specification that allows API providers to describe sequences of API calls, both within one API or across various APIs, with the means to link them together so implementers can orchestrate a series of steps based on known success and failure criteria. Arazzo is a significant step forward in describing the increasingly complex API landscape. You can learn more about Arazzo in our announcement.


The announcement of the Arazzo Specification means that the OpenAPI Initiative is moving to a multi-specification organization, with the OpenAPI Specification and the Arazzo Specification both falling under the OpenAPI Initiative umbrella. This will change how we maintain specifications consistently, especially as we add more specifications in the future. We will discuss this in a future post that describes our evolving landscape and governance approach in more detail.


In case you’re wondering: Arazzo means “Tapestry” in Italian, and was chosen because the specification is both about intricately weaving together something out of smaller things, and about telling a story that ends up being bigger than the sum of its parts.

Specification News

With planned patch releases for the 3.0 and 3.1 branches coming up, it’s “clarification season” in the OpenAPI Specification project. These changes address common questions and confusion, to make sure that the specification is as clear as possible. We’ve also made improvements to the tooling for publishing the specifications as HTML from the Markdown sources that we maintain in the repository, in preparation for releasing new versions. You can see all the changes and activity on the OpenAPI-Specification repository on GitHub.

Our biggest contributor for clarifications to the OpenAPI Specification and fixing an enormous number of ambiguities and open questions in the specification is Henry Andrews. A big thank you to Henry for all his effort in making our “small print” readable by anyone.

Our weekly Technical Developer Community meetings (0900 Pacific time on Thursdays, everyone welcome) are well-attended, full of thoughtful debate and discussion, and the engagement there – as well as all the hard work in between the meetings – continues to move us forward with purpose.

Community News

In this newsletter, we announce our Community Heroes feature, which provides a profile of an invaluable member of the OpenAPI community. In this first feature, we interviewed Henry Andrews, a subject matter expert in OpenAPI and JSON Schema and a prolific contributor to the community. You can read more on our blog.

We can also bring you news of the imminent release of our first OpenAPI Initiative training course, OpenAPI Fundamentals. This course provides foundational knowledge of OpenAPI, with the history of the language and practical examples of creating and using an OpenAPI description. This free course is available on The Linux Foundation Training and Certification platform from June 11th 2024.

Events Round-up

The summer is fast approaching in the Northern Hemisphere and consequently, the conference schedule tends to take a hiatus. We have, however, been busy running our OAI track at various conferences since our last newsletter. The OAI track aims to bring together community leaders and practitioners to provide a focused and detailed series of talks on subjects across the spectrum of OpenAPI Initiative specifications. The tracks are orchestrated by Erik Wilde, who describes them as:


“The OAI Track brings the API community together around OpenAPI and standardization in general. We typically have presentations about core specification topics, we talk about practices and tooling, and we also have contributions where presenters share how OpenAPI and standardization helped them on their API journey. Join us at any OAI Track to get the latest news and high-quality presentations about OpenAPI and other OAI activities!”


The OAI track was hosted at three apidays conferences in April and May, in Singapore, New York, and Helsinki, as well as at the JAX Conference in Mainz, Germany, in April. We heard from great speakers, including Frank Kilcommins who covered the finer points of Arazzo (including unveiling the name at apidays Helsinki). Darrel Miller looked at consuming APIs for “SDK Haters” in New York, while Sohaib Tariq discussed lessons learned from one million API definitions in Singapore.


We will be running the OAI track at conferences in the future, including the apidays Paris conference, where we plan to provide extensive training sessions on OpenAPI. We will launch an official “OAI certification program” in the second half of the year, at both the on-site training sessions at the apidays Paris conference and online courses. Stay tuned for details and please check out the OAI event calendar for a full list of upcoming events.


We also want to hear from you! Please get in touch on the Outreach channel on Slack with news of upcoming events, meet-ups, or anything you want to share with the OpenAPI community. We’d also love to hear about your experiences of using OpenAPI in designing and implementing your APIs, and share those experiences with the community on our blog.

Finally…

That’s it for this newsletter. If you have news you want to share with the OpenAPI community please get in touch by email or join the Outreach channel on Slack. We also welcome suggestions on how we can improve this newsletter or bring you information that can help make the most of how you use specifications published by the OpenAPI Initiative.

Meeting Orchestration Needs with Arazzo

By Announcement, Blog

Today we are delighted to announce the release of Arazzo, a new OpenAPI Initiative specification designed to describe sequences of API calls to meet the orchestration needs of API providers and consumers.

In a digital economy increasingly powered by APIs there is a need to accurately reflect the increasing complexity of the integration required to do business. Organizations calling multiple APIs to execute business flows and functions, sometimes across multiple service providers, require guidance and support to correctly implement sequences of API calls, with cognizance of success and failure at each step.

The Workflows Special Interest Group (SIG), part of the OpenAPI Initiative umbrella of specifications, has created the first release of the Arazzo Specification to meet the increasingly complex integration needs. Arazzo will allow API and integration service providers to build on top of OpenAPI Specification, providing information on sequences of API calls that comprise a flow or function.

Using Arazzo API providers can:

  • Link multiple operations, described through OpenAPI or other Arazzo descriptions, into one sequence of activities.
  • Provide criteria that describe success or failure based on the responses received from the APIs that API consumers call.
  • Implement variables that can carry dynamic variables from one API call to another, ensuring that data is successfully carried, as needed, through the context of the described sequence.

Like the OpenAPI Specification, the goal is to create a rich description language that can be used both for documentation and to automatically create integration code from machine-readable sources.

Frank Kilcommins, Principal API Evangelist at SmartBear and member of the Workflow SIG team, describes Arazzo as:

“An important milestone on the path to improved API maturity across the industry. By providing deterministic recipes for value-based usage of APIs, the Arazzo Specification, through its human- and machine-readable attributes, acts as living API documentation, reducing dependence on out-of-band onboarding guides. It ensures assertable qualities for API providers and regulatory stakeholders across the API lifecycle, while also empowering tooling vendors to craft the next wave of SDKs and code generators.

The Arazzo Specification enables human API consumers to better understand how to use and combine APIs, focusing on their jobs to be done, thus reducing their mean time to integration. Concurrently, it offers a consistent and interoperable mechanism for the new wave of AI consumers to achieve expected API outcomes first and every time.”

Arazzo will evolve as more organizations and tooling makers implement the specification. Please visit the specification page and repository, or join our Slack channel for more information.

OpenAPI Moonwalk 2024

By Announcement, Blog, News

An astronaut plants a flag with an OpenAPI logo on the moon.What comes next for the OpenAPI Specification? How will v4 improve on the success of OpenAPI v3? What can the spec help solve problems in the context of AI and LLMs?

As 2023 comes to a close, answers to these questions are beginning to take shape. With an aggressive goal of launching v4 “Moonwalk” by the end of 2024, it is going to be an exciting year.

Because there is so much work to be done, it was necessary to establish some guiding principles. After reviewing the major proposals and discussions of the last year, these are semantics, signatures, inclusion, organization, upgrading, and their order is important:

    1. 🌖 Semantics provide purpose. It is not sufficient to describe the mechanics of an API without also describing its semantics, whether the consumer is a human or an AI. Semantics join the what (… does this do?) and the why (… does this matter?) to the how (… does this work?).

      OpenAPI has helped people build better APIs faster, and the ecosystem of tooling continues to deliver more value year after year. What is new today in 2023 is the rise of a new kind of API consumer—generative AI. LLMs can process OpenAPI descriptions and then use that API to solve problems. With generative AI’s ability to understand natural language, OpenAPI can help bring the power of APIs to non-developers with a level of accessibility never seen before. To fully realize this potential, API producers should decorate their mechanical descriptions of HTTP requests with details that convey the meaning and purpose of those API operations. This, in turn, helps both people and LLMs to achieve better results.

      To say this another way, people have been using squishy, natural language to talk to each other for centuries, and we’ve used crunchy, programming languages to talk to machines for decades. LLMs bridge the squishy and the crunchy worlds, which means that a huge number of people can use APIs who could not before.

      Regardless of your opinion of generative AI, from over-hyped to world-changing, we can expect that many people will be using OpenAPI to drive AI-based API consumers. If OpenAPI does not step up to address the needs of that community, they will find alternatives.

    2. 🌒 Signature please! An API represents a set of functions, each of which describes a client-oriented purpose. A function is identifiable by its signature, which correlates to a set of HTTP interactions. Moonwalk places this concept at its center.

      Any HTTP API is always a means to some end. API consumers prefer to reuse existing functionality, and ideally they can learn about that functionality in terms that are most natural to them. That a PUT/PATCH/DELETE returns a 200 or a 204 is an implementation detail that pales in comparison to the function it performs for the client. Today there are limited ways to express the signature of an API function in OpenAPI. A pathItem can’t use query parameters to distinguish operations. There can only be one operation per HTTP method. These are artificial constraints on the signature of the API functions due to the lack of a formal definition of the unique signature. Past efforts in OpenAPI have focused on enabling developers to describe HTTP APIs. This reprioritizes them so that developers can use OpenAPI to define API functions with unique signatures that then map each signature to HTTP mechanics.

    1. 🌕 Inclusion needs a big tent: Moonwalk aspires to describe all HTTP-based APIs. While it remains neutral on the design aspects of HTTP APIs, it recognizes the importance of having different design styles and opinions.

      Moonwalk should be able to describe the HTTP APIs that developers may already have as well as to design the APIs they may want to build. It should be able to accurately map the signature of an API function to an actual instance of an HTTP request and response provided by the API. Moonwalk does prefer resource-oriented API styles due to their overwhelming popularity, but it should be possible to describe purely RPC APIs, even when those API signatures are distinguished via HTTP header values or request body values.

    1. 🌗 Organization through separation of concerns. For example, the changing shape of an API should move independently of API deployments. API deployments may be secured with different security schemes. API functions’ signatures should not be tightly coupled to content schema formats.

      To support the growing customer base with diverse needs, the feature count will undoubtedly grow, introducing more complexity. To counterbalance this, we will apply more rigor to the modularization of different aspects of the API description. We will strive to eliminate ambiguity where it currently exists and leverage existing standards to minimize unnecessary novelty. Our goal is to provide a better experience for API description consumers, authors and tooling providers.

    1. 🌑 Mechanical upgrading. An important principle of OpenAPI v3 was that it offered a direct upgrade path from v2. Moonwalk carries this forward, which means that it must again be possible to mechanically upgrade to Moonwalk from v3 (and by extension, v2).

Important open source projects like OpenAPI depend on contributions from many people. If you are as excited as we are about the ideas above or about the opportunity to leverage AI to help APIs be used by more people, then please get involved! A great way to start is to join our weekly calls on Thursdays (details), and anyone who wants to join is welcome!

 

Apidays Paris 2023 – with an OpenAPI Track – is Coming This December!

By Announcement, Blog, Events

The OpenAPI Specification is an integral part of software development and delivery of APIs. In 2023, we have been joining multiple API related conferences to connect directly with API users and enthusiasts around the world. Next up, the City of Light! Join us for the OpenAPI Initiative’s “OAI Track” at apidays Paris on December 6-7, 2023!

See our apidays Paris events page here.

What is the OAI Track?

The OAI Track is a specialized forum at apidays Paris hosted by the OpenAPI Initiative (OAI). This focused track aims to provide a platform for API practitioners to share and exchange valuable insights, experiences, and best practices related to OpenAPI. At Paris, we will have 3 different sessions with a total of 12 speakers! 

OAI Track Program Sessions

  • Current and Future Trends in API Specifications
  • Improving APIs and API Landscapes with API Descriptions
  • API Governance and Management with API Descriptions

Call for Contributions

The OAI Track is currently inviting contributions from interested individuals and organizations. If you have an experience or insight to share, we would be thrilled to include your voice in the discourse.

👉 Submit Your Proposal Here: https://apidays.typeform.com/to/ILJeAaV8?typeform-source=www.apidays.global#event_name=xxxxx 

👉 Register here: https://ticket.apidays.global/event/apidays-paris-2023/8a1f3904-e2be-4c69-a880-37d2ddf1027d/cart   

Why Should You Participate? 

  • Knowledge Sharing: Learn from industry experts and peers actively involved in API management and OpenAPI specifications.
  • Networking: Connect with a passionate community of API developers, architects, and business stakeholders.
  • Visibility: An opportunity to present your work and insights to a highly specialized and relevant audience.

Join Us, Join the Conversation!

Whether you’re an adept API craftsperson or an enterprise visionary keen on tapping into API magic, the OAI Track provides a fantastic platform to immerse and interact with the best of the API world.

Date: December 6-8, 2023

Venue: CNIT la Défense, Paris, France

Don’t miss out on this unique opportunity. Mark your calendars, and prepare to dive deep into the world of OpenAPI.

We hope to see you there!


For further updates and announcements, watch our apidays Paris page.

Join Us at apidays Australia 2023 for a Full-Day OAI Track

By Blog, Events

The OpenAPI Specification is an integral part of development and delivery of APIs. In 2023, we are joining multiple API related conferences to connect directly with API users and enthusiasts around the world. Join us for the OpenAPI Initiative’s “OAI Track” at apidays Australia in Melbourne on October 11th and 12th, 2023!

What is the OAI Track?

The OAI Track is a specialized forum hosted by the OpenAPI Initiative (OAI) as part of the larger apidays Australia conference. This focused track aims to provide a platform for API practitioners to share and exchange valuable insights, experiences, and best practices related to OpenAPI.

Key Focus Areas

  • User Stories: How are you or your organization using OpenAPI?
  • Tooling: Showcase tools you use or develop to enhance OpenAPI utilization.
  • Specification Extensions: Share any augmentations or adaptations you’ve made to the OpenAPI Specification that could benefit the wider API community.

Call for Contributions

The OAI Track is currently inviting contributions from interested individuals and organizations. If you have an experience or insight to share, we would be thrilled to include your voice in the discourse.

👉 Submit Your Proposal Here: https://apidays.typeform.com/to/ILJeAaV8?typeform-source=www.apidays.global#event_name=xxxxx

Why Should You Participate?

  • Knowledge Sharing: Learn from industry experts and peers actively involved in API management and OpenAPI specifications.
  • Networking: Connect with a passionate community of API developers, architects, and business stakeholders.
  • Visibility: An opportunity to present your work and insights to a highly specialized and relevant audience.

Get Inspired: Hear from apidays Founder

Still wondering if the OAI Track is the right place for you? Listen to Mehdi Medjaoui, the founder of apidays, discuss the essence and vision of the OAI Tracks at apidays events with Erik Wilde.

Join the Community!

apidays Australia is not just another tech event; it’s a rich learning ground and a launchpad for ideas to advance the API ecosystem. Whether you’re a seasoned API developer or a business leader looking to harness the power of APIs, the OAI Track offers an unparalleled opportunity to engage with the API community.

Save the Dates: October 11th and 12th, 2023

Location: Pullman Melbourne Albert Park, Melbourne, Australia

You can register here: https://ticket.apidays.global/event/apidays-australia-2023/f2d35972-9e81-401d-a29a-285fa1d00974/cart 

Don’t miss out on this unique opportunity. Submit your proposals here​​, mark your calendars, and prepare to dive deep into the world of OpenAPI.

We hope to see you there!
For further updates and announcements, watch our apidays Australia page.

Case Study: Using the OpenAPI Specification for Integrating SaaS Applications and Scaling Up to Hundreds of API Providers

By Blog

Guest blog post by Donald Atha, Software Architect, BetterCloud

One of the biggest challenges facing IT teams today is the increase in tedious and repetitive tasks driven by the explosive growth in SaaS applications over the last 10 years. Companies are using more and more SaaS products, which presents challenges when it comes to managing employee onboarding and offboarding, managing licenses and permissions, and resolving help desk tickets. At BetterCloud, we give IT teams the tools to reduce the amount of manual work on their plate with automations and configurable workflows. As the number of SaaS applications grows, our customers rely on our library of SaaS integrations to also grow.

Testing OpenAPI Generators for Rapid Integration

Recently the Innovation Team within BetterCloud, a team tasked with discovering and testing new capabilities that accelerate innovations, took on the challenge of prototyping a solution that would allow us to more rapidly integrate with various SaaS applications and scale that solution to onboard hundreds of API providers. The team agreed early on in order to reach the ambitions of the business, we would need to automate much of the process. The team also agreed that this would be possible because much of adding a new integration is the same and that the OpenAPI Specification would allow us to automate pieces of this by using existing community generators. 

To fully understand the problem, it helps to understand what it means to add an integration at Bettercloud and a bit about our product. BetterCloud’s workflow engine automates processes like employee onboarding by detecting when a new employee is hired and subsequently granting access to the various SaaS applications required for their role. This onboarding scenario is just one of many use cases we support. All these use cases invariably necessitate ingesting and storing data from the 3rd party provider and updating the provider’s state. For instance, in the onboarding use case, the ingestion process fetches employee data, detects a change in status, and triggers the onboarding workflow. This workflow calls the provider’s APIs to create accounts or grant access to shared resources for the employee—functionality we internally refer to as “actions.”

When embarking on adding a new integration, BetterCloud begins by validating that the provider has the necessary APIs to support our use cases. This crucial step sets the stage for efficiently accessing required data and assessing whether the provider’s APIs are compatible with our action use cases. The OpenAPI Specification provides a consolidated view of this information.

Reducing the Amount of Code Written by Using the OpenAPI Specification

Once the API is understood, the next phase is implementing the ingestion logic. This phase involves calling the provider’s APIs to fetch and store all necessary data within BetterCloud’s infrastructure. The team has explored two methods to coordinate this, both leveraging the OpenAPI Specification. The intent with both approaches is to reduce the amount of code that a developer must write when adding a new integration. The first involves code-generating an HTTP client in Java using the OpenAPI Java code generator, while the other approach uses extensions to markup the spec, enabling the configuration of the ingestion logic. This marked-up spec feeds into a general-purpose engine that implements the logic based on the extensions. This covers the ingestion of data from the APIs, but once acquired, it must be stored to serve our applications. 

BetterCloud utilizes a SQL database to store the entities we ingest. To create the schemas, the team employs the OpenAPI MySQL generator, Flyway, and Terraform. These tools facilitate the creation and configuration of a database for the new provider. The team was able to slightly modify the existing mustache templates of the MySQL generator in order to add our internal fields such as customer id. Since both the ingestion data models and the MySQL data schemas derive from the OpenAPI Specification’s entities, automation of this process becomes straightforward as the data models are aligned. With just an OpenAPI definition, we can generate a new database and its schemas at the click of a button in all of our environments!

Conclusion – Better Scaling the OpenAPI Specification, Better Value

We anticipate that this approach will allow us to bootstrap the ingestion portion of adding a new integration. By automating and code-genning common elements, the team can concentrate on the unique aspects of each new integration. Much like how we at BetterCloud automate workflows for IT teams to allow them to scale the impact of their work, the OpenAPI Specification has given us the tools to build our own automations that scale the value we can provide to our customers.

WireMock, Venture Funded Open Source API Mock Platform, Joins OpenAPI Initiative as New Member

By Announcement, Blog

The OpenAPI Initiative, the consortium of forward-looking industry experts focused on creating, evolving, and promoting the OpenAPI Specification (OAS), is announcing today that WireMock has joined as a new member. Welcome WireMock!

WireMock was created in 2011 and has been a popular open source tool for API mocking. Last year, project founders Tom Akehurst and Uri Maoz launched a company with the same name. They created a managed cloud service called WireMock Cloud, and in May 2023 announced a $6.5 million investment from Ridge Ventures, with participation from First Rays Venture Partners, Scribble Ventures and several unnamed investors.

Building a stable and predictable environment when creating APIs is crucial to the efficiency and success of developers. WireMock is a flexible and free open source platform that can be run as a standalone server, or in a hosted version via the WireMock Cloud managed service.

“We are thrilled to welcome WireMock as a member of the OpenAPI Initiative! Mocking APIs plays a crucial role in reducing development time and increasing productivity for developers. The open source community relies heavily on mocking tools in order to speed up development, better test for edge cases, and much more,” said Isabelle Mauny, OpenAPI Business Governing Board Chair. “It’s important for tools makers to implement the OpenAPI Specification and mocking APIs is one of the great benefits of using the OpenAPI Specification for your APIs.”

“OpenAPI is the key standard around which a rich ecosystem of tools and infrastructure is rapidly evolving. We believe that first-class OpenAPI support in WireMock will unlock a huge amount of productivity for both API developers and consumers,” said Tom Akerhust, the WireMock creator and the CTO of WireMock Inc.

“API-first development is at the core of both the WireMock open source project and WireMock Cloud, our developer productivity platform. Support for OpenAPI is central to our mission of enabling developers to simulate APIs across the entire application lifecycle”, said Oleg Nenashev, Community Builder and CNCF/CDF Ambassador, WireMock, “We believe that our vision and products are closely aligned with the OpenAPI Initiative. We’re pleased to join OAI as a member and work on expanding the OpenAPI ecosystem together”

Learn more in WireMock’s announcement blog post.

OpenAPI Resources

Want to become a member of the OpenAPI Initiative? Find more information here: https://www.openapis.org/membership/join 

To learn more about participating in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

About WireMock

WireMock is a popular open-source tool for API simulations (aka API mocking). It is used for integration testing of applications, especially via REST API. Started in 2011 as a Java library by Tom Akehurst, it now spans multiple programming languages and technology stacks. WireMock helps to create stable test and development environments, isolate code from flakey 3rd parties and simulate APIs that aren’t currently available. It can run as a test library, as a standalone server or via the WireMock Cloud service. With more than 300 contributors, 50+ integrations and 5+ million downloads a month, it is one of the most popular open source projects in its domain.

About WireMock, Inc. 

WireMock Inc. is building software to unlock developer productivity by enabling collaborative API design, mocking APIs and eliminating slowdowns caused by external dependencies. The company was started in 2022 by Tom Akehurst and Uri Maoz becoming its CEO and CTO. WireMock Cloud, the company’s flagship product, is built on top of the WireMock open source project stewarded by the company.

Recent WireMock News: What Our $6.5M Seed Round Means for WireMock and the WireMock Community

WebAssembly and Career Networking at Gluecon

By Blog

Guest Author: Tony Blank

Tony is an experienced software developer with an interest in web design, web marketing, customer integration, and software IT including networking, data center management, and sysadmin. He has attended many of the GlueCon events in the past years because of its highly curated content and focus on cutting-edge technology transforming the web, including API Standards. GlueCon was sponsored by the OpenAPI Initiative.

“Gluecon 2023 was an incredibly enjoyable conference. I extend my thanks to the OpenAPI Initiative for providing me with a complimentary ticket. If anyone is considering attending a future Gluecon and has any questions, please feel free to reach out.”

Email: me@tonyblank.com

Twitter: @thetonyblank

I can’t believe it’s been ten years since I first started attending GlueCon. This event has always been on my “must-attend conference list” because of its highly curated content, focusing on cutting-edge technology that is poised to transform the web. Throughout the years, I’ve had the opportunity to represent a few different companies at Gluecon leading community teams. However, this year is different. I was unfortunately laid off in March, and now I find myself in search of my next exciting challenge.

A conference like Gluecon is the perfect place for me to network and connect with innovative companies.

Back in 2013, when I first attended Gluecon, the conference was abuzz with discussions about web services and API standards. As a developer evangelist for Context.io, an email data API, I found Gluecon to be the ideal gathering to meet fellow developers and individuals keen on exploring new APIs.

This year, the main topic of conversation was WebAssembly.

For those unfamiliar with WebAssembly, it is a binary instruction format specifically designed for the web. Its purpose is to enable high-performance code execution within web browsers. These low-level languages execute on the web with near-native performance, revolutionizing the way applications are built.

It reminds me a little of when Docker was first released and it was apparent to everyone how useful containers are. In fact, Solomon Hykes, the co-founder of Docker, famously tweeted that if WASM had existed in 2008, Docker would never have been necessary (https://twitter.com/solomonstre/status/1111004913222324225).

The second time Solomon presented Docker publicly was 10 years ago at Gluecon, along with Jeff Lindsey. Jeff referred to Solomon’s quote during his talk at Gluecon titled “Futuristic Architectures: Session Backends and WebAssembly Components.” In his talk, Jeff brilliantly illustrated how standard WASM components will lead to innovative app architectures. It was a delight to catch up with Jeff, as the last time we crossed paths was in Paris at the dotScale conference back in 2014. He was showing dotScale Dokku, which began… as Jeff’s Docker demo for his Gluecon talk the previous year.

Another remarkable session was the fireside chat between Alex Williams, from The New Stack, and Matt Butcher, founder and CEO of Fermyon. Alex has been covering the most intriguing emerging technologies since his days at Programmable Web (RIP), and his conversation with Matt was no exception. Hearing about how the benefits of WASM, like cross-language compatibility and fast execution times, are being implemented by Fermyon in their new cloud offering was very exciting.

Not every talk at Gluecon was about WebAssembly. Any developer would have enjoyed Jason Harmon’s talk focused on internal API best practices. Treating APIs like products vs. a feature of a product leads to good developer experience, faster production cycles, and fewer headaches. Jason is currently the CTO of Stoplight.io, who went through the Techstars Cloud accelerator in 2015. Editor’s note: Jason was also a key figure in the early days of the OpenAPI Initiative!

It was fun bumping into Samy Fodil, who I met when his startup Sage Hero was in Techstars Cloud in 2016. Samy was at Gluecon this year talking about his current startup Taubyte and, yep, WebAssembly!

Gluecon always closes with some amazing keynotes. Unfortunately, I had to miss this year to get set up for Mile High Startups & Music, the monthly tech event I promote featuring Denver’s best local musicians. (Big shout out to Elastic for supporting both Gluecon and Mile High Startups & Music!)

I hope to see you there next year!