The discussion discarded the need of a waku-cli (REST API client) to assist with Status app investigation, in favour of metrics and log parser.
However, I maintain that all Waku APIs should be aligned as described in Prometheus, REST and FFI: Using APIs as common language
More concretely:
- Define a C API for a specific action, as done in [1], for example:
extern int waku_publish(char* messageJSON){}
This method:
a. Publishes a message over relay or light push, depending on the mode of the node (edge vs relay)
b. May use several light push service node if in edge mode
c. Emits several events such as (skipping how this is handled, this could be done at node level or function level, too detail for the illustration):
i. error
ii. light push ack received
iii. store confirmation received (if enabled at node level)
-
Have a method in libwaku (nim), that implement and exposes this C API
-
Have a method in the Golang bindings, that would be
func publish(instance *WakuInstance, msg *pb.WakuMessage)
- Have a method in js-waku, that would be
class WakuNode {
public async publish(
msg: WakuMessage
)
}
- Have a REST API route, that would be:
POST /waku/publish
{
"msg": {..}. // messageJSON
}
Meaning that no matter the language being used, the Waku API remains consistent, with a goal to keep extensibility cost as low as possible.
The need is clear regarding Golang and C API alignment, the aim is to have clear boundary between Status and Waku (Golang) code and ensure the Waku API is as simple as possible. Similarly for Rust.
Regarding js-waku and C, the benefit would be developer experience and future-proofing: if the need arises, a full stack JS SDK that is nwaku based in NodeJS/React Native and js-waku in the browser would be facilitated by an existing alignment of the API.
In any case, we know that we were guilty of providing complex API with too much protocol level details [2]. Spec’ing the API is a way to ensure we are deliberate about our choices.
Need for REST API
Long term
As native applications integrate Waku, and users end up running several embedded Waku nodes on their devices; we expect a need to run a single Waku node, that can be used by several applications.
In this context, a REST API aligned with the C API would make sense. Allowing several applications to share one Waku node and save bandwidth.
Short/mid term
Short and mid term, the need is not as evident. One argument would be that a REST API is easier to use than a C one. Hence, for developers that do not have access to a Waku SDK in their languages (yet), may prefer usage of REST.
However, it is a weak argument as most languages allow for the usage of C libraries.
Conclusion
At this point in time, I do not see a need to tidy up the REST API. However, if we were to do so, aligning the REST API with the common Waku API seems an obvious choice.