SeAT - thread: I just wanted to share a bit of the - Page 1

“Single member view” This is exactly what corp leadership wants:

• Main + alts

• Activity breakdown

• Trends over time

• Timezone patterns

• Skill / role alignment

That’s actionable intelligence, not just pretty charts. “System usage / milked vs wasted” This is literally:

• Resource optimization

• Strategic planning

• Upgrade / downgrade decisions

• Risk vs reward balancing

That’s already how alliances think — they just don’t have good tooling for it. “Sov / renter performance” That’s:

• Value tracking

• ROI measurement

• Infrastructure planning

Again: very real use case. “Predictive / advanced analytics” This is the natural next step once you have:

• Historical data

• Patterns

• Behavior models

Even simple things like:

• “This system is trending down”

• “This member is burning out”

• “This TZ is underused”

…are already powerful.

You basically describe why seat supports plugins. Everything you describe can be done with plugins.

It is also more or less what I've been doing for years:

• https://github.com/eveseat-plugins/seat-market-monitor - created to monitor market manipulation for a nullsec coalition

• https://github.com/eveseat-plugins/seat-rat - created to monitor ratting usage of rented systems

• https://github.com/eveseat-plugins/seat-mineral-hauling - calculator to determine the cheapest way to haul ore in eve. Built as a seat plugin because seat already has all the data

it is all a question of someone taking the initiative and doing something

If you don't want to use PHP, fine we have an API for a reason.

If the API doesn't expose all the data you need, you're also very welcome to improve it

Totally fair, and I get why plugins are the “native” way to extend SeAT 👍 The main constraint for me is just skillset + time — I’m very comfortable on the frontend / data / JS side of things, but PHP/Laravel plugin development would be a pretty big ramp-up. I’m not trying to avoid doing the work, just trying to do it in a way where I can actually ship something useful without spending months learning a new stack. For my use case, a read-only DB / API / export approach lets me focus on building the dashboards and insights I’m excited about, while keeping SeAT untouched and safe. Huge respect for what you’ve built already — I’m just approaching the problem from a slightly different angle 😄

I think my main point is just this: PHP/Laravel plugins naturally limit contributors to a specific skillset, while API-style access opens the door to a much wider group of devs (JS, Python, data people, frontend folks, etc.) who could build tooling around SeAT without touching its core.

Not gonna lie.. I've had amazing success creating plugins using claud flexing on my c/go/rust knowledge and a bit of js to guide it into things

I've also not been shy about writing addon services in go that dig directly into the db

Read from db, write to api

I also have grafana hooked directly into the seatdb for querying

I'm currently clauding a re-imagining of how the team speak connector works

The one problem I had with APIs is that the features are limited within its design, but every groups want their own filtering and aggregation rules. In the end I give up and just plugged some business intelligence / data visualization platform on top of seat database

With that being said, to extend features when an API is present still likely to require some mods into backend, and thus Laravel/PHP stuff.

In the end there is API platform within SeAT itself, but I don't see lots of good use around it

Probably something like PostgREST is needed, like how Supabase present stuffs, but that way we are literally writing a painful SQL synonym

Unless you want to do aggregations in frontend. Thats a whole another can of worms...

Yeah, that’s a fair point — a generic “query anything” API usually ends up being too limiting or too complex for everyone’s different needs. My goal isn’t really to build a universal data API for all use cases, though. I’m more thinking in terms of a small set of opinionated, read-only “report” endpoints that return exactly the aggregates my dashboards need (mining, members, systems, etc.). If a new insight requires a new aggregation, I’m totally fine with adding a new endpoint for it — that’s just part of evolving the tool. For my scope (corp dashboards + insights), that feels simpler and more maintainable than trying to expose the entire DB or support arbitrary filtering/aggregation from the frontend.

https://discord.com/channels/821361165791133716/1460228550182309981/1460292258518663279 apparently this wont work for what you want..

I think there may have been a small misunderstanding there 🙂 I’m not locked into one specific implementation approach. For what I want to build, there are a few viable options that don’t require deep Laravel/UI plugin work: • Running scripts against local DB backups to generate the data I need • A simple read-only DB → API bridge in whatever tech stack • Or a minimal SeAT API package that just returns JSON (no UI, no auth, no views) My main point was really about flexibility of how the data can be consumed, not a rejection of SeAT’s ecosystem. The goal stays the same: surface useful insights from the existing data, without touching SeAT’s core or recreating its web UI.

That's it; I highly suspect that you can do enough flexibility without touching Laravel

POC done ✅ All mining sections are built now. I went with option 1 (local scripts over DB backups) – simplest path, no SeAT core changes, full control over the aggregates. What’s left is just backfilling older data and wiring proper navigation inside page section. After that it’s basically production-ready. Definitely a journey getting from raw DB → usable dashboards, but the approach feels good now.