taxilang VS spec

Under the hood, the tags (and associated query language) are actually Taxi - an OSS meta-language and toolchain we build (and have shared previously).

Taxi is a relatively new entrant in the API space. It's goal is to let developers add simple, (but type-safe) tags into their APIs, so software can understand how different APIs relate to one another.

One of the gripes I have about OpenAPI is that it has a very low signal-to-noise ratio. It was bad in JSON, it's just as bad in YAML, with an added whitespace pedantry.

It's great to see a number of alternatives listed in this thread - there's much more active development in this space then I was aware of, and I hope that some of it gets upstreamed back into OpenAPI.

I'll shamelessly plug our tool in this space - Taxi (https://github.com/taxilang/taxilang), which has a dedicated DSL (not YAML) you can either use standalone, or embeddedd within OpenAPI.

I also happen to think that (for internal teams at least), generating clients on ${apiSpec} is a form of tight coupling, where producer and consumer become tied together. If you can avoid it, you should, as it allows producers and consumers to stay loosely coupled and evolve independetly without the gymnastics of avoiding breaking changes.

I've talked about this before, with proposed solutions.[0]

[0]https://orbitalhq.com/blog/2023-01-16-using-semantic-metadat...

AsyncAPI: Interested in how to define your WebSocket APIs? One of the most advanced realtime specifications is the AsyncAPI specification, which comes with various generators for code and documentation, as well as renderers for the specifications.

Our journey with FastStream started when we needed to integrate our machine learning models into a customer's Apache Kafka environment. To streamline this process, we created FastKafka using AIOKafka, AsyncAPI, and asyncio. It was our first step in making message queue management easier.

Automatic Docs: Stay ahead with automatic AsyncAPI documentation

FastStream supports in-memory testing, AsyncAPI schema generation and more... If you are interested, please support our project by giving a GH start and joining our discord server.

However, in order for the system to work effectively, there must be a common understanding between the components regarding events and their data structures. This is where AsyncAPI comes in; it helps define a contract that describes how the components communicate and behave effectively.

You can also take a look at https://www.asyncapi.com/ (a spec for asynchronous APIs). It's useful for this use case, that is, building a well structured websocket interface with pub/sub.

Sure! Next step I am working on AsyncAPI scheme generation by your application code. It's also includes a project generation from scheme, scheme web view (lika the Swagger for OpanAPI), etc. It will a much difficult than just another broker implementation...

Onboarding - Enable developers to quickly learn how to consume the exposed APIs. For example, offer OpenAPI or AsyncAPI documentation and provide a portal and sandbox.