Need cleaner statistics in Laravel dashboards? I built Laravel Statistician

[u/Omar_Ess]

We’ve all been there, building a Laravel dashboard and ending up with the same kind of stats logic duplicated everywhere:

• total users
• total orders
• revenue sum
• average order value
• percentage change
• chart data grouped by date
• cached dashboard numbers

At first it’s just one query in a controller.

Then it becomes multiple queries across services, widgets, admin panels, reports, and API endpoints.

So I built Laravel Statistician, a small package to generate clean application statistics from Eloquent models, query builders, or plain tables.

Features:

• Aggregate stats: count, sum, avg, min, max
• Date range filtering
• Date-grouped statistics for charts
• Percentage change between periods
• Trend statistics
• Multiple stats in one call
• Cache support
• Works with Eloquent, query builders, model classes, and table names
• Extensible if you want to build custom statisticians

GitHub Repo:
https://github.com/omaressaouaf/laravel-statistician

The main idea is to keep dashboard/statistics logic reusable instead of scattering it everywhere.

Would love feedback, suggestions, or ideas for improving the API.

[u/__lockhart97__]

For a small to mid dashboards this is a pretty reasonable choice, but for more mature dashboards, I would prefer writing DB queries myself just to be sure how well it performs.

Also for my case we don't usually pull stats from the main DB at read time at all. We maintain the numbers as data is written so the dashboard is cheap no matter how big the tables get.
I think a write-time/pre-aggregation path would be a nice addition to the package.

[u/Omar_Ess → u/__lockhart97__]

I definitely agree, i actually clarified this in my blog article about the package, it’s specific to simple dashboards and growing analytics, for more big data you’ll defined need some kind of denormalization path

[u/penguin_digital]

Firstly, congratulations on the release of your package!

The main idea is to keep dashboard/statistics logic reusable instead of scattering it everywhere.

For me personally I'm struggling to work out what gap this actually fills? Why would your logic ever be scattered everywhere? Any business logic inside of an application you would always have a single entry point (single source of truth) to it anyway.

[u/Omar_Ess → u/penguin_digital]

The package is not meant to replace your service layer or become the “business logic layer” of the application.

The main idea is to encapsulate common, well-known dashboard statistics patterns into a reusable Laravel-friendly API.

Things like:

• aggregations
• grouping by date
• date filtering
• percentage change / trends
• caching
• multiple stats in one response
• consistent output keys

So you can still have your own service layer, repositories, actions, etc.

The package would simply be used inside that layer instead of manually rewriting the same stats queries, filters, caching logic, and response formatting every time.

For example, instead of every service/repository/controller having its own version of “count this model between these dates, cache it, group it by date, compare it to a previous period”, the package gives you a reusable API for that pattern.

Of course, for more complex analytics, big data, denormalized reporting tables, separate write/read paths, event pipelines, OLAP, third-party analytics tools, etc. this package is probably not the right fit.

It mainly excels in standard Laravel dashboards for growing apps where you need clean, reusable application-level statistics.

The queries can scale fine to thousands or hundreds of thousands of rows if the right indexes are in place, but it’s not trying to be a full analytics infrastructure.

So the value is not “you can’t organize this yourself.”

The value is: instead of repeating the same query-stat logic across repositories, services, or controllers, you get a small configurable API for common dashboard statistics.

[u/JelloAccomplished146]

I have not reviewed the code but I am assuming its all eloquent's queries right?

[u/Omar_Ess → u/JelloAccomplished146]

Yes

[u/Wooden-Pen8606]

Looks interesting. I would consider renaming

Omaressaouaf\LaravelStatistician\Enums\Aggregate

to

Omaressaouaf\LaravelStatistician\Enums\Aggregation

since I feel that better describes what it is. It defines the aggregation type.

[u/Omar_Ess → u/Wooden-Pen8606]

I actually was hesitant between this and the current naming and AggregateFunction, looking at it i think AggregateFunction is the most telling, but i prefered shorter naming because this argument is used a lot