[bisq-network/proposals] Use a GRPC API as core API and use wrappers around for other API types (#136)

chimp1984 notifications at github.com
Sun Nov 10 21:29:56 UTC 2019


> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

## Overview
I am aware that we had in the past the discussion if we should use GRPC and it was rejected because we preferred that non-technical users have it easier to write their own applications agains an HTTP API. 

I would like to suggest though to rethink that again and suggest that we use GRPC as core API infrastructure and build any other APIs like a HTTP API around that. The benefit it that GRPC is much faster and easier to add and require only 2 dependencies (Googles grpc and netty.io) which are from huge projects and can be considered low risk dependencies (I assume netty could be replaces by other library as well if there is reason for it).

## GRPC proof of concept
I got my old [GRPC project](https://github.com/chimp1984/bisq/tree/grpc) updated to master and running again and could add 2 new endpoints (getTradeStatistics and getOffers) in roughly 20 min each. We can reuse our existing protobuf definitions for the domain objects and adding a simple endpoint is very simple. 

There are still some smaller issues open to improve (see FIXME comments) but as a proof of concept I think it is good enough.

There is still the question open if we should have 2 desktop modules (one without API and one with API embedded) to don't add those dependencies to all Bisq users even if the API is not enabled, but as those dependencies are much lower risk I think it is at least worth to discuss if that is needed.

The GRPC API has no authentication atm and is designed to be accessed via localhost only but still we should do the same way how Bitcoin Core is dealing with it. 

Any wrapper API exposing the API to public network need to implement a more secure authentication mechanism but I think the core API we deliver should not take that burden.

If we leave the wrapper APIs to other developers and not require it to become part of the official Bisq repo we do not carry those burdens and it help us to get out of those deadlock situations whoich we have at the moment that no maintainer has enough time and motivation to take the risk to review and audit that.

@blabno Do you think you could adjust your HTPP API to become a wrapper around such a GRPC API? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/136
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191110/0108e6b4/attachment.html>


More information about the bisq-github mailing list