Proposal: Consolidate k-charted library into kiali repo

Skip to first unread message

Lucas Ponce

Nov 10, 2020, 6:00:16 AM11/10/20
to kiali-dev
Hi all,

In Apr 2019 we modularized the chart component used by Kiali to render inbound/outbound and runtime metrics in a library called k-charted.

This library has two parts: backend and frontend.

Backend performs queries to k8s and prometheus, and frontend provides the dashboard charts used for the metric detail tabs.

In code, it creates two dependencies that need to be updated on new changes both in backend and frontend.

There are a lot of pros/cons of this pattern but today Nov 2020 perhaps it makes sense to re-consider to move the code into the kiali repo to simplify some aspects. 

This is a list of reasons for this proposal:

- Reduce the dependencies and the bump of versions for minor changes (in UI mostly, the backend looks quite stable).
- Put all communication from Kiali to backend in a single location to share caching, and other potential techniques for optimization and re-use queries).
- Both kiali and k-charted uses the same dependencies on k8s and p8s clients, when upgraded, needs to be updated in both.
- UI tends to need minor maintenance (CSS, z-index issues, etc).

In general, I guess that k-charted is very tight to kiali in terms of business and team would benefit to have the code located in a single place.

Another reason, in the context of the multi-cluster effort is clear that Kiali would need to query more than one single endpoint for k8s/p8s/tracing, so having this logic located in a single point would help in general (if not, k-charted would need also to adopt same design used by kiali when multiple cluster are defined).

This is not a refactoring, logic and components should be untouched/unchanged and we don't want to miss the very good storybook that k-charted implements, it's more just to move the code to a single repo.

Joel and I had some preliminary chat about it and we would like to get more inputs from the team about this proposal.


Joel Takvorian

Nov 10, 2020, 11:34:06 AM11/10/20
to Lucas Ponce, kiali-dev
Adding some comments:

Having a separate library was originally aiming to see other projects potentially consuming this charts library, which offers some kind of prometheus-to-react bridge via a kubernetes CRD. If that was the case, Kiali could have benefited from a broader variety of dashboards, for different runtimes or contexts.. But it didn't happen so far [*] and I don't see any reasons why that would change, so I'm also +1 to merge it in Kiali in order to simplify our development processes, for the reasons that Lucas gave.

[*] there's Iter8 which does actually use custom dashboards, but it's doing so through and for Kiali, not with a separate UI that would consume k-charted, so that wouldn't change anything for them

You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Jay Shaughnessy

Nov 10, 2020, 12:33:31 PM11/10/20

I support bringing k-charted into Kiali proper.

Mike Thompson

Nov 10, 2020, 1:35:00 PM11/10/20
to Jay Shaughnessy,
I think this makes total sense! It will simplify development which is always a good thing :)

Edgar Hernández

Nov 12, 2020, 11:23:03 AM11/12/20

Probably a little late in the conversation, but I want to also give my thumb up to merging k-charted into the main kiali/kiali repo... and, of course, also merge the front-end part into kiali/kiali-ui.

I understand that we wanted to make easier for people to contribute to these generic dashboards part. But this goal hasn't succeeded.
So, I'm +1 to going back to the so-so "monolithic" code to reduce maintenance efforts.
Reply all
Reply to author
0 new messages