It’s also compatible with existing Spectral rulesets and generates compatible Spectral reports.
vacuum will tell you what is wrong with your spec, why, where and how to fix it. It will work at scale and is designed as a CLI (with a UI) and a library to be consumed in other applications.
Why does it exist?
When I worked at VMware, We needed a quality linter to start understanding just how well the API landscape held up across the company.
There were thousands of different OpenAPI specs, across a large number of business units. It was my job to try and make sense of it all.
Spectral was the only credible linter available at the time to build on top of, Which is great, because spectral does a good job, except for one thing…
We need a faster linter
We needed something compiled and fast, even Java would have been too slow.
I was talking to my colleague Steve Trefethen about this major pain point with our engineering capability one day, particularly how slow Spectral was when trying to operate it as a service.
“What we really need is a drop in replacement for Spectral”
“I am going to build it.”
So I did.
World’s fastest OpenAPI linter.
It’s faster because it’s written in golang, it’s multi-threaded and uses an index for complex rules.
It’s also been designed as a golang library from the ground up.
What makes vacuum different?
It’s been designed with enterprise & large scale use, as well as having a console UI, a rad, interactive HTML report as well as a ‘vacuum sealed report’ that allows re-rendering of any report in time, without losing any fidelity or re-running new logic that could change results.
About these docs
These documents are hand-crafted. They are not auto-generated, they have been deliberately written to be easy to understand, easy to read and easy to navigate. SEO, performance and a11y have been critical factors in the design and architecture of how these documents are structured and delivered.
All of quobix.com is powered by hugo. hugo is just about perfect for this type of content delivery, I fell in love with hugo about a year ago. There isn’t a webapp on planet earth that you cannot build with hugo. It’s an old-school design, with a nu-school stack.
I’ve been building apps for quarter of a century (at the time of writing - July 2022) and during that time I have designed multiple commercial content management systems (CMS) in the past. I wish hugo existed then, I would never have wasted my time.
I asked myself these questions:
Should I use React? I need ultra speed and power - will it deliver?
React uses something called Virtual DOM. the TL;DR version is that a ‘copy’ of the actual DOM is kept in memory. The memory version of the DOM is the source of truth, that’s the model that is mutated. React then ‘prints’ the state to the actual DOM, using magic.
Which led to the conclusion:
No, Magic is slow.
The answer was easy. It’s No framework, use native browser APIs. Use WebComponents
Wait, what about all the boilerplate?
Yeah, this is an issue at scale, lots of copy pasta, lots of mess. There are some options but, they suck and look abandoned.
This is where Lit comes into the picture. It provides some Mixins for WebComponent development that builds out the boilerplate at compile time. Lit is not, and does not provide a run-time, it simply builds out the same boilerplate code you would need to anyway.
You may still be thinking..
Cool story bro, but, mmm… nah, I will stick with React.
I would ask you a question:
“Do you like slow service?”
Followed by another question:
“Do you think your customers like slow service from you?”
If you answer ‘no’, Then check out Lit.