Explore alternative RPC interface

[benthecarman]

We currently use a REST interface with a RabbitMQ notification system. While this works, we have discussed alternative options.

@tnull on reasoning for the current choices

We wanted to add a 'purely notifications' message stream that allows for pub/sub and doesn't lead to repersisting the event queue, and is also generally decoupled from LDK's events which is a mixture of 'informational notifications' and 'async callbacks' basically. The original choice to do protobuf-over-REST was because we already used the same stack for VSS server, where we chose that as gRPC is hard to integrate with WASM. I have no insight into why we picked RabbitMQ in particular, but I suspect simply since it's relatively commonly used. As discussed, we could consider to replace that with gRPC, especially if we bundle that with more fine-grained access control that could still give some (e.g. accounting backend) subscribers read-only access to the node. From my side happy to do whenever, though given it will be rather API breaking if we don't want to keep maintaining both gRPC and protobuf-over-REST, we might want to do it before 0.1? Not sure?

Personally I would prefer gRPC. It allows for bidirectional communication and is great for working with because with most languages you can just use the proto files to generate a complete client.

@joostjager expressed:

I'm not sure how much we'd gain by switching to gRPC. SSE seems like a more natural fit? It keeps everything on the same HTTP protocol, still gives us a stream for notifications, and removes the RabbitMQ dependency without introducing new complexity.

[joostjager]

I think the main friction point for gRPC is browser support. Looking at Lightning Labs, they seem to repeatedly add gateways, adapters or shims to their stack to make grpc work. It may be good technically, but I think we need to be quite sure that it is so much better than the existing HTTP mechanisms that it justifies the extra work.