AsyncAPI Blog

The r1 is not just not-their-first, it's a pivot that reuses code from their earlier endeavours. (which itself is fine, like, that's what you'd expect from a pivot, it's just that their PR strategy relies on claiming those past projects are wholly unrelated.)

When they rug-pulled GAMA (after selling a bunch of NFTs), as consolation prize they "open sourced"[0] a few things.

One of their many promises was that their space-station "metaverse" would have "Quantum Engine AI Integration" (letting you talk to NPCs, among other things). They released a lightly edited Unreal Engine game template (the "metaverse"), along side a file named `api.yml`[1] which documents an AsyncAPI[2] API (the "AI integration"). There is no actual integration, the API spec is just positioned adjacent to the Unreal project - there's a note in the README that amounts to "integrate it yourself".

The back-end component was never open-sourced, and they've long since shut down the API server, but based on the docs, the API used by the r1 is clearly a direct evolution of that design.

As for the R1's API, there is no documentation, but I partially reverse-engineered it and wrote some docs of my own[3], which is enough to see the similarities.

[0] https://github.com/gamaspacestation/

[1] https://github.com/gamaspacestation/gss_release/blob/main/api.yml

[2] https://www.asyncapi.com/

[3] https://gist.github.com/DavidBuchanan314/aafce6ba7fc49b19206bd2ad357e47fa

I'm in the process of migrating PrintNanny.ai's remote command/event system off Cloud IoT Core. I've been running on IoT Core for 1.5 years. Here's my breakdown of the costs...

- $236.99 in usage, approx 1% of project's total revenue

- ~20 hours to implement pub/sub applications running on a mix of Raspberry Pi & GCP VMs. Implementations were in Rust and Python. It would have taken much, much longer to stand up a managed MQTT broker and identity/key management that I felt comfortable using in my own home, let alone providing to customers.

- Hundreds of hours implementing and debugging glue between GCP's Pub/Sub product, websocket-based subscribers, and MQTT subscribers/publishers.

I don't regret my decision (wouldn't have shipped otherwise), but I'm looking forward to the next phase. Here's what I'm migrating towards:

- NATs message broker. NATS supports connections via MQTT and Websocket protocols, besides NATS own protocol.

- django-nats-nkeys for org, identity, and JWT management (not production-ready, don't use this until I've been eating my own dog food for a few months) [1]

- AsyncAPI schemas [2] for core message APIs, including schemas for 3rd-party printer software events (OctoPrint, Moonraker, Repetier, etc). This will underpin PrintNanny's plugin system.

[1] https://github.com/bitsy-ai/django-nats-nkeys

[2] https://www.asyncapi.com/

I'm taking a closer look today, and it looks to me like one AsyncAPI document, which can be defined using multiple files, defines one application. If you look at the "fixed fields" section under the root object, the second field is "id"[0]:

id Identifier Identifier of the application the AsyncAPI document is defining.

This format is fine, but the tool I'm looking for is something that will read the definitions of multiple AsyncAPI documents (multiple applications) and show how their inputs and outputs connect, so I can answer a question like, "When application X publishes message Y on channel Z, which applications consume that message?"

AsyncAPI gets me 90% there by defining the service spec and providing code to parse it. It's possible somebody has already written the rest; I'll have to see.

[0] https://www.asyncapi.com/docs/specifications/v2.0.0#fixed-fields

I don't quite get it. Why can't I just enforce schema validation in my pub/sub handlers?

I see the YAML example completed here: https://www.asyncapi.com/docs/getting-started/servers/

asyncapi: 2.0.0
info:
title: Hello world application
version: '0.1.0'
servers:
production:
url: broker.mycompany.com
protocol: amqp
description: This is "My Company" broker.
channels:
hello:
publish:
message:
payload:
type: string
pattern: '^hello .+$'

This looks like a thin wrapper around sending a message to a message queue. What's the gain?

Where do you define what to do as a subscriber?

I'll ding one more thing about Open API 3.

While it is an open spec, the spec maintainer, Swagger, definitely keeps its fingerprint on it for business reasons. Among other issues, their validation tools in particular require a sign-up. Postman also has an Open API 3 schema builder, but also requires a sign up. There is no technical reason for this, and you have to trust Swagger or Postman to be responsible with your API schema. I believe this front-and-center branding of the spec itself makes it not as appealing or dynamic as it otherwise would be

edit ApiBldr seems ok: https://apibldr.com/

edit 2 AsyncAPI seems interesting: https://www.asyncapi.com/