Feedback about websocket client code generation about generator HOT 11 CLOSED

Just a note that discriminator is defined by OpenAPI and not JSON Schema.

from generator.

Wow! Thanks for the great feedback @bali182! The resulting code is starting to look nice. Maybe a bit too bloated, but because the Slack API is also very big. Also, I love the work you did on defining the schema with TypeScript 👏

1. It would be beneficial to add the concept of operationId in OpenAPI 3.0 to Message Object.

Completely agree. This is gonna be solved in the next version: asyncapi/spec#77. Hopefully soon.

2. Make it possible to discriminate payloads (Message Object payloads). ... But in case this is not available, it can be very costly to validate the full schema just to determine what type of message it is.

In Websockets, how do you discriminate messages if it's not by looking at a field in the payload? AFAIK, you can't send headers in a message.

3. This might be just a problem with the slack schema, but according to the json schema spec, any part of the schema that doesn't have the "required": true field set, is not required, and can be ommited. In the slack schema all fields are optional.

Correct, this is just a problem with my Slack example.

from generator.

Cool, the operationId (or silmilar) was the my biggest issue! Thanks for the compliments on the typescript stuff, it has been in the works for the while, I was doing the same for OpenAPI...

As for message discrimination, this might be a stretch but hear me out :) If we would want to force the schema for the incoming messages into a type system it would be something like this right?

type IncomingMessage = HelloPayload | AccountsChangedPayload | BotChangedPayload ...

So in terms of json schema this could be expressed as

receiveMessageSchema:
  oneOf: // or anyOf not 100 sure about semantics
    - $ref: '#/components/messages/HelloPayload'
    - $ref: '#/components/messages/AccountsChangedPayload'
    - $ref: '#/components/messages/BotChangedPayload'

And if this is the case we could add an optional discriminator property which as far as found online is already part of json schema:

  discriminator:
    propertyName: type
    mapping:
      hello: '#/components/messages/HelloPayload'
      accounts_changed: '#/components/messages/AccountsChangedPayload'
      bot_changed: '#/components/messages/BotChangedPayload'

I also added an example on how I imagine usage of the generated stuff, not sure what you think: https://github.com/bali182/asyncapi-ws-to-ts/blob/master/slackApiWithWs.ts

But optimizing for the most common usecases could also work (that's what I did for the slack example) in case you think it's too specific.

from generator.

Just out of curiosity, are there any examples out there for the channeled (topiced if thats a word) forms of communication? What are the usecases that inspired having the asyncapi format? How do clients/servers look like? It seems like websocket is not the main targeted platform as I was thinking initially :)

from generator.

Yeah, forgot about the discriminator feature of jsonschema. Not sure how it works, to be honest. I'll have to read more about it.

Regarding examples, you can find an example with topics here: https://github.com/asyncapi/asyncapi/blob/master/test/docs/sample.yml.

There are a few examples in this directory: https://github.com/asyncapi/asyncapi/tree/master/test/docs.

This is an example of a Node.js server generator: https://github.com/asyncapi/node-codegen. @rmelian and @ibaca are working on Java generators here: https://github.com/asyncapi/asyncapi/issues/18.

And you're right, the main platforms were message brokers, initially RabbitMQ and Kafka. Websockets support came afterward, in version 1.2.0. We're working on creating documentation with reference architectures where people can see examples of the most common use cases.

from generator.

BTW, this is looking great! Very simple to read :)

from generator.

Great, thanks, I will check those tools too, to get a sense of what the features are other than events :)

from generator.

@MikeRalphson oops, my bad. It still seems like a useful concept for this usecase.

from generator.

@fmvilas Added a sample server/client with the slack schema just for fun :D https://github.com/bali182/asyncapi-ws-to-ts/blob/master/README.md#run-sample

from generator.

Nice! That looks great! 👏

from generator.

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

from generator.