[GRPC] Enhancement & Rework Directory

[mustiikhalil]

So I was planning on reworking the GRPC directory; which will happen in three steps, step one will be unrelated to the release of flatbuffers 2.0.

Step 1:

• [ ] Add examples for other supported languages + proper readme for each one of them including existing ones. And make sure that it works, since a lot of the supported GRPC code flatbuffers has is outdated.

Starting with these languages:

• [x] cpp #6338
• [x] go #6448
• [ ] java blocked
• [x] python #6456
• [x] swift #6439
• [x] TS #6441

Step 2:

• [ ] Where we move all the GRPC code into example projects. This would help us maintain the GRPC code, and allows users of the library to get to know how to use it faster than jumping between directories

\GRPC\
    \Examples\
      greeter.fbs
       \cpp\
       \swift\
       \ts_js\

Ready languages:

• [ ] cpp
• [x] go #6448
• [ ] java WIP
• [x] python #6456
• [x] swift #6479
• [x] TS #6476

---

• [x] Add Code generator for the GRPC code into the CI since that's something we are missing for most generated code. (TS changes where missed by the CI). Just like what we have for the monster.fbs

Step 3:

• [ ] Add doc to the flatbuffers website for each and every language.
• [ ] Add support to more languages.

Related blocking PRs:

• https://github.com/google/flatbuffers/pull/6338
• https://github.com/google/flatbuffers/pull/6441

[aardappel]

Thanks for doing this!

Let's see though to what extent it is reasonable to do all of this before 2.0: https://github.com/google/flatbuffers/issues/6353

[mustiikhalil]

From what i can see the only thing that might make an issue is this

Add examples for other supported languages + proper readme for each one of them including existing ones. (Note: this might require a 2.1 flatbuffers release, since I'll have to check if each and every language is working without any issues)

since that would mean we have to refactor some GRPC (in case the language supported is broken) like the earlier swift, ts builds

[aardappel]

so maybe we want to land things which are "fixes" before 2.0, and all the reorg stuff after?

[mustiikhalil]

Yeah, definitely. i can start working on that then if that's the case

[mustiikhalil]

~Do we include grpc upgrades to this? or should we keep it simple and just make sure that the generated code works? Since go as an example is outdated since there is a v1.35.x instead of what we are using, which from what i can see will lead to a bit of refactoring just like TS~

I updated the go Language GRPC support https://github.com/google/flatbuffers/pull/6448 in this PR. I thought it would take longer than what It actually took

[mustiikhalil]

@paulovap I have been writing examples for each language and making sure everything is up to date with all of the languages. I wanted to write an example in java and also make sure it works with the latest grpc-java. However since I have almost zero experience with java I couldn't really do much in that area. I would love to get some pointers on how to make it work if possible.

The vision I have for the java-greeter example:

• Have support for grpc 1.35.0
• Fetch local Flatbuffers Java dir into the project
• Fetch local Encoder/decoder? https://github.com/google/flatbuffers/tree/master/grpc/flatbuffers-java-grpc
• Client executable + server executable.

Is this possible? and if so is it possible to fetch remote + local dependencies at the same time?

[paulovap]

@paulovap I have been writing examples for each language and making sure everything is up to date with all of the languages. I wanted to write an example in java and also make sure it works with the latest grpc-java. However since I have almost zero experience with java I couldn't really do much in that area. I would love to get some pointers on how to make it work if possible.

The vision I have for the java-greeter example:

• Have support for grpc 1.35.0
• Fetch local Flatbuffers Java dir into the project
• Fetch local Encoder/decoder? https://github.com/google/flatbuffers/tree/master/grpc/flatbuffers-java-grpc
• Client executable + server executable.

Is this possible? and if so is it possible to fetch remote + local dependencies at the same time?

Hey, I haven't used GRPC so far. But I will try to find time to take a look.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.

[mustiikhalil]

keep alive

[dbaileychess]

@mustiikhalil Status on this?

[mustiikhalil]

@dbaileychess Blocked by Java and cpp since I don't have great knowledge in both those languages

[dbaileychess]

@mustiikhalil What must be done for those two languages?

[mustiikhalil]

For Java, I believe it would requires a refactor. however I'm not sure of how the library work, and my knowledge in java is limited.

For cpp, I believe this pr can paint the full picture, it would be nice to have proper support from GRPC for it to work.

we can close this issue for now.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

[github-actions[bot]]

This issue was automatically closed due to no activity for 6 months plus the 14 day notice period.