Blog.

State management is one of the most discussed topics in Flutter development. With so many options available, it can be overwhelming to choose the right approach for your project.

Why State Management Matters

In Flutter, everything is a widget. When your app grows beyond a few screens, you need a systematic way to manage and share state across your widget tree.

The Options

1. setState The simplest approach. Great for local state within a single widget.

2. Provider A wrapper around InheritedWidget that makes it easier to manage state. It's the recommended approach by the Flutter team for most apps.

3. Riverpod A complete rewrite of Provider that fixes many of its limitations. It's compile-safe, testable, and doesn't depend on the widget tree.

4. BLoC Business Logic Component pattern. Great for complex apps with clear separation between UI and business logic.

My Recommendation

Start simple with setState for local state. Use Riverpod for shared state. Only reach for BLoC when you have complex business logic that benefits from the pattern.

The best state management solution is the one your team understands and can maintain.

Building a REST API that's clean, scalable, and developer-friendly takes more than just returning JSON. Here are the practices I follow in every backend project.

Resource Naming

Use Nouns, Not Verbs Your endpoints should represent resources. Use GET /users instead of GET /getUsers. The HTTP method already tells you the action.

Be Consistent with Plurals Stick with plural nouns: /users, /orders, /products. Consistency makes your API predictable.

Error Handling

Use Proper HTTP Status Codes 200 for success, 201 for created, 400 for bad request, 401 for unauthorized, 404 for not found, 500 for server errors. Don't return 200 with an error message in the body.

Return Meaningful Error Messages Include a clear message, an error code, and details when possible. Your frontend team will thank you.

Authentication

JWT vs Session-Based JWT works great for stateless APIs and mobile apps. Session-based auth is simpler for traditional web apps. Choose based on your architecture.

Always Use HTTPS Never transmit tokens over plain HTTP. Use HTTPS everywhere, even in development.

Versioning

Version your API from day one. Use URL versioning (/api/v1/users) — it's the most explicit and easiest to understand.

A well-designed API is a product in itself. Treat it with the same care you give your frontend.

SOLID principles are the foundation of writing maintainable, scalable software. But they're often taught in abstract, academic ways. Let's make them practical.

S — Single Responsibility

One Class, One Job A UserService should handle user operations — not also send emails and generate reports. If your class does too many things, split it.

O — Open/Closed

Open for Extension, Closed for Modification Use interfaces and abstractions so you can add new behavior without changing existing code. A PaymentProcessor interface lets you add new payment methods without touching the core logic.

L — Liskov Substitution

Subtypes Must Be Substitutable If your code works with a base class, it should work with any subclass without breaking. If a Square extends Rectangle but breaks when you set width independently of height, you've violated this principle.

I — Interface Segregation

Small, Focused Interfaces Don't force classes to implement methods they don't need. Instead of one giant interface, create several small ones. A Printable interface is better than a DoEverything interface.

D — Dependency Inversion

Depend on Abstractions High-level modules shouldn't depend on low-level modules. Both should depend on abstractions. Inject your dependencies instead of creating them inside the class.

The Key Takeaway

SOLID isn't about following rules blindly — it's about writing code that's easy to change, test, and understand. Apply these principles where they reduce complexity, not where they add it.

AWS can feel overwhelming with its 200+ services. But the truth is, most projects only need a few core services to get up and running.

The Big Three

EC2 — Virtual Servers Think of EC2 as renting a computer in the cloud. You pick the size (CPU, RAM), install your software, and run your app. It's the most flexible option — you control everything.

S3 — Storage S3 is a giant file storage system. Upload images, videos, backups, static websites — anything. It's cheap, reliable, and scales infinitely. Most apps use S3 for storing user uploads and assets.

RDS — Managed Databases RDS gives you a database (PostgreSQL, MySQL, etc.) without the headache of managing the server. AWS handles backups, updates, and scaling. You just write queries.

Networking Basics

VPC — Your Private Network A VPC is your own private section of AWS. Think of it as walls around your servers. You control who gets in and who doesn't.

Route 53 — DNS Route 53 manages your domain names. Point your domain to your EC2 instance or S3 bucket. It also handles load balancing across regions.

Serverless: The Easy Path

Lambda — Run Code Without Servers Write a function, upload it, and AWS runs it when triggered. No servers to manage, no scaling to worry about. You pay only when your code runs.

API Gateway — HTTP Endpoints for Lambda Pair API Gateway with Lambda and you have a fully serverless API. No EC2 needed.

Where to Start

Pick one project and deploy it. Start with S3 for a static site, or EC2 for a simple backend. Don't try to learn everything — learn what you need, when you need it.

The best way to learn AWS is to build something on it.