-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: first support of bindings for AVRO key #77
feat: first support of bindings for AVRO key #77
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
dcfcc72
to
721731f
Compare
721731f
to
6cf8ca3
Compare
index.js
Outdated
@@ -7,6 +7,19 @@ module.exports.parse = async ({ message, defaultSchemaFormat }) => { | |||
message['x-parser-original-payload'] = message.payload; | |||
message.payload = transformed; | |||
delete message.schemaFormat; | |||
|
|||
async function handleProtocolKey() { | |||
for (const protocol of Object.keys(message.bindings)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can go straight to Kafka protocol instead of iterating. I don't know any other protocol that has a key
property that can be defined with Avro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if fact this was my first approach but i guess maybe new EDI technologies in future can handle message key like nats.io
... but ok i will change this implementation to only support the kafka protocol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done @fmvilas
Maybe as a temporary solution to this problem it is ok, but in the long term it is not a good solution. We can now hardcode with that, but what if someone defines a key in kafka with EDIT: Related issue with proposal asyncapi/spec#622 |
Yes i agree with you. i assume that the |
Looks good to me so far. I think we should update the Kafka binding before we proceed to merge this one: https://github.com/asyncapi/bindings/tree/master/kafka. |
By indicating that the key can also handle an Avro reference file in addition to a Schema Object ? |
Yes, that's what I was thinking. As the binding is right now, this library would not be compliant but since I think it's a great thing to have for Kafka devs, maybe it's just a matter of updating the Kafka binding definition. |
Here is the related PR @fmvilas asyncapi/bindings#81 |
Guys (@fmvilas / @magicmatatjahu ) , what about this PR status linked to the merge asyncapi/bindings#81 ? Could you merge it ? |
@fmvilas You requested changes one time :) Please look again. |
@M3lkior there are some linter errors. Otherwise, it looks good to me. |
oups sorry, it is fixed ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
@magicmatatjahu can you review and approve/reject? |
Co-authored-by: Maciej Urbańczyk <[email protected]>
07716bf
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
🎉 This PR is included in version 0.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
see the #67 for the details ;
this implementation only support
bindings.[protocol].key
but if you have any feedback for a better support of general bindings for any property ; i'm listeningHere is the result with the support of bindings for my kafka key definition that was previously not correctly displayed in the html generation (test with the last version of the generator)