BanyanDB gRPC/JSON transcode

[kezhenxu94]

Now BanyanDB are all based on gRPC protocol and since we are going to provide a web app (in GSoC), we could investigate the transcoding between gRPC and JSON protocol so that we might minimize the efforts to rebuilt/wrap the JSON protocol based on gRPC.

Reference: https://adevait.com/go/transcoding-of-http-json-to-grpc-using-go

This is not a solid requirement yet and needs some investigation so opening a discussion, if anyone do some research and find it feasible, we can open an issue to track this.

[lujiajing1126]

An alternative would be using node.js as an intermediate layer for the UI.

[wu-sheng]

I think @hanahmily doesn't want an out-of-process layer?

[hanahmily]

I tend to introduce an embedded one.

[sacloudy]

Banyandb-cli might also use the json-protocol API of BanyanDB.

[lujiajing1126]

Banyandb-cli might also use the json-protocol API of BanyanDB.

Since we are not facing similar limitations of the browser, the binary protocol is always an option for cli.

[hanahmily]

As I mentioned in #9044, tls, authN, and authZ are the primary concerns on this topic.

[kezhenxu94]

OK @hanahmily just opened an issue #9044 let’s track there

[lujiajing1126]

Besides, I'm always considering the possibility to create a web-based application built upon cross-platform GUI framework like https://github.com/electron/electron. I would say it is a trending, for example,

• https://github.com/rancher-sandbox/rancher-desktop
• https://github.com/docker/for-mac (Not sure now, but kitematic was written in Electron)
• https://github.com/microsoft/vscode
• https://github.com/lensapp/lens

Many years ago, we may use phpmyadmin for database administration but now most developers prefer applications like Navicat or DataGrip.

[wu-sheng]

I think you should talk with @hanahmily first. Last time, when we discussed this, he want a simple VUE application, with a go-based web container hosted inside the BanyanDB server directly as stage one MVP.

[hanahmily]

I agree that creating a native desktop tool is an interactive idea, and it may be the future. The motivation to build a SPA is:

• The students' capacity from the summer code campaign doesn't align with such high-level requirements. Most of them know basic frontends tech stacks. But the GUI frameworks are out of their radars.
• An embedded SPA is easy to release. BanyanDB is a new creature for all the ppl. A full-battery artifact is good to make it popular around the world.
• The SPA could be the trial version of GUI. If we keep polishing the web UI, the GUI is not far ahead.

[lujiajing1126]

I agree that creating a native desktop tool is an interactive idea, and it may be the future. The motivation to build a SPA is:

• The students' capacity from the summer code campaign doesn't align with such high-level requirements. Most of them know basic frontends tech stacks. But the GUI frameworks are out of their radars.
• An embedded SPA is easy to release. BanyanDB is a new creature for all the ppl. A full-battery artifact is good to make it popular around the world.
• The SPA could be the trial version of GUI. If we keep polishing the web UI, the GUI is not far beheaded.

Agree! Let's do it step by step.