liftbridge-io / liftbridge-api

Protobuf definitions for the Liftbridge gRPC API. https://github.com/liftbridge-io/liftbridge
Apache License 2.0
15 stars 13 forks source link

Management API #1

Open ghost opened 6 years ago

ghost commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 https://github.com/liftbridge-io/liftbridge-grpc/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhvcdB6cAhRx8B7N3WJo-umdoUsVy7Sks5uRRpNgaJpZM4V_UEu .

ghost commented 6 years ago

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, notifications@github.com 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 notifications@github.com 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 https://github.com/liftbridge-io/liftbridge-grpc/issues/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 https://github.com/liftbridge-io/liftbridge-grpc/issues/1#issuecomment-413515918, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwlBK8zG9oZ-t0zNR2H8L9vmb4gjLks5uRVlEgaJpZM4V_UEu .

tylertreat commented 6 years ago

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 commented 6 years ago

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.