[FEATURE REQUEST] Support flatbuffers schema files

[mpe85]

It would be nice to be able to document flatbuffers payload using AsyncApi. I think this shouldn't be a big deal, because protobuf (which is similar to flatbuffers) support is already announced for 2.0. Have you already thought about this?

[fmvilas]

I heard about flatbuffers once but didn't pay so much attention because nobody ever told me they were using it. I do see the value of having support but we're a small team and already have a lot to do in front of us. You're right, using it on version 2.0.0 would be possible because we don't restrict payloads to any language. However, there needs to be tooling supporting it. The only piece I see missing is a flatbuffers->jsonschema converter. Would you like to participate in the development of the flatbuffers support?

[mpe85]

There is the possibility to convert a flatbuffers fbl fbs file to a JSON schema file by specifying the option --jsonschema when running the flatbuffers compiler (flatc). See here https://github.com/google/flatbuffers/pull/4369 Maybe this could be used somehow by AsyncApi?

[fmvilas]

Yeah, I see this is possible using the CLI, but we'd need to have it as a separate library for the parser to understand it. I see it's C++ and we're currently writing the parser in Go. It shouldn't be very different though. We can do it ourselves but again, it would be much appreciated if you could help to contributing to this effort. Even if it's just created such library so we can afterward create the schema parser.

[mpe85]

Are there any guidelines or specifications about how such a library should look like?

[fmvilas]

Not really. I was talking about a generic library that's capable of transforming flatbuffers to jsonschema. Something totally unrelated to AsyncAPI but that AsyncAPI would use. You can take as an example existing libraries to translate from protobuf to jsonschema, for example.

[mpe85]

I guess a Java library would be of no use for you?

Since I'm very deep in the Java world, I am probably able to implement it in Java very quickly. My C/C++ skills got very rusty over the years (about 10 years ago I used it the last time), and concerning Go I have no experience at all.

[fmvilas]

I hear ya! Neither we have experience in Go but we chose it because it's good compiling to C libraries, performant, and its ever-growing community. So, in short, yes, it has to be written in Go.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[zamazan4ik]

@fmvilas sorry for necroposting but my question is the same: Does AsyncAPI now support Flatbuffers? We are investigating the possibility to describe our event-based API with AsyncAPI, and our underlying format will be Flatbuffers.

[jonaslagoni]

@zamazan4ik you might want to take a look at https://github.com/asyncapi/spec/issues/622. I think that will enable your use-case. For all schemas, protobuf, Flatbuffers, whatever you need.

[zamazan4ik]

Thanks! It seems like exactly what I need. I just suggest don't close this issue until the proposal will not be merged. I think it will be more convenient for other people with the same question.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[smoya]

@zamazan4ik we do have now support for protobuf but not for flatbuffers. I see this issue has not have any activity since time ago, so I'm gonna close it as won't do for now.

Please open a new request or RFC if you believe support for flatbuffers should happen. Thanks.