[WIP] NETLAB-App using clab-ui

[Muddyblack]

So maybe or maybe not @DanPartelly remembers that before containerlab released their VS Code extension I started building a web UI too, focused on netlab with clab.yml as second priority. The moment they released their UI I scrapped mine. The clab VS Code extension was just better, had more features, and a UI wasn't really what I needed personally anyway. It was just a small attempt where I realised it is a lot of work. I mostly prefer handy scripts :D

Fast forward to now: srl-labs has extracted and published their UI code as a package @srl-labs/clab-ui, so I asked myself why not reuse their UI and add a netlab backend to it. Their UI is pretty heavily clab-api reliant, so the idea was to use the clab-ui library and build a dedicated topology viewer for netlab from it. The core idea: avoid reinventing what clab-ui already does great.

On the clab-ui side, either srl-labs accepts merge requests that make it more open to reuse it without affecting their own clab workflow, or I fork it and continue side by side. Not sure which is the better approach.

Mini demo (doesn't show much without the backend though): https://muddyblack.github.io/netlab-app/

---

Stack in brief

• Backend: FastAPI implementing the ClabUiHost contract + PTY web shell
• Frontend: React 19 + Vite, consuming clab-ui canvas with netlab-native authoring panels
• API types generated from Pydantic models → TypeScript via openapi-typescript (no drift between Python and TS)

---

Honest caveats

This is very much a WIP and a mini side project with higher-priority things competing for my time. The last 2 weeks I also have the feeling AI is getting dumber and less useable which slows such fast idea-prototyping down. The approach is doable but it will take time, and I'm uncertain how much I can invest right now. But I would like to make it work over time.

If anyone's interested in taking a look at the (messy) private repo (also needs local symlinking clab-ui), I would invite you to the private repo. It is just ... very ugly and messy so ...

---

The question tho

Is a dedicated netlab GUI something actually worthy. I mean I personally mostly just use the netlab plugin system.

But I would say what would be still nicer with UI is to define groups — example a workplace, a work-room which uses those workplaces, a building which hence uses those work-rooms, a site which has buildings etc.
Where you could say that a desktop typically has a connection from here to somewhere in the work-room, and as you scale, the connections scale directly with it?

My first UI attempt over a year ago actually had this. It was mostly missing an API to generate the netlab YAML. And well... scaling it up massively just had rendering issues with hundreds of nodes. The new clab-ui handles it now a bit better than it did earlier.

What is your take on the dependency-vs-fork trade-off? I'd love to be able to add netlab as a plugin into the containerlab app somehow, but yeah that seems even harder.

For now this was a small experiment showing that it is doable. Interested in if it is worth continuing and what you think.

@ipspace

Still have to make yml code editing saving work, and refactor backend cleaner and review all that ai code haha - as well a lot of minor improvements

[Muddyblack]

As addition clab-ui expects of cause clab yml formation for the links section. Hence I am kind of forced to rewrite the netlab.yml data sent to the topology drawer adding a empty string for the devices adapter so it will draw it. Which is no issue. What can be added is once clab init or so has run once it gets the adapters data from the ansible files or so but that is future work.

As well live stream of netlab up command it does execute but only works when it has errors with no errors it does not display the output haha.

[ipspace]

The UI looks great ;) Let's see what @hellt thinks about adding netlab support to the existing package.

[DanPartelly]

@Muddyblack , Yeah, I recall your first version of a GUI.

As for the current situation, talk to Roman / FloSch first. From a maintenance PoV getting the code upstream - if possible at all - would be best.

[FloSch62]

@Muddyblack looks nice how you use the clab-ui 👍
For sure I like contributions to the upstream if its something useful for both projects, but for the maintainability burden I would not like to integrate it deeper into the clab-ui package. The contracts should allow extensions and overwrites, as you already show in the demo :)

[ipspace]

@Muddyblack -- looks like you're in sync with @FloSch62 (and @hellt and myself are perfectly OK with whatever you two decide to do), so go for it 🎉

[Muddyblack]

Sounds good over the next week I am off the computer. But I will propose a PR then soon once I am sure I only include minimal changes required to make it work up to the clab-ui.

[FloSch62]

The best thing is that in your demo the eastergg still work 😉

[Muddyblack]

I have never looked out for easter eggs but i found it i love the fact you added such 😂😂