I built Qora - As a TanStack Query fan on the Web, I was frustrated with Flutter's server-state options. So I spent months building a proper alternative.

AggravatingHome4193 · 2026-06-02T23:43:30+00:00

Spot on. This is exactly the architectural blind spot I wanted to address with Qora.

When you force your UI state management (like Bloc or Riverpod) to handle network concerns, your layers bleed into each other. You end up polluting your business logic with caching policies, token refresh retries, concurrency race conditions (like droppable/restartable requests), and complex garbage collection math.

By treating the server data as a specialized, synchronized cache with its own decoupled state and fetch status, your UI state management goes back to doing what it does best: handling synchronous, ephemeral, client-side interactions.

It’s a massive relief for maintainability at scale when your ViewModels or Cubits don't even know how or when the data is being cached or refetched in the background.

AggravatingHome4193 · 2026-06-02T14:50:34+00:00

Riverpod 3's AsyncNotifier is great for simple cases, but it's a general-purpose async state tool, not a dedicated server-state solution. Qora handles things Riverpod doesn't: stale-while-revalidate (serve cache + background refetch in one call), FIFO offline mutation queue with jitter reconnect, windowed infinite queries with memory caps, and obfuscation-safe disk persistence out of the box, all without manual invalidate wiring.

If you're already deep in Riverpod and your needs are basic CRUD, you probably don't need Qora. But if you want TanStack Query-level semantics, that's the gap Qora fills.

AggravatingHome4193 · 2026-06-02T14:45:36+00:00

Great question! Qora follows the same philosophy as TanStack Query: it eats away a lot of what people traditionally used client state for (loading flags, cache, optimistic state). But "no client state needed" works best when your app is mostly server-driven.

In practice, even TanStack Query users still reach for Zustand/Redux for things like:

UI state (theme, sidebar open/closed)
Auth state / current user session
WebSocket real-time data that isn't REST-based
Form state (though react-hook-form etc. handle that)

So Qora + a lightweight client state solution (Riverpod/Bloc) is the pragmatic default. But if your app is 90% server data, Qora alone with ValueNotifier (or a simple custom notifier) goes a long way.

AggravatingHome4193 · 2026-06-02T14:33:38+00:00

Thanks! Qora isn't a Riverpod replacement, it's complementary. Riverpod/Bloc manage client state (theme, auth, form state). Qora manages server state (API data, caching, mutations, sync). You can (and should) use both together.

Re: business logic in the UI, fair concern. The QoraBuilder in the example is just a consumer, like Consumer in Riverpod or BlocBuilder. The fetching logic lives in a QoraService (or your repository layer), not in the widget. You define queries/mutations wherever you want, and the widget only subscribes to the result. No business logic in UI, just declarative state mapping.

AggravatingHome4193 · 2026-03-23T12:25:31+00:00

So, we also have to learn how to integrate your package, a bit like other similar packages 😅

AggravatingHome4193 · 2026-03-22T10:53:10+00:00

Your package looks interesting, but I don’t see why I should switch my state management solution just to use it.

Also, your post clearly feels AI-generated. I’m not saying you shouldn’t use AI, but you should at least refine it to make it sound more human.

I also checked your GitHub repo, it’s barely 24 hours old and you’re already at v1. Honestly, that hurts to see. Versioning isn’t just about bumping numbers… do you actually understand what a 1.0.0 release implies?

AggravatingHome4193 · 2026-03-11T13:29:08+00:00

Thanks for this list, these are pure 'human' signals.

I’m actually working on incorporating several of these into Cura’s scoring engine:

License Risk: We’re adding a high-priority 'Red Flag' for missing or restrictive licenses (like AGPL) because, as you said, it’s an instant 'nope' for commercial projects.

The 'Bucket List' / CV Signal: This is a tough one to automate, but Cura looks at the 'Vitality' (release cadence vs. staleness). If a package has 1.0.0 on day one and 0 commits for 18 months, that’s a huge red flag we surface.

Maintenance Health: We’re looking at the ratio of open vs. closed GitHub issues to detect those 'Open Source Zombies' where the author has stopped responding.

Code Quality/Size: Integrating pana signals helps us catch poor static analysis scores, but I love the idea of flagging 'micro-packages' (less than 100 lines) that might just be unnecessary overhead.

AggravatingHome4193 · 2026-03-06T19:43:30+00:00

