A lightweight, extensible Kibana-style UI for XERJ — interested?

[Vinz2168]

Hi! I've been using XERJ as a drop-in Elasticsearch replacement, and the thing I missed most was Kibana: the query bar, the filter chips, Discover, the Dev Tools console. So I built a small UI that brings those habits to XERJ, and I'd like to know whether it is useful to the project before investing more in it.

Vega Board is a static web app that talks to XERJ only through the Elasticsearch-compatible API. Two things guided every choice:

• Lightweight: about 73 KB gzipped, no build step, no npm dependencies. It's just files you serve.
• Extensible: a new chart, control or page is one file plus one line in a manifest. The core doesn't need to change.

It has three pages:

• Dashboard: panels with Vega-Lite charts, a global time picker, a query bar, include/exclude filter chips, options-list controls, drag-to-zoom on time, and dashboards saved in an index.
• Discover: document table, field list with top values, histogram, and include/exclude filters from any value.
• Dev Tools: console with request history, examples and "copy as curl".

Why it might fit XERJ

• It's light enough to ship with the binary: about 73 KB of application code gzipped, plain ES modules served as they are, with no toolchain to maintain. Vega/Vega-Lite come from a CDN today, but they could be vendored.
• It only uses the public ES API: _search, _msearch, _mapping, _cat/indices and GET /, plus PUT/DELETE of _doc to store dashboards in a regular index (vega-dashboards). There is nothing XERJ-specific to maintain on your side.
• It can be served by XERJ itself. Today it runs behind a small same-origin proxy, because XERJ sends no CORS headers unless cors.allowed_origins is configured. Served from the node, on its own path, it would just work, with no CORS and no proxy.
• It works on other engines too: I tested the same build on OpenSearch 3.9 (security plugin on, username/password login). That makes it a migration path: people can keep their Kibana muscle memory while moving to XERJ.

Compatibility testing

I ran the board against XERJ v1.0.0-rc.93 with two example dashboards (20 panels) and compared every panel query with a reference engine (the board's in-browser demo engine) on the same documents:

• 49 of 54 panel queries return identical results. Of the other 5, three are the highlight issue below. The remaining two differ only because hits.total stops at 10,000 by default, exactly as in Elasticsearch, while the reference engine counts exactly.
• highlight with fields: {"*": {}} is ignored, so there is no <mark> in search results ([bug]: Wildcard field names in highlight.fields ("*", "mess*") are ignored — no highlight in hits #1281, fix proposed in fix(highlight): expand field-name patterns in highlight.fields (#1281) #1294).
• No CORS headers by default. A cors.allowed_origins setting exists, but --help doesn't mention it ([bug]: --help: CORS config is not discoverable, and the default native REST port is described as PORT+1 (it is 8080) #1286).

The full write-up is in the field report #1287. The same run turned up a few smaller deviations, each filed as an issue with a proposed fix (#1282–#1285, #1288 → #1289–#1293). The core of what a dashboard needs worked as in Elasticsearch: terms ordered by a single-value sub-aggregation, percentiles (exact values, nice!), date_histogram with extended_bounds, _msearch, and saving and reloading dashboards.

How it relates to the XERJ Console

I know the console exists and goes in its own direction: typography-first, AI-centric dashboards, passkeys. This is not meant to replace it. It targets a different user, someone coming from Elasticsearch and Kibana who wants the familiar workflow on day one. I'd see it as complementary: linked from the console, or served on a separate path.

Extending it

Extensibility is the core design goal. Everything is added through files and manifests, never by editing the core:

• A widget is one ES module with query(), rows() and a Vega-Lite spec() (or an HTML render()), plus one line in a manifest. The two newest widgets, a double donut and an options list, were each added this way in a single file.
• A page is one module plus one line in config.json.
• Replacing a standard widget: put a copy with the same type in widgets/custom/. Existing dashboards keep working, and nothing is forked.
• Configuration (engine, URL, login options, demo data) lives in config.json.

That makes it easy to add XERJ-specific views later (vector search, RAG metrics…) without touching what's there.

A validator (node tools/validate.mjs) runs every widget against an in-browser demo engine, and an AGENTS.md describes the contracts for humans and coding agents. The UI is in English and Italian and follows the browser language.

Questions for you

1. Is this something you'd want in or around the project? Options I can see:
   • served by the node on a path like /_board;
   • a separate repo under xerj-org;
   • just a community project you link to.
2. If you'd serve it: would you accept vendoring Vega (~1 MB minified) into the binary, or should it stay a separate download?
3. Is there anything about the console's roadmap that would make this redundant soon? I'd rather know now.

Code: https://github.com/Vinz2168/xerj-vega-board (Apache-2.0). Happy to adapt the license, naming and structure to whatever works for you.

Built with the help of an AI coding assistant (Claude Code); every change was tested against a real XERJ node.

[xerj-org]

Please check Xerj-UX it has some UX already and if you can lead that, you can make it works as Kibana

Would be great, we have strong foundation already