The whole validation/parsing process in our parser consists of 3 steps:

• validation via AJV based on spec JSON Schema
• custom validation(s) which cannot be done with AJV because we have to compare values between different parts of the specification, e.g. security in servers and corresponding values in components/securityRequirements. Here we also perform additional actions like applying traits etc
• creating from validated AsyncAPI spec the models - the instance of the AsyncApiDocument class

The above operations are not complicated and are sufficient for now (however, we do not validate all edge cases from point 2, such as lack of payload's/header's example validation etc.). However, we are missing one thing that every good linter/parser/validator has, support for custom rules. I am thinking about using spectral in our parser to add such functionality. The advantage of this solution would be the complete elimination of the first two steps, because it would be done by the spectral itself and only our parser would be a wrapper for it. At the end we still need to models/intent API.

But to go in this direction we should first test spectral and see if we can support all the cases we have in AsyncAPI like:

• validating extensions based on their schema
• validating bindings based on version and schema
• validating and parsing custom schema formats like Avro, Raml etc.
• validating custom ref behaviour if we decide to change current $ref logic.

Currently spectral has in source code support for AsyncAPI with some additional rules. You can check it here https://github.com/stoplightio/spectral/blob/develop/packages/rulesets/src/asyncapi/index.ts Here comes the problem because in order to have control over these rules we should ask the spectral people if we can extract these rules from their source code and move them to our organization under @asyncapi/spectral package.

Then, with every spec release we could add a new rules, without waiting for an update from stoplight. Additionally, such a package would have two advantages:

• people using spectral alone would have the ability to validate AsyncAPI with the spectral CLI (only have to fetch that new rules)
• we as an AsyncAPI organization would have the ability to use those rules in our parser during validation + support in our CLI/ServerAPI/Studio.

I'm not a fan of reinventing the wheel (unless there is a lack of functionality on the market or no feedback from the package maintainers) but we should try to reuse spectral in our parser instead of validating in our own way. Of course if Spectral will not meet our requirements then we should think about our own linter, but lets see.

What do you think about it?

cc @smoya @jonaslagoni @fmvilas @derberg