Management API

[ghost]

Was thinking about stream, and subject discovery for administrating liftbridge.

As I understand it NATS has this and it's highly dynamic where you can see the topics and channels being created in real time.

So I want to ask if this is useful to expose over the grpc API.
It will allow building developer and operator tools on top of liftbridge using only grpc. I was thinking about building a simple CUI first.

[tylertreat]

Yeah I think so. Better instrumentation is something I have planned but have not yet put much thought into how. I do think providing an API is a good first step though.

…

On Thu, Aug 16, 2018, 2:07 AM gedw99 ***@***.***> wrote: Was thinking about streeam, and subject discovery for administrating liftbridge. As I understand it NATS has this and it's highly dynamic where you can see the topics and channels being created in real time. So I want to ask if this is useful to expose over the grpc API. It will allow building developer and operator tools on top of liftbridge using only grpc. I was thinking about building a simple CUI first. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAhvcdB6cAhRx8B7N3WJo-umdoUsVy7Sks5uRRpNgaJpZM4V_UEu> .

[ghost]

I got NATS web GUI going for now. It's nodejs and should be easy to use it as a basis to convert to grpc-web ( not the c++ one, but the pure golang one ). The other option is dart grpc with a dart GUI is also a smart move. Dart-grpc-web just got committed today. I have been using go grpc with dart grpc - have not had any issues at all. Very stable and easy I found So I guess I would favour dart grpc. It will make it easy to manage as it's strong typed all the way through. But up to you. I can help a bit but am pretty pressed right now for time

…

On Thu, 16 Aug 2018, 13:36 Tyler Treat, ***@***.***> wrote: Yeah I think so. Better instrumentation is something I have planned but have not yet put much thought into how. I do think providing an API is a good first step though. On Thu, Aug 16, 2018, 2:07 AM gedw99 ***@***.***> wrote: > Was thinking about streeam, and subject discovery for administrating > liftbridge. > > As I understand it NATS has this and it's highly dynamic where you can see > the topics and channels being created in real time. > > So I want to ask if this is useful to expose over the grpc API. > It will allow building developer and operator tools on top of liftbridge > using only grpc. I was thinking about building a simple CUI first. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1>, or mute the > thread > < https://github.com/notifications/unsubscribe-auth/AAhvcdB6cAhRx8B7N3WJo-umdoUsVy7Sks5uRRpNgaJpZM4V_UEu > > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATuCwlBK8zG9oZ-t0zNR2H8L9vmb4gjLks5uRVlEgaJpZM4V_UEu> .

[tylertreat]

So one thing I've been wondering is does it make more sense to expose a monitoring API via REST or should it just be a gRPC API?

[ghost]

Ah good question.
There are some good arguement to use rest, because the client is not as tightly coupled.
I hate REST though. So much untyped mess that gets worse as the API gets bigger.

My instinct is to use grpc for now
It will allow superior real time updating Ops GUI.
Also grpc-web and grpc REST can later easily be codegen on top of grpc proto later if needed.