DEV Community: marco menegazzi

Why I Built an HTTP Client That Doesn't Try to Be Smart

marco menegazzi — Tue, 12 Aug 2025 21:07:37 +0000

Sometimes the best solution is the one that doesn't reinvent the wheel

I just released rq, an HTTP client that might be different from what you're used to. Instead of building another GUI tool or inventing new syntax, I went the opposite direction: what if we just used HTTP syntax as-is?

The Problem: Too Many Abstractions

Let's be honest about existing HTTP clients:

Postman - Great features, but it's a heavy GUI that wants to own your entire workflow. Plus, good luck using it over SSH or in a CI pipeline.

Bruno - File-based approach (love it!), but why this custom syntax?

meta {
  name: Login
  type: http
}

post {
  url: {{host}}/login
  body: json
}

httpYac - Uses standard .http files (perfect!), but no workspace organization.

HTTPie - Beautiful CLI syntax, but no persistence or project structure.

Each tool solves some problems while creating new ones. But here's the thing: HTTP syntax is already perfect. It's been around for decades, it's human-readable, and every developer knows it.

So why are we reinventing it?

My Solution: Raw HTTP + Smart Organization

rq uses actual HTTP syntax with workspace organization:

POST {{BASE_URL}}/api/login HTTP/1.1
Content-Type: application/json
Authorization: Bearer {{API_TOKEN}}

{
  "username": "{{USERNAME}}",
  "password": "{{PASSWORD}}"
}

That's it. No custom syntax to learn. No abstractions. Just HTTP.

How It Works

1. Docks (Workspaces)

Think of docks like project folders for your API requests:

rq dock init my-api     # Creates workspace
cd my-api/

2. Raw HTTP Files

Write requests in standard HTTP syntax:

rq new login           # Creates login.http

Edit login.http:

POST {{BASE_URL}}/auth/login HTTP/1.1
Content-Type: application/json

{"email": "{{EMAIL}}", "password": "{{PASSWORD}}"}

3. Environment Configuration

Simple key-value files (like .env):

echo "BASE_URL=https://api.example.com" > env
echo "EMAIL=user@example.com" >> env
echo "PASSWORD=secret123" >> env

4. Run Requests

rq run login           # Executes the request

The Magic: Hierarchical Configuration

Here's where it gets interesting. You can organize requests in folders with inherited config:

my-api/
├── env                 # Global config
├── login.http
├── auth/
│   ├── env            # Auth-specific config (inherits + overrides)
│   ├── signup.http
│   └── oauth/
│       ├── env        # OAuth config (inherits from auth + global)
│       └── token.http
└── users/
    ├── list.http
    └── create.http

Each level inherits configuration from above and can override specific values. Just like CSS cascading, but for API requests.

Smart Variables

Variables aren't just simple substitution:

POST {{BASE_URL}}/upload HTTP/1.1
Content-Type: multipart/form-data

{
  "file": "{{file(document.pdf)}}",
  "checksum": "{{sha256(document.pdf)}}",
  "timestamp": "{{timestamp()}}",
  "id": "{{uuid()}}"
}

Functions handle common tasks:

{{file(path)}} - reads and base64-encodes files
{{sha256(data)}} - computes hashes
{{uuid()}} - generates UUIDs
{{timestamp()}} - current timestamp

Environment Management

Multiple environments are first-class:

# env (default)
BASE_URL=http://localhost:3000
DEBUG=true

# env.staging  
BASE_URL=https://staging-api.example.com
DEBUG=false

# env.prod
BASE_URL=https://api.example.com  
DEBUG=false
LOG_LEVEL=error

Run with specific environments:

rq run login --env staging
rq run users/create --env prod

Auto-Discovery

Just specify the request name:

rq run login           # Finds login.http automatically

If multiple protocols exist:

auth/
├── login.http         # HTTP request
├── login.ws           # WebSocket (future)
└── login.grpc         # gRPC (planned)

rq will prompt you to choose or you can specify explicitly:

rq run login.ws        # Force WebSocket

Why This Approach Works

Version Control Native

git add api-requests/
git commit -m "Add user authentication flow"

Your API tests live with your code, not in some external tool.

Project Integration

my-project/
├── src/
├── tests/
└── api-dock/          # API requests as part of the project
    ├── env
    └── *.http

CI/CD Ready

# GitHub Actions
- name: Test API endpoints
  run: |
    rq dock use api-tests
    rq run health --env staging
    rq run auth/login --env staging

Zero Learning Curve

If you know HTTP, you know rq. No custom syntax, no abstractions.

Fast

Terminal tools start instantly. No waiting for Electron apps to load.

Protocol Agnostic Future

File extensions determine protocols:

.http - HTTP requests
.ws - WebSocket connections (planned)
.grpc - gRPC calls (planned)
.graphql - GraphQL queries (planned)

Same workspace, same variable system, different protocols.

Getting Started

# Install (replace with your platform)
curl -L https://github.com/username/rq/releases/latest/download/rq-linux -o rq
chmod +x rq

# Try it out
./rq dock init test-api
cd test-api/
./rq new hello
echo "GET https://httpbin.org/get HTTP/1.1" > hello.http
./rq run hello

Code Examples

Basic API Testing

# users.http
GET {{BASE_URL}}/api/users?page={{PAGE}} HTTP/1.1
Authorization: Bearer {{JWT_TOKEN}}
Accept: application/json

File Upload

# upload.http  
POST {{BASE_URL}}/api/files HTTP/1.1
Authorization: Bearer {{JWT_TOKEN}}
Content-Type: multipart/form-data

{
  "name": "{{FILENAME}}",
  "data": "{{file(./uploads/document.pdf)}}",
  "hash": "{{sha256(./uploads/document.pdf)}}"
}

Authentication Flow

# auth/login.http
POST {{AUTH_URL}}/login HTTP/1.1
Content-Type: application/json

{
  "email": "{{EMAIL}}",
  "password": "{{PASSWORD}}"
}

With auth/env:

AUTH_URL={{BASE_URL}}/auth
EMAIL=admin@example.com
PASSWORD=admin123

What's Next

WebSocket support (.ws files)
gRPC integration (.grpc files)
Test assertions and validation
Response templating and extraction
Plugin system for custom functions

Try It Out

GitHub: https://github.com/marcomit/rq

# Quick start
curl -L https://github.com/marcomit/rq/releases/latest/download/rq-linux -o rq
chmod +x rq
./rq dock init my-test

The tool is built with Go, works on all platforms, and has zero dependencies.

Discussion

What do you think? Is this approach too simple, or is simplicity exactly what we need?

I'd love to hear your thoughts:

What HTTP client do you currently use and why?
What frustrates you most about API testing tools?
Would you try a tool like this in your workflow?

Your Flutter Logging Strategy is Embarrassing (Here's How to Fix It)

marco menegazzi — Tue, 05 Aug 2025 17:18:15 +0000

The Current State of Flutter Logging (It's Bad)

I reviewed 50+ Flutter projects on GitHub last week. Want to know what I found? Every single one was using print() statements as their primary debugging strategy.

Here's what "professional" Flutter logging looks like in 2025:

void handlePayment(double amount) {
  print('Processing payment: \$${amount}');

  try {
    final result = processPayment(amount);
    print('Payment successful!');
  } catch (e) {
    print('Error: $e'); // Good luck finding this in prod
  }
}

If this looks familiar, you're part of the problem.

Why print() is Sabotaging Your Career

1. Production Invisibility

Your print() statements disappear the moment you deploy. When your app crashes at 3 AM and your manager is asking questions, those debug prints won't save you.

2. Performance Killer

Every print() call blocks the UI thread. You're literally making your app slower with every forgotten debug statement.

3. Zero Organization

Everything dumps to the same console. Finding relevant logs is like finding a specific grain of sand on a beach.

4. Memory Waste

Those string interpolations create objects that need garbage collection, even when logging is disabled.

5. Amateur Hour

Nothing screams "junior developer" like production code full of print() statements.

Building a Real Logging System

When I built the logging system for Mosaic, I didn't just wrap print() in a class. I engineered a production-ready system that handles real-world requirements.

Multi-Destination Logging

Different logs need different destinations:

await logger.init(
  dispatchers: [
    ConsoleDispatcher(),           // Dev debugging
    FileLoggerDispatcher(),        // Persistent logs  
    RemoteLogDispatcher(),         // Production monitoring
    SlackDispatcher(),             // Critical alerts
  ],
);

When network fails, file logging continues. When disk fills up, remote logging keeps working.

Hierarchical Level System

Stop thinking binary (log or don't). Use levels:

// Development: Everything
logger.setLogLevel(LogLevel.debug);

// Staging: Skip noise
logger.setLogLevel(LogLevel.info);

// Production: Problems only
logger.setLogLevel(LogLevel.warning);

Level filtering happens before processing, so higher levels = better performance.

Tag-Based Organization

Organize logs by context, not chaos:

logger.info('Login successful', ['auth', 'user_$id']);
logger.warning('Slow API: ${ms}ms', ['api', 'performance']);  
logger.error('DB connection lost', ['database', 'critical']);

Now you can filter by component, user, or severity without parsing garbage.

Thread Safety That Actually Works

Most logging libraries aren't actually thread-safe. Multiple async operations logging simultaneously = corrupted output or race conditions.

My solution uses semaphore-based locking:

class ConsoleDispatcher extends LoggerDispatcher {
  final _semaphore = Semaphore();

  @override
  Future<void> log(String message, LogType type, List<String> tags) async {
    try {
      await _semaphore.lock();
      debugPrint(message); // Actually thread-safe now
    } finally {
      _semaphore.release();
    }
  }
}

Every dispatcher operation is mutex-protected. No more corrupted logs. You can also create your own dispatcher.

Rate Limiting Prevents Log Flooding

Your app hits an error loop and generates 50,000 logs per second. Congratulations, you just DoS'd yourself.

Real logging has rate limiting:

final _rateLimiter = RateLimiter(
  window: Duration(seconds: 1),
  maxRate: 1000,
);

if (_rateLimiter.exceeded()) {
  debugPrint('Rate limit hit, dropping message');
  return;
}

Protects performance while ensuring legitimate messages get through.

Async Processing Without Pain

Every log operation is async to avoid UI blocking:

Future<void> _dispatch(String message, LogType type, List<String> tags) async {
  await Future.microtask(() async {
    await Future.wait(
      _dispatchers.values.map((d) => _safeDispatch(d, message, type, tags)),
    );
  });
}

But here's the key—bulletproof error handling:

Future<void> _safeDispatch(LoggerDispatcher dispatcher, ...) async {
  try {
    await dispatcher.log(message, type, tags)
        .timeout(Duration(seconds: 5));
  } catch (e) {
    debugPrint('Dispatcher ${dispatcher.name} failed: $e');

    // Auto-disable broken dispatchers
    if (e is TimeoutException || e is IOException) {
      dispatcher.active = false;
    }
  }
}

When dispatchers fail, logging continues. When network times out, file logging keeps working.

The Loggable Mixin

Instead of dependency injection everywhere, use a mixin with automatic context:

class PaymentService with Loggable {
  @override
  List<String> get loggerTags => ['payment'];
  // Each log has this tag by default

  Future<void> processPayment(double amount) async {
    info('Processing payment: \$${amount}'); // Auto-tagged

    try {
      await _stripe.charge(amount);
      info('Payment successful');
    } catch (e) {
      error('Payment failed: $e'); // Stands out as critical
      rethrow;
    }
  }
}

Every message automatically includes class context. DRY, clean, scalable.

Memory Management That Won't Leak

Proper cleanup prevents production memory leaks:

Future<void> dispose() async {
  if (_disposed) return;
  _disposed = true;

  // Clean up all dispatchers
  await Future.wait(
    _dispatchers.values.map((d) => d.dispose().catchError((_) {})),
  );

  // Clear all collections
  _dispatchers.clear();
  _defaultTags.clear();
  _tags.clear();
}

Every resource tracked and cleaned up. No leaks, no surprises.

Stop Embarrassing Yourself

While you're debugging with print() like it's 1995, professional developers use logging systems that actually work in production.

Systems with:

Proper level filtering
Tag-based organization
Thread safety
Rate limiting
Error recovery
Memory management

The complete logging implementation is available in the Mosaic framework along with modular architecture, thread-safe utilities, and other tools that separate professionals from hobbyists.

dependencies:
  mosaic: ^0.0.3

Your future self (and your team) will thank you.

What's your biggest logging pain point? Drop a comment and let's discuss how to solve it properly.

Mosaic: The Flutter Architecture That Makes Provider, BLoC, and GetX Look Like Amateur Hour

marco menegazzi — Wed, 30 Jul 2025 18:39:03 +0000

How I replaced an entire ecosystem of conflicting packages with one coherent system

Most Flutter developers are building apps wrong. Monolithic architectures, tight coupling, hours-long builds — it's amateur hour.

I solved this. Mosaic is what happens when you actually think about architecture instead of mindlessly following Google's documentation.

Why I Built This

I got tired of watching teams drown in dependency hell. Your typical Flutter project has 200+ packages that conflict with each other, break on updates, and force you to spend more time managing dependencies than building features. You need 15 different packages just to handle basic state management, routing, and logging — all with different APIs, philosophies, and maintainers who abandon projects without warning.

Mosaic replaces your entire chaotic toolchain with one coherent system. Everything works together because it was designed together. No more version conflicts, no more API mismatches, no more dependency roulette.

What I Built

Event system that makes Redux look like a toy:

// Pattern matching that actually works
events.on<Payment>('payment/*', callback);  // Any payment event
events.on<User>('user/#', callback);        // All user events, recursively

True modularity (not the fake "packages" everyone pretends are modules):

// Modules are completely isolated universes
class PaymentModule extends Module {
  // Own lifecycle, DI container, navigation stack
  // Zero dependencies on other modules
}

Dynamic UI injection (bet none of you have seen this):

// Module A injects into Module B without imports
// Try doing THAT with your precious Provider pattern
injector.inject('home/sidebar', widget);

Reactive signals that don't suck like every other state solution:

final user = AsyncSignal(() => api.fetchUser(), autorun: true);
// Loading states, error handling, computed values - all built in
// While you're still wrestling with StreamBuilder

Thread safety that actually works:

final cache = Mutex<Map<String, User>>({});
// No more race conditions because you don't understand concurrency

Dependency injection that respects boundaries (unlike your get_it mess):

// Global DI for shared services
global.put<HttpClient>(CustomHttpClient());

// Per-module DI for isolation
class PaymentModule extends Module {
  @override
  Future<void> onInit() async {
    di.put<PaymentService>(StripeService());
    di.lazy<PaymentRepository>(() => PaymentRepository());
    // Module dependencies stay in the module
  }
}

The Numbers Don't Lie

Builds: 3 hours → 15 minutes (while your team waits for CI)
Team conflicts: Daily nightmare → Zero in 6 months
Test coverage: "What's testing?" → 95% per module
Deployment: All-or-nothing disasters → Independent module releases

Mosaic vs Your Favorite "Solutions"

Building a User Profile with Counter

Provider (The Widget Coupling Hell):

// 1. Create provider with boilerplate
class UserProvider extends ChangeNotifier {
  User? _user;
  int _counter = 0;

  void increment() {
    _counter++;
    notifyListeners(); // Manual notification hell
  }
}

// 2. Wrap everything in providers
MultiProvider(
  providers: [ChangeNotifierProvider(create: (_) => UserProvider())],
  child: MyApp(),
)

// 3. Use with ugly Consumer boilerplate
Consumer<UserProvider>(
  builder: (context, provider, child) {
    return Text('${provider.user?.name}: ${provider.counter}');
  },
)

BLoC (The Event/State Explosion):

// 1. Define endless events and states
abstract class UserEvent {}
class LoadUser extends UserEvent {}
class IncrementCounter extends UserEvent {}

abstract class UserState {}
class UserLoading extends UserState {}
class UserLoaded extends UserState {
  final User user;
  final int counter;
  UserLoaded(this.user, this.counter);
}

// 2. Create bloc with massive boilerplate
class UserBloc extends Bloc<UserEvent, UserState> {
  // 30+ lines of boilerplate for basic functionality
}

// 3. Use with even more boilerplate
BlocBuilder<UserBloc, UserState>(
  builder: (context, state) {
    if (state is UserLoaded) {
      return Text('${state.user.name}: ${state.counter}');
    }
    return CircularProgressIndicator();
  },
)

Mosaic (Real Architecture):

// 1. Module with built-in everything
class UserModule extends Module with Loggable {
  final userSignal = AsyncSignal<User>(() => fetchUser(), autorun: true);
  final counterSignal = Signal<int>(0);

  @override
  Future<void> onInit() async {
    // Built-in DI, events, logging - all integrated
    di.put<UserService>(UserService());
    events.on<String>('user/increment', (_) => counterSignal.state++);
    info('User module ready');
  }

  @override
  Widget build(BuildContext context) {
    return userSignal.when((status) {
      if (status.loading) return CircularProgressIndicator();
      if (status.success) return UserProfile(status.data!, counterSignal);
      return ErrorWidget(status.error);
    });
  }
}

// 2. Zero boilerplate usage
class UserProfile extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return counter.watch((count) => Text('${user.name}: $count'));
  }
}

// 3. Cross-module communication without coupling
events.emit('user/increment', null); // From anywhere

The difference:

Provider/BLoC: 50+ lines, tight coupling, boilerplate hell
Mosaic: 15 lines, zero coupling, everything integrated

Why Most Developers Will Resist This

Admitting Mosaic is right means admitting your current approach is wrong.

Package addicts will cry "vendor lock-in" (while locked into 15+ conflicting vendors)
BLoC evangelists will defend their boilerplate (because they've invested too much time learning it)
Provider fans will claim "simplicity" (while drowning in Consumer widgets)

Let them. The developers who get it will build next-generation applications while everyone else manages their dependency graveyard.

The Brutal Truth

90% of Flutter developers will look at this and not understand what they're seeing. They'll go back to their spaghetti code and wonder why their apps are unmaintainable garbage.

But the 10% who actually get it will never touch another monolithic Flutter app again.

Here's the kicker: This solves problems most of you don't even know you have yet. You're still thinking small-scale, single-developer, toy-app mindset. I'm thinking enterprise-scale, multi-team, real-world architecture.

Get Started

dependencies:
  mosaic: ^0.0.3

Links:

GitHub: https://github.com/marcomit/mosaic
Pub.dev: https://pub.dev/packages/mosaic
Docs: https://mosaicist.vercel.app

Feel free to go back to your callback hell and setState madness. I'll be here when you finally realize you need actual architecture.

Try to prove me wrong. I dare you.

What's your biggest Flutter architecture nightmare? Drop a comment and I'll show you how Mosaic solves it with one coherent system instead of 15 conflicting packages.