Try to call bblfsh server from the browser instead of from the backend API

[dpordomingo]

As reported by @dennwc via Slack, it might be interesting the new official beta:
https://github.com/grpc/grpc-web

It might worth to investigate the possibility of calling bblfsh from the browser, that was already discarded in the past for undocumented reasons.

[smacker]

Example of using grpc-web is here:
https://github.com/smacker/in-browser-uast

there is an example which is a simplified version of the dashboard.

[smacker]

implemented here: https://github.com/smacker/dashboard/tree/bblfsh_js

[dpordomingo]

from @smacker report at https://gist.github.com/smacker/af6b40ac6df44238cd1519ee698728f5

gRPC-web status

gRPC-Web is now Generally Available, and considered stable enough for production use.

It needs standalone proxy. Currently only Envoy can be such a proxy.

Implementation details:

• custom wire format grpc-web, not gRPC over HTTP2 as proposed before
• wire format has 2 modes: text and binary
  • text (default): payload are base64-encoded, supports both unary and streaming calls
  • binary: payload in the binary protobuf format, only unary calls
• wire format will become optional/outdated in 1-2 years due to new whatwg streams API standard.
  Current status of it: Edge, Safari, Chromium-based browsers partially support it already
• Doesn't provide library to include into grpc server itself and expose proxy on another port as 3rd party grpc-web libs used to do. (but it's in roadmap)

Overall:

• easy enough to use
• works stable and fast
• still requires proxy

gRPC-web with bblfsh

UAST1

Here is UAST1 prototype very similar to bblfsh/web, supports filtering and everything:
https://github.com/smacker/in-browser-uast/tree/google_grpc_web

• Works very fast
• No backend code
• Doesn't require re-parsing on filtering
• Reasonable size (a little bit more than 1mb but most probably can be improved)

UAST2

• protobufs can't be used as is because now they contain only array of bytes with custom encoding
• compiling client-go produces 18mb WASM
• js binding to libuast v3 would produce wasm of similar size
• most probably it's too much for the web (total bundle will exceed 20mb easily)
• js binding might be not straightforward as with uast1 because:
  • libuast depends on sdk which depends on gogo and generated code that we don't need
  • it would require small refactoring of sdk/libuast
  • though maybe I did something wrong and compiler actually removes this code already

Overall: doable if we are okay with a HUGE bundle. It will require some work both on apps and bblfsh side.

bblfsh/web

• we can remove our go backend and replace it with envoy
• but it won't be single binary anymore
• besides work for UAST2 support described above it would require:
  • adapt the result of wasm+js binding to be displayed correctly
  • rewrite github/gist integration (they return responses with Access-Control-Allow-Origin: * so we can do it on frontend too)