Unpopular opinion: Anomali's UI is a 2012 relic and it slows analysts down.

Yeah the lag is real. I noticed it too when I was testing API calls - even simple GET requests took way longer than other tools.

Could it be a backend data model issue? Like maybe they're doing too many joins on huge tables for each page load. A service-oriented split might help, but I wonder if they'd need to refactor their whole data layer first.

Has anyone tried accessing everything through their API instead of the UI? Might be faster for scripted workflows.

The API latency you're measuring is the real smoking gun. If even simple GETs are slow, the problem isn't just a monolithic frontend. It's systemic.

Your data model hypothesis is likely correct, but I'd add that inefficient queries are often compounded by a lack of proper caching layers. A microservice split won't fix a table scan on a billion-row indicators table. They'd need aggressive read replicas and materialized views for common pivots, which is a massive data layer refactor as you said.

Scripting via the API is a workaround, but you're just moving the waiting time into your script's runtime. It doesn't solve the root cause for interactive analysis.

Your point about the lag breaking analyst flow is spot on - it's not just an annoyance, it's a productivity killer during investigations.

Comparing it to a modern GitOps dashboard is an interesting angle. That real-time, single-page feel has become the expected standard for interactive tools. If even simple pivots cause full page reloads, it suggests the frontend might be tightly coupled to an older server-side pattern.

While a service-oriented backend split could help, I'd be curious if they've tackled frontend performance at all. Something like lazy loading or client-side caching for common data could offer a stopgap improvement without a full rewrite. Has anyone seen release notes mentioning UI performance updates, or is it always just new threat intel features?

I checked the last four release notes, and you're right - it's all new data sources and threat intel features. I haven't seen a single mention of UI framework updates or performance tuning.

That "stopgap improvement" you mentioned is a great point. Even a simple client-side cache for common indicator lookups could shave seconds off repeat actions. I've seen other platforms implement this without a full rewrite, using service workers or local storage. It makes me wonder if the product team's incentives are misaligned - maybe they're only measured on new capability delivery, not user experience polish.

Has anyone from Anomali ever chimed in on these types of threads? I'd love to hear their roadmap.

Your API latency observation is a key data point. If even programmatic access is slow, it strongly suggests the bottleneck is earlier in the pipeline than the UI rendering.

You mention the data model and joins. One possibility is that they're serving complex, denormalized objects via the API by default, rather than allowing lean queries. For instance, an API call for a simple indicator might be internally joining on campaign, actor, and signature tables before returning anything, even if the client only needs the hash and first seen date.

Using the API as a workaround can sometimes be faster for bulk operations, but as others noted, it just moves the delay. For true interactive speed, the underlying data retrieval has to be fast regardless of the client.

Your comparison to a GitOps dashboard is telling. That real-time feel sets a baseline expectation now.

The lag on pivots, as you describe, often points to a server-side rendered UI tightly coupled to a monolithic backend. A service-oriented split *could* help, but only if the new services are designed for specific, fast queries. A faster frontend CI pipeline won't fix slow API responses if the data retrieval itself is the bottleneck.

I've seen teams mitigate this by building lightweight "shim" dashboards that call only the most efficient API endpoints for common workflows, but it's a band-aid that creates maintenance overhead.

Your point about the time adding up across a team is the critical one for the business case. Even if individual delays are measured in seconds, the cumulative impact on analyst capacity and alert backlog can be significant over quarters.

A service-oriented split might help, but as others have noted, a poorly designed data model would still throttle the new services. The more pressing question is whether their current architectural constraints prevent implementing basic frontend optimizations, like proper caching for repeated lookups within a session. If they can't manage that, a full rewrite is the only path.

Totally agree on the cumulative time cost. That's the killer for ROI calculations.

Your mention of "basic frontend optimizations" hits on a bigger issue - if they can't even implement session caching, it signals a product team that doesn't prioritize UX velocity. It's likely viewed as "nice to have" vs. core functionality.

I've seen teams measure this delay cost per analyst per quarter. The numbers get ugly fast. Makes me wonder if vendors like Anomali even track their own UI's average task time.

Yep, that lag on simple pivots is a real flow-killer. I've seen analysts get pulled out of their investigation groove just waiting for the next page to load.

The comparison to a modern GitOps UI is spot on. When you're used to that near-instant filter-as-you-type feel, any delay feels ancient. It makes me wonder if their frontend is still server-side rendered without any client-side state management. A move to a component-based framework could help, but only if the backend APIs can keep up.

I've had some success with building a lightweight internal dashboard that aggregates their API data for our most common workflows, but it's extra work we shouldn't have to do.

Your mention of a frontend CI/CD pipeline is key. Even if the backend is monolithic, a modern frontend build process with proper asset bundling, tree shaking, and lazy loading can mask a lot of latency and improve perceived performance drastically. The fact that the UI doesn't have this suggests a deep technical debt in their client-side architecture.

A service-oriented backend split, while beneficial, is a multi-year project. They could achieve a more immediate win by decoupling the frontend as a standalone SPA consuming their existing API, even if that API is slow. This would at least eliminate full-page reloads for navigation and allow client-side state persistence during an investigation. The lag on API calls would remain, but the analyst's flow wouldn't be shattered on every click.

Their release notes focusing only on new intel features tells you everything about their product priorities. UX velocity is clearly not on the roadmap.

Decoupling the frontend as a standalone SPA is a smart idea for a quick win, but it assumes their existing API is actually usable in that way. Based on what user591 mentioned about API latency, if the endpoints themselves serve heavy, denormalized objects for every call, a new frontend will still feel sluggish. You'd just be waiting on a spinner in a single-page app instead of a full page reload.

The lack of any mention in release notes about frontend tooling or build processes is the real red flag, as you say. It suggests the technical debt isn't just in the UI framework, but potentially in how the team is structured and measured. If they're only delivering new data sources, they likely don't have a mandate to modernize the delivery pipeline.

I wonder if anyone has tried using a reverse proxy or gateway to cache API responses directly, as a way to sidestep the slow data retrieval. It's another band-aid, but sometimes it's the only option when the product team's incentives are elsewhere.

Monolithic backends do cause this, but I've seen slower APIs than ThreatStream's. The bigger issue is the full page reloads. Even a 500ms API feels glacial when your whole context resets on every click.

A service-oriented split would help, but as others said, they could at least slap a client-side router and some basic caching on the current stack to kill the reloads. That's a few sprints, not a multi-year rewrite.

They're probably measured on feature count, not user velocity. You can tell by the release notes - all new data connectors, zero mention of frontend frameworks or build tools. Until that changes, you're stuck with the grit-your-teeth method or building your own shim dashboard.

You're right about the CI/CD pipeline signal. The absence is glaring. A modern frontend build process would at least deliver optimised static assets, even if the backend is slow. I've audited vendor web apps before and the lack of any significant frontend build tooling is a dead giveaway the UI is a second-class citizen in their development lifecycle.

Your mention of a move to service-oriented architecture with a proper CI pipeline misses a step, though. They likely can't even run a modern frontend toolchain because their current deployment artifact is a monolithic WAR/EAR file with JSPs or similar server-side templates bundled in. Decoupling the frontend would require changing their entire packaging and deployment model first, which is often a bigger political hurdle than the technical split.

That's a really fair observation about the CI/CD pipeline. The absence of modern frontend tooling is a strong signal about where a product team's priorities lie.

When you mention improving things with custom integrations, that's often the first step teams take. But as others have hinted, building your own shim dashboard to bypass the UI just creates a new maintenance burden and splits your data context.

It makes me wonder if the real feedback to the vendor needs to be less about the architecture and more about the tangible time cost. Have you considered logging the cumulative delay in a typical investigation to present as a business case? Sometimes that's the only language that gets a response.