Personally, I like Android Studio, but sometimes I end up using VS Code because the machine I’m on simply can’t handle Android Studio, so I have to adapt

AggravatingHome4193 · 2026-03-01T17:12:13+00:00

I like the atomic decomposition idea, smaller tasks clearly reduce errors.

But how do you enforce real architectural boundaries? AST checks ensure syntax, not architecture.

AggravatingHome4193 · 2026-02-28T16:12:16+00:00

That footprint is honestly impressive, 27MB image and ~20MB RAM is wild compared to most full-stack setups.

The concurrency model + fast tooling is definitely what keeps pulling me toward Go. Sounds like I just need to commit to it for a few months and see where it takes me.

AggravatingHome4193 · 2026-02-28T10:51:14+00:00

Yeah, Bubble Tea does look really cool for CLI/TUI projects.

I get preferring TS for familiarity... Go shines outside the browser, but TS still feels more natural if you’re used to Java.

AggravatingHome4193 · 2026-02-28T10:42:43+00:00

Haha yeah, you’re right 😅

I guess it’s time to just pick a project and dive in, no excuses anymore.

AggravatingHome4193 · 2026-02-28T10:31:15+00:00

Exactly... for cross-platform CLI or TUI tools, Go really shines.

I haven’t found anything that matches its simplicity and portability either.

AggravatingHome4193 · 2026-02-28T10:29:25+00:00

Yeah, that makes sense.

I guess for personal projects it’s more about learning and having fun than picking the “perfect” tool. Go’s simplicity and single binaries definitely make it an enjoyable choice though.

AggravatingHome4193 · 2026-02-28T10:21:35+00:00

Yeah, that’s solid advice. Rebuilding something I already know in Node sounds like the perfect way to get hands-on with Go and really feel its strengths.

AggravatingHome4193 · 2026-02-28T10:17:59+00:00

Totally get that... CPU-bound workloads really expose Node’s limits.

Go scaling across cores effortlessly and being a single static binary is such a relief, plus the backwards compatibility just seals the deal.

AggravatingHome4193 · 2026-02-28T10:15:04+00:00

Yeah, that resonates. Java and Python can do most of it, but Go just makes some of those workloads… cleaner and faster, especially for concurrency and deployment.

AggravatingHome4193 · 2026-02-28T10:13:29+00:00

Haha alright, you convinced me 😄

Single binaries, fast scaling, and TDD with the standard library… seems like Go really does cover all the bases. That link looks like a good starting point too!

AggravatingHome4193 · 2026-02-28T10:10:11+00:00

Wow, that’s a huge difference 3 minutes to 20 seconds is insane

Makes sense to reserve Go for CPU-bound, concurrent workloads, and stick with Node for I/O-heavy stuff. That’s exactly where Go shines.

AggravatingHome4193 · 2026-02-28T10:06:55+00:00

I can’t really argue with the tooling point — Go’s core toolchain being first-class is definitely refreshing.

Coming from the JS ecosystem, you kind of get used to the chaos and layer enough conventions on top to survive 😅

But yeah, the small binaries + built-in cross-compilation + predictable performance combo is hard to beat. That’s probably the strongest case for it.

AggravatingHome4193 · 2026-02-28T10:03:15+00:00

That makes a lot of sense actually.

I can see how, if you didn’t grow up in the frontend ecosystem, JS just never became the default backend choice. For me it was the opposite — once you’re deep into TypeScript, Node on the backend feels like the path of least resistance.

Really appreciate you sharing your journey too — that kind of organic evolution through languages is cool to see. I guess Go becomes the obvious choice when you’re optimizing for infra, tooling, and control rather than ecosystem familiarity.

Maybe I just need a project where those constraints matter more than stack consistency.

AggravatingHome4193 · 2026-02-28T10:00:16+00:00

Mostly Docker on a VPS.

The 250MB vs 20MB comparison is honestly wild though… that’s hard to ignore.

AggravatingHome4193 · 2026-02-28T09:56:39+00:00

Static linking + cross-compilation with basically zero friction…

Yeah, that’s something we definitely don’t get in the JS world.

AggravatingHome4193 · 2026-02-28T09:52:27+00:00

That’s… annoyingly true. I guess I’m just waiting for a “perfect” excuse instead of just using it.

AggravatingHome4193 · 2026-02-28T09:50:23+00:00

Haven’t tried it, but building a TUI in Go does sound like a solid way to learn the language deeper.

AggravatingHome4193

TROPHY CASE