Unified L7 communications view

Spider captures and parses several Layer 7 protocols at once: HTTP and PostgreSQL, both TLS encrypted or not.

Until now, each protocol lived in its own dedicated view.
That worked well for focused investigation - but it made it harder to reason about what a service was actually doing at a given moment, because you had to flip between tabs and correlate manually.

The Unified view (labelled "All" in the view selector) solves this.
It is a unified view that shows HTTP and PostgreSQL communications together in a single grid, sequence diagram, waterfall, and stats panel.

What the unified view contains

The All view aggregates communications from both protocols into a single stream, ordered by time.
Each row carries a type indicator so you always know what protocol you are looking at.
Clicking any row opens the correct per-protocol detail panel

• the HTTP detail view for HTTP communications,
• the PostgreSQL detail view for PgComs.

Every major sub-view is available:

• Grid - sortable, filterable table with Excel export. Columns adapt to the communication type.
• Sequence diagram - actors and flows across both protocols on the same canvas. Useful for spotting the chain of calls a single user request triggers - HTTP to a gateway, then PostgreSQL to the database, all in one diagram.
• Waterfall - timeline bars for all communications. See the companion post for this new feature.
• Stats - aggregations across both protocols: top servers, top clients, status codes, duration distributions, templates, tags...
• Filters - a unified filter panel covering both protocols: IP, TCP, template, parsing status, request/response size, status code, duration, and tags.

The view selector

The view selector in the top bar now groups the L7 views visually: All, HTTP, and PostgreSQL are grouped together, separated from the L4/raw views (TCP sessions, Packets).

This makes it obvious that All is the entry point for cross-protocol investigation, with the per-protocol views available when you need to narrow down.

What it is built on

• The unified view queries a dedicated Elasticsearch alias (spider-search-multicoms) that unions the HTTP and PostgreSQL communication indices.
• The backend MultiRead service handles search, aggregation, and pagination against this alias.
• Documents returned carry a @type field (HttpCommunication or PgCommunication) that the UI uses to route detail-view requests to the correct per-protocol endpoint.

Any new L7 protocol would be added naturally in this model.

When to use it

Use the unified view when you want to understand what a service or a client did over a time window, regardless of protocol.
Use the per-protocol views when you are investigating a specific HTTP or PostgreSQL issue and need protocol-specific filters and columns.

The sequence diagram in unified is particularly useful for tracing a full request path: you see the HTTP call arrive at a gateway, the downstream HTTP calls it makes, and the PostgreSQL queries the database tier generates - all in one diagram, ordered by time.

Vibe coded with Claude

This feature was built almost entirely with Claude Code, and the experience was remarkable enough to document here.

The brief: a Trello checklist screenshot

Every new Spider service follows the same checklist:

• scaffold from a template,
• initialize the GitLab repo,
• wire up the helm chart,
• register the Elasticsearch indices,
• add the monitoring configuration and dashboards,
• update the technical documentation

About 25 steps in total, that I was used to perform by hand.

Rather than describing all of this in prose, I gave Claude a screenshot of the actual Trello card I use to track these tasks.
The checks are terse - the kind of shorthand that only makes sense once you know the codebase.
Claude decoded them, mapped each one to the right files, and produced the right changes.

The result of that single session was:

A /new-service skill (new-service.md, 408 lines) A reusable Claude Code command that encodes the full 25-step scaffolding process.
Given a new service name and a template service name, it:

• copies and renames the template;
• cleans up routes, models, and DAOs;
• initializes the GitLab repository;
• updates the Helm chart values and default configuration;
• registers the Elasticsearch index indices and aliases;
• adds the monitoring rules and injects the new service into the self-monitoring dashboards;
• and updates the technical documentation!

The MultiRead service itself Built from the Tcp-Read service as a template in one pass, already wired into the chart and correctly querying the spider-search-multicoms alias.

90% of the work was correct on the first attempt, from a checklist screenshot.

The UI: dependency injection at scale

The Network-View frontend is structured around dependency injection and multiple levels of abstraction.
Adding a new collection requires touching a specific, bounded set of files - config, store, view registrations - but the patterns are not obvious from a surface read.

I expected this to slow Claude down. It did the opposite.

Claude navigated the injection chain, identified every file that needed changing, and produced a working unified view in roughly 15 minutes!

The MULTI_COM collection appeared in the view selector, wired to the right store, delegating detail views to the per-protocol collections via the @type field - exactly as the existing HTTP and PostgreSQL collections worked.

One moment stood out: the map tooltips needed updating to show a per-protocol breakdown.
I had forgotten the exact mechanism the UI uses for tooltip content (a Map dependency passed through the component tree).
Claude found it, understood it, and extended it correctly without any hint.
The commit that landed it is a single focused change. 🚀

What followed

The initial working view landed on February 24.
The two weeks after were a back-and-forth of targeted refinements:

• new column definitions,
• Excel export,
• aggregation terms (Protocol, Server (DNS name), Template),
• the unified filter panel,
• new Waterfall view, and lane grouping

Each session fast because the structure is clean and Claude understood it.

Lesson learned

tip

The lesson: a well-structured frontend with clear abstractions and dependency injection is not a liability for AI-assisted development.

It is an asset.

The same boundaries that make the code maintainable for humans make it navigable for Claude. 💪