Altı brauzer sekmesindən bir dashboarda
The six-tab workflow
Before SAMURAI, answering a simple question like “which switch port is 10.1.50.23 on, and has its ACL changed recently?” required opening six browser tabs: APIC for the fabric view, FMC for firewall policies, Panorama for Palo Alto rules, an SSH terminal for the switch, ISE for authentication state, and maybe NDO if the endpoint spans sites. Each tool has its own login, its own session timeout, its own search syntax, and its own idea of what an “endpoint” looks like.
SAMURAI started as a personal tool to eliminate this context-switching tax. The goal was not to replace any of these platforms — they are good at what they do — but to provide a single read-only surface where you can query, trace, and monitor without leaving one browser tab.
Cache-first architecture
The key design decision that makes this work is cache-first data serving. SAMURAI does not proxy requests to upstream devices in real time. Instead, background sync workers fetch data from every device on a configurable interval (default: 3600 seconds) and store the results in MongoDB. The API serves from the cache. This means the UI loads in milliseconds, not seconds — regardless of how many devices you have or how slow their APIs are.
When you need live data, the ?live=true query parameter bypasses the cache and fetches directly from the device. For historical comparison, ?snapshot=2026-05-20T14:30:00Z queries a specific point in time. But 95% of daily operations — searching endpoints, reviewing policies, checking routes — are served from cache with sub-400ms latency.
One sidebar, one search
The sidebar presents every device type as a panel: APIC, FMC, Palo Alto, Routers, Switches, ISE, NDO, vCenter. Each panel shows the same primitives — devices, their collected data, and a changes tab — with device-specific views where needed (tenant hierarchy for APIC, security policies for Palo Alto, TrustSec matrix for ISE).
The search bar is global. Advanced search syntax supports field-scoped queries (vendor:cisco), CIDR matching (ip:10.0.0.0/8), boolean operators (AND/OR/NOT), quoted phrases, and negation. The same syntax works across every panel — endpoints, routes, policies, audit logs. One search language for the entire network.
WebSocket push for live updates
When a background sync completes, the server pushes an event over WebSocket. The frontend uses TanStack Query with cache invalidation tied to these events — when device X finishes syncing, the query cache for device X is invalidated, and any open panel refreshes automatically. No polling. No manual refresh button. The data appears when it is ready.
Sync status is also pushed over WebSocket. The sync button in the UI reflects the real-time state: idle, queued, syncing, success, or failed. This is hydrated from the server on mount (not from empty client state), so opening the dashboard mid-sync shows the correct status immediately.
Changes timeline
The changes page aggregates diffs from every device type into a single timeline. Instead of checking six dashboards for “what changed overnight,” you open one page, filter by time range or device type, and see every meaningful change with admin attribution where available. The timeline reads from a pre-computed change_log collection (~5ms per query), not from live diffs.
Şəbəkəniz nizam-intizama layiqdir
SAMURAI-ni real mühitinizə qarşı işlədiyini görün. Demoların əksəriyyəti 24 saat ərzində planlaşdırılır.