In 2016 Stoplight released the industry’s first form-based OpenAPI designer, and since then we have helped developers, architects, and even product managers design tens of thousands of APIs. Over the last few years, we focused on adding features to take advantage of these OpenAPI documents, such as hosted API documentation and automatic mock servers. However, as we engaged with our customers, we realized that a new set of problems was cropping up as the number of APIs under management grew.
Creating a process to design and develop a handful of APIs at your company is difficult but doable. On the other hand, creating a process to design and develop tens, hundreds, or thousands of APIs at your company, spread across dozens of teams, is a Herculean task. In conversation after conversation, we learned that this is the situation many of our customers find themselves in as development patterns shift toward building and deploying smaller, more specific APIs (microservices).
Managing APIs at this scale introduces a number of new challenges - consistency, governance/compliance, discoverability, and quality become difficult to manage as the number of APIs increases. When we look around at the options for solving these problems, we see a lot of solutions that ask companies and developers to add a completely new workflow to their process. This is a big ask, and one that can stifle attempts at rolling out a more modern API design first program at your company.
What we realized is that most of these problems can be solved in the context of the workflows and tooling that already exist at your company. Your Git repositories are the obvious place to store API design assets. The process you have today to drive code reviews is a great foundation to drive design reviews. The automation you have in place to run test suites is a perfect spot to add API style guide/consistency checks. And so on.
By enriching the tools and workflows that exist at your company today, Stoplight becomes easier to roll out across your entire company, bringing the goal of affecting meaningful improvements to your API development processes one step closer.
A primary goal with the Stoplight Platform was to make it as easy as possible to integrate Stoplight into your existing workflows. Stoplight should enrich - not replace - these workflows, thus reducing the friction involved with rolling out a modern API development strategy at your company.
To that end, the Stoplight Platform was built to act as a layer on top of the version control system(s) at your company - GitHub, GitLab, Bitbucket, etc.
This shift yields a number of benefits right off the bat:
Today we unveiled our vision for the Stoplight product ecosystem - one in which you own your data, and you choose how and when to incrementally layer Stoplight into your existing workflows. Over the next few months we’ll work with customers on our legacy products to help you through the migration process. Please note that you do not have to migrate until you are ready - we are not sunsetting our legacy products at this time, and will provide at least 6 months notice before we do so.
You can explore what we’re working on, and make suggestions, on our public roadmap - we look forward to working together.