Fasq in the Ecosystem

Unlike general-purpose state managers (Riverpod, Bloc, Provider) which aim to solve all state needs, Fasq is a specialized server-state manager.

Role: Complementary vs. Competitive

• Vs. General State Managers: Fasq is complementary. It is designed to handle the “messy” parts of async data (caching, invalidation, deduplication) so your global state managers can focus on business logic.
• Vs. Manual API Handling: Fasq is competitive. It replaces the boilerplate of manually fetching, loading, and storing API responses in custom classes.

The State Spectrum

To understand where Fasq fits, it’s helpful to categorize different types of state:

Technical Comparison (Vs. General State Managers)

Paradigm Differences

Feature Comparison

When to Use Which?

Use a General State Manager (Riverpod/Bloc) when:

• You are managing complex UI flows or state machines.
• You have highly reactive, client-side derived state.
• You need a single centralized store for the entire app’s logic.
• You require 100% stable, community-vetted tools with extensive DevTools support.

Use Fasq when:

• Your app is heavily data-driven from multiple API endpoints.
• You want to eliminate the “loading-success-error” boilerplate for every fetch.
• You need sophisticated caching, background refetching, and request deduplication.
• You want to separate “Server Data” from “App Business Logic”.
• You need enterprise-grade resilience features (Circuit Breakers, Security).

Use Both (Recommended) when:

• You use Fasq for the data-fetching layer and Bloc/Riverpod for cross-cutting app logic (auth, navigation) and complex feature flows.

Architectural Comparison: Fetching User Data

Theoretical comparison of implementation costs

Ecosystem Maturity

Fasq is a younger package compared to industry giants.

[!NOTE] The FASQ adapter packages (fasq_bloc, fasq_riverpod, etc.) are currently in an experimental state. They are intended to help bridge the gap for teams who want the caching power of Fasq while staying within their chosen state management architecture.

Comparison & Ecosystem Roles

Fasq occupies a specific niche in the Flutter state management landscape. This page helps you understand the architectural role of Fasq compared to other popular solutions.

At a Glance

Comparison: Fasq vs Other Query Packages

Packages like flutter_tanstack_query, fquery, and fl_query are excellent libraries that brought the “Query” paradigm to Flutter. Here’s how Fasq distinguishes itself:

1. Enterprise-Grade Features 🛡️

Fasq is built with complex, large-scale applications in mind.

• Circuit Breakers: Built-in support to prevent cascading failures when APIs are down. Service unavailability is handled gracefully without custom logic.
• Security Plugin: fasq_security offers encrypted storage and automatic clearing of sensitive data on app backgrounding—critical for fintech and healthcare apps.
• Performance Tuning: Explicit controls for Isolate usage and hotCache to ensure heavy data transformations don’t block the UI thread.

2. Architecture Agnostic 🤝

While some packages are heavily tied to flutter_hooks or their own widget ecosystem, Fasq provides first-party adapters:

• fasq_bloc: Integrate queries directly into your Blocs.
• fasq_riverpod: Use queries as Providers.
• fasq_hooks: Use useQuery if you love hooks.
• Pure Dart: Run queries in pure Dart code (CLI, background services) without Flutter dependencies.

3. Developer Experience 🛠️

• Type Safety: Strict typing avoids dynamic guessing games.
• Global Observers: Powerful QueryClientObserver pattern for centralized logging, analytics, and error reporting, rather than just simple callbacks.

Feature Matrix

Future Roadmap & Community

We are actively evolving Fasq. Our goal is to identify what’s missing in current solutions and bridge those gaps. We are constantly researching, iterating, and looking for feedback to make Fasq the most robust server-state manager for Flutter. If you find a feature missing or have a specific use case, please open an issue!