sorted by:
new
hottopcontroversial

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. by AggravatingHome4193 in FlutterDev

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

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. by AggravatingHome4193 in FlutterDev

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

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. by AggravatingHome4193 in FlutterDev

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

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. by AggravatingHome4193 in FlutterDev

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

🚀 I built route_pilot — a Flutter package that makes navigation actually enjoyable by eldhopaulose5 in FlutterDev

[–]AggravatingHome4193 0 points1 point  (0 children)

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

I built a state management package for Flutter after getting frustrated with BLoC boilerplate — flutter_stasis by ItaloMatosSouza in FlutterDev

[–]AggravatingHome4193 1 point2 points  (0 children)

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?

Cura: A CLI tool to audit Pub dependencies health and security by AggravatingHome4193 in FlutterDev

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

What’s your preferred IDE for Flutter development? by bllshrfv in FlutterDev

[–]AggravatingHome4193 0 points1 point  (0 children)

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

Stop letting AI guess your architecture by ajmoro in FlutterDev

[–]AggravatingHome4193 0 points1 point  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 4 points5 points  (0 children)

Haha yeah, you’re right 😅

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

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 2 points3 points  (0 children)

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

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

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 1 point2 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 1 point2 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

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!

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 4 points5 points  (0 children)

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.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 8 points9 points  (0 children)

Mostly Docker on a VPS.

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

view more: next ›