Skip to content

feat: devex for js-waku logs and developer support #2212

@weboko

Description

@weboko

Description

js-waku logs are important for debugging, providing support and, potentially, collecting metrics from the code.
We need to make sure developers that are integrating js-waku can easily share their logs for reporting a bug or getting support from core js-waku developers. Also, we should try enable developers to measure js-waku performance, though this is more important for NodeJS environment than Browsers.

User Story

  • As a consumer of js-waku lib, I want to be able to get logs, so that I can read them or share with other people.
  • As Waku CC, I want to be able to easily navigate logs that are shared to me or that I retrieved from debugging.
  • As a consumer, I want to see past performance of the node by uploading logs to a visualizer.
  • As a consumer, I want easily understand what error(s) occurred by reading and navigating logs.
  • As a consumer, I want to measure performance of the node in run time and report to a server if needed.

Proposed Solution / Feature Design

This feature is modular and can be approached in iterations.

Logger

We need to develop an API compatible with both Browser and NodeJS environments that enables consumers to retrieve logs based on their configured verbosity level.
Additionally, consumers should have the ability to save these logs to a file for later access.

It’s essential to support logging from libp2p, as these logs can be crucial for investigating potential issues.
Furthermore, the formatting of log entries should be enhanced to ensure they are intuitive and easy to navigate, particularly for first-time users.

To bring more awareness to these changes we need to add Reading logs and debugging section to docs.waku.org mentioning format of js-waku logs and tips how to navigate it.

Metrics and visualization

Following example of js-libp2p we should consider exposing internal behavior of js-waku through a set of packages and API in order to allow application developers to track and measure behavior of it.

On top we should investigate if we can provide some simple pre-setup boards that can visualize captured metrics.

With this sub-task we should be cautious and facilitate needs only relevant for Browser environment. From that PoV some things might not be needed.

Notes

Relevant js-libp2p packages:

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status

    To Do

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions