Comments (11)
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 👏
- 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.
- 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.
- 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.
Related Issues (20)
- Improve arborist (npm installation) to have no hacks HOT 4
- Allow $$operation$$ file template HOT 2
- `noOverwriteGlobs` will not work in majority of cases in templates using react HOT 10
- Proposal for mentorship of potential maintainers of generator -> `Becoming a Maintainer of AsyncAPI Generator` HOT 22
- [BUG] Demo from homepage does not work HOT 9
- Need to add proper options to generate the template from private registory using CLI HOT 2
- Allowing Generator to pull the templates from the private GitHub Repository HOT 1
- [Docs Bug 🐞 report]: The `template-constant` link is broken at the generator docs HOT 6
- [Docs Bug 🐞 report]: The `AsyncAPI document` button is broken at the generator docs HOT 3
- [📑 Docs]: Improve documentation related to `File templates` feature HOT 8
- `conditionalFiles` feature is broken when template uses `server` special parameter HOT 1
- Incoming changes for generator HOT 3
- Support platform generator type templates to infrastructure as code HOT 4
- [BUG] Docker container html template is not compatible with generator HOT 3
- Figure out what development flow will be without cli.js HOT 4
- Add Post-installation script for Cli.js deprecation and migration
- Migration Guide to md & post-installation script to deprecate `cli.js` HOT 4
- create our own changeset bot HOT 1
- Provide a development.md or **Development Guide** in readme where you explain how to start project locally and do some basic manual tests and how to run existing tests in isolated docker env HOT 1
- Put all (most) templates into the generator together for better developers' experience HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from generator.