full-stack-fastapi-template's HTTP client layer carries the highest activity risk — 2 functions to address first

Two anonymous functions in frontend/src/client/core/request.ts and SidebarProvider in sidebar.tsx dominate the critical band, combining structural complexity with heavy recent commit activity across 545 analyzed functions.

Stephen Collins ·
oss typescript refactoring code-health

Antipatterns Detected

god_function3long_function2complex_branching1deeply_nested1exit_heavy1

Key Points

What is a god function and why does it matter in full-stack-fastapi-template?

A god function is one that has taken on too many responsibilities — in this template, SidebarProvider and ThemeProvider both carry the pattern, with fan-out values of 19 and 14 respectively, meaning they call into a large number of other functions and become central coordination points. When a god function changes, the ripple effects are wide and hard to predict, making every commit to it disproportionately risky. In a template that developers fork and extend, god functions also become the hardest parts to safely customize without breaking unrelated behavior.

How do I reduce fan-out in TypeScript?

Identify clusters of callees that share a single responsibility and extract them into focused custom hooks or helper modules, then have the original function depend only on those higher-level abstractions rather than calling each dependency directly — this reduces the number of distinct functions any one unit coordinates and makes each piece independently testable.

Is full-stack-fastapi-template actively maintained?

The activity data strongly suggests yes — the top two functions both carry recent commit activity levels above 9, placing them in the critical band, which requires sustained commit frequency against already-complex code to score that high. The HTTP client and sidebar layers in particular show the kind of churn consistent with active feature development or ongoing refinement.

How do I reproduce this analysis?

Run the Hotspots CLI against the full-stack-fastapi-template repository at commit fbaf2db to reproduce these exact scores and band assignments.

What does activity-weighted risk mean?

Complexity × recent commit frequency — functions that are hard to understand AND actively changing are the highest priority for refactoring.

Across 545 analyzed functions in full-stack-fastapi-template — a production-ready FastAPI + React scaffold used as a starting point for full-stack applications — the HTTP client layer is the highest-priority refactoring target: the top anonymous function in frontend/src/client/core/request.ts holds a recent commit activity of 10.15, meaning it is not merely complex but is being actively changed right now, which converts structural risk into live regression exposure. Only 2 functions reached the critical band, but they sit in different layers — the API request pipeline and the UI component tree — suggesting that churn is distributed across the stack. The combination of god_function patterns, deep nesting, and high fan-out across the top five hotspots points to coupling pressure that will compound as the template evolves.

The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).

Top 5 Hotspots

FunctionFileRiskCCNDFO
<anonymous>frontend/src/client/core/request.ts10.615511
SidebarProviderfrontend/src/components/ui/sidebar.tsx9.95119
cancelfrontend/src/client/core/CancelablePromise.ts8.91232
<anonymous>frontend/src/client/core/request.ts8.711313
ThemeProviderfrontend/src/components/theme-provider.tsx8.74114

Hotspot Analysis

<anonymous> — frontend/src/client/core/request.ts

This anonymous function sits inside the core HTTP request module and almost certainly handles the main fetch/XHR dispatch logic — request construction, header injection, error branching, and response normalization are all typical responsibilities at this path. Its cyclomatic complexity of 15 means at least 15 independent execution paths must be reasoned about and tested, while a max nesting depth of 5 makes those paths difficult to trace visually. A fan-out of 11 distinct callees combined with a recent commit activity of 10.15 — the highest in the repository — means every commit touching this function risks breaking one or more of those downstream dependencies under conditions that are hard to reproduce without exhaustive test coverage.

Recommendation: Add characterization tests covering the 15 execution paths before making any further changes, then extract distinct concerns (auth header injection, error classification, response parsing) into named helper functions to reduce both CC and fan-out to individually testable units.

SidebarProvider — frontend/src/components/ui/sidebar.tsx

SidebarProvider is a React context provider responsible for managing sidebar state and distributing it to the component subtree — a role that naturally accumulates responsibilities as the UI grows. Its cyclomatic complexity of 5 is moderate, but its fan-out of 19 is the structural signal to focus on: 19 distinct functions called from a single provider means changes here carry an unusually wide blast radius across the component layer. The god_function and long_function patterns confirm that this provider has absorbed concerns beyond state distribution, and exit_heavy indicates it manages multiple return paths through its lifecycle logic. A recent commit activity of 9.48 places it firmly in the critical band, meaning that blast radius is being exercised regularly.

Recommendation: Audit the 19 callees to identify which responsibilities belong in sub-providers or custom hooks, then extract those concerns to reduce fan-out and limit the blast radius of future sidebar-related changes.

cancel — frontend/src/client/core/CancelablePromise.ts

The cancel function in CancelablePromise.ts manages the lifecycle termination of in-flight HTTP requests — canceling pending promises typically requires coordinating state flags, resolving or rejecting deferred values, and cleaning up listeners, all of which produce branching logic. A cyclomatic complexity of 12 and max nesting depth of 3 confirm that the cancellation logic is non-trivial, with 12 paths that each represent a scenario where partial cleanup or incorrect state transition could silently corrupt request state. With a recent commit activity of 8.45 in the high band, this function is being touched frequently enough that its 12-path surface area is a recurring regression risk in the request pipeline.

Recommendation: Map out the 12 execution paths as explicit unit tests covering edge cases such as double-cancellation and cancellation after resolution, then evaluate whether the branching can be reduced by modeling promise states as an explicit state machine.

Patterns Found

Antipatterns detected across the top functions in this snapshot:

PatternOccurrences
god_function3
long_function2
complex_branching1
deeply_nested1
exit_heavy1

These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.

Key Takeaways

  • The anonymous function in frontend/src/client/core/request.ts has a recent commit activity of 10.15 and cyclomatic complexity of 15 — write characterization tests covering all 15 paths before the next commit touches it.
  • SidebarProvider’s fan-out of 19 is the widest in the top hotspots; decompose it into focused sub-providers or hooks to contain the blast radius of UI-layer changes.
  • The cancel function in CancelablePromise.ts has 12 cyclomatic complexity paths and is actively changing — model its promise lifecycle states explicitly to prevent silent regressions in request teardown.

Reproduce This Analysis

git clone https://github.com/fastapi/full-stack-fastapi-template
cd full-stack-fastapi-template
git checkout fbaf2dbe9d35a53cc74a60d6538a3bf17adc4857
hotspots analyze . --mode snapshot --explain-patterns --force

To run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.

Hotspots highlights structural and activity risk — not “bad code.” Findings are a prioritization aid, not a bug predictor. Editorial policy →

Run this on your own codebase

Hotspots runs locally in under a minute — no account, no data leaves your machine.

macOS
$ brew install Stephen-Collins-tech/tap/hotspots
Linux / cargo
$ cargo install hotspots-cli
Run in any repo
$ hotspots analyze .
★ Star on GitHub

Related Analyses