DEV Community: Omar Anajar

Building Offline-First Mobile Sync: Lessons from the Trenches

Omar Anajar — Wed, 28 Jan 2026 14:17:33 +0000

One of the most challenging features I've built was a mobile synchronization
engine that needed to work reliably even when users had no internet connection.

The Challenge

Field sales teams needed to access customer data, place orders, and record
visits while traveling through areas with poor connectivity. When they
reconnected, everything needed to sync seamlessly without data loss.

The Constraints

20+ different data types (customers, products, orders, prices, inventory)
1,000+ concurrent mobile users
Complex relationships between entities
Must handle conflicts when same data is edited offline by multiple users
Limited mobile storage and bandwidth

The Architecture

1. Polymorphic Data Handler
I built a flexible system that could handle any entity type without hardcoding:

class SyncEngine {
    public function sync($entityType, $data) {
        $handler = $this->getHandler($entityType);
        return $handler->process($data);
    }
}

2. Role-Based Data Filtering
Different users need different data. A vendor doesn't need shipper information:

class VendorFormatter {
    public function format($data) {
        return [
            'customers' => $this->filterByTerritory($data->customers),
            'products' => $this->filterByCategory($data->products),
            // Only send what this user needs
        ];
    }
}

3. Conflict Resolution
Last-write-wins with server timestamp as source of truth:

if ($serverTimestamp > $localTimestamp) {
    // Server version is newer, update local
    $this->updateLocal($serverData);
} else {
    // Local version is newer, push to server
    $this->pushToServer($localData);
}

What I Learned

Technical Lessons:

Start with simple conflict resolution, add complexity only if needed
Optimize payload size—mobile bandwidth is precious
Database transactions are critical for data consistency
Comprehensive logging saves hours of debugging

Process Lessons:

Test with real users in real conditions (not just office WiFi)
Edge cases will surface in production—plan for them
Clear error messages help users understand what's happening
Incremental rollout catches issues before they scale

The Outcome

The system now processes thousands of sync operations daily with a 99.9%
success rate. Field teams can work confidently offline, knowing their data
will sync when connection returns.

Building offline-first is hard, but the user experience payoff is worth it.

What I Wish I Knew About Full-Stack Development 5 Years Ago

Omar Anajar — Mon, 29 Dec 2025 16:19:09 +0000

Five years into my career as a full-stack developer, here are the lessons
I wish someone had told me on day one.

1. Specialize Before You Generalize

What I thought: "I need to learn EVERYTHING to be full-stack."

What I learned: Master ONE backend framework and ONE frontend framework
first. I chose Laravel and Vue.js. Once you deeply understand one stack,
picking up others is easier.

Going wide before going deep leaves you mediocre at everything.

2. Performance Matters More Than You Think

What I thought: "Make it work first, optimize later."

What I learned: Yes, but... slow applications frustrate users. Learn
to write performant code from the start:

Understand database indexing
Know how your ORM generates queries
Cache strategically
Monitor performance in production

Optimization isn't premature if you're being thoughtful.

3. Clean Code Isn't Optional

What I thought: "I'll refactor later when I have time."

What I learned: You'll never have time. Write clean code now:

Use design patterns appropriately
Keep functions small and focused
Name things clearly
Delete code more than you write it

Future you (and your teammates) will thank present you.

4. Business Context Matters As Much As Code

What I thought: "Just tell me what to build."

What I learned: Understanding WHY you're building something changes
HOW you build it. Ask questions:

What problem does this solve?
Who are the users?
What's the business impact?
How will success be measured?

Developers who understand business become invaluable.

5. Communication Is a Technical Skill

What I thought: "I'm a developer, not a communicator."

What I learned: Your ability to:

Explain technical concepts to non-technical people
Write clear documentation
Give and receive code review feedback
Collaborate across teams

...is as valuable as your coding ability.

6. Choose Companies That Invest in You

What I thought: "Any experience is good experience."

What I learned: Choose companies with:

Modern tech stacks
Code review culture
Senior developers to learn from
Room for growth and ownership

Two years at a good company > five years at a mediocre one.

7. Build Things Outside Work

What I thought: "I code all day, I don't want to code at night."

What I learned: Side projects teach you things production work can't:

Trying new technologies without constraints
Owning decisions end-to-end
Building what YOU want to build
Creating a portfolio that speaks for itself

You don't need massive projects. Small, complete things showcase skills.

8. Imposter Syndrome Never Fully Goes Away

What I thought: "Once I know enough, I'll feel confident."

What I learned: Everyone feels like they're winging it sometimes.
Senior developers just hide it better. The difference? They've learned
to be comfortable being uncomfortable.

Not knowing something isn't failure—it's an opportunity to learn.

Final Thoughts

If I could tell 5-years-ago-me one thing: Focus on fundamentals, not
frameworks. Frameworks change. Understanding how databases work, how
to write clean code, how to solve problems systematically—that's forever.

How I Optimized Database Queries by 90% in a Laravel Application

Omar Anajar — Mon, 22 Dec 2025 00:48:41 +0000

When I inherited a Laravel application that was struggling with performance
issues, the biggest bottleneck wasn't the code—it was how we were querying
the database.

The Problem

The application was loading user dashboards with related data: orders,
customers, products, and pricing. Each page load triggered over 100 database
queries, taking 3-5 seconds to render.

The Investigation

I used Laravel Debugbar to analyze the queries and found the classic N+1
problem. For every order, we were making separate queries for customer data,
product details, and pricing information.

The Solution

Step 1: Eager Loading
Instead of lazy loading relationships, I implemented strategic eager loading:

// Before: N+1 queries
$orders = Order::all();
foreach ($orders as $order) {
    echo $order->customer->name; // New query each time!
}

// After: Optimized
$orders = Order::with(['customer', 'items.product'])->get();

Step 2: Query Scoping
I created reusable query scopes for common data patterns:

public function scopeWithFullDetails($query) {
    return $query->with([
        'customer.priceList',
        'items.product.category',
        'payments'
    ]);
}

Step 3: Strategic Caching
For frequently accessed, rarely changing data (like product catalogs),
I added Redis caching:

$products = Cache::remember('products.catalog', 3600, function () {
    return Product::with('category')->get();
});

The Results

Page load time: 3-5 seconds → under 500ms
Database queries: 100+ → under 10 per page
Server load reduced significantly
Better user experience

Lessons Learned

Always profile before optimizing - Don't guess where the bottleneck is
Eager loading is your friend - But don't over-eager-load everything
Cache wisely - Not everything needs real-time data
Think in relationships - Design your queries around how data connects

Performance optimization isn't magic—it's systematic analysis and
thoughtful solutions.