DEV Community: Abishek Dongol

It Works on My Machine: Debugging Vuex Proxy Traps in Production

Abishek Dongol — Thu, 05 Feb 2026 04:45:04 +0000

Ever deployed perfectly working code only to watch it fail spectacularly in production? This guide reveals a critical Vuex bug that silently breaks your app in production while working flawlessly locally—and shows you exactly how to fix it.

The Nightmare Scenario

Picture this: You've just finished a complex feature. You've tested it thoroughly on your local machine—clicking every button, checking every filter, verifying every state change. It's flawless.

You deploy to production.

Five minutes later, a ticket comes in: "Filters are broken. I click them, but nothing happens."

You open the live site. You click the filter. The checkbox ticks visually... but the results don't update. You navigate away and back—the checkbox is unchecked. The state is lost.

You frantically check your local environment again. It works perfectly.

Sound familiar? Welcome to the "Read-Only Proxy Trap"—a subtle difference between development and production environments that can cripple your Vue application.

The Root Cause: Strict Mode & Read-Only Proxies

The culprit lies in how Vuex handles state access differently across environments. In many Vuex setups, Strict Mode is enabled automatically in certain environments or behaves differently due to build optimizations.

Development: The Forgiving Environment

In development, Vue often allows you to get away with sloppy state mutations. If you access a Store object via a getter and then try to mutate it directly in a component, Vue might warn you—or it might just let it slide because the reactivity system (Proxies) handles it gracefully.

// Development: "Sure, go ahead."
const filters = store.getters.getFilters; // Returns a mutable reference
filters.active = true; // Works! Store updates (technically wrong, but works).

Production: The Strict Enforcer

In production, however, the build is optimized. Getters often return read-only proxies to enforce state immutability.

// Production: "Absolutely not."
const filters = store.getters.getFilters; // Returns a Read-Only Proxy
filters.active = true; // SILENT FAILURE. The proxy rejects the write.

⚠️ Silent Failures: Your component thinks it updated the value. The UI might even show a tick momentarily if it updated a local DOM state. But the underlying data model—the Store—never accepted the change.

Finding the Smoking Gun

The breakthrough in our debugging came from a simple console log added to the persistence layer:

console.log("Enriched State:", filters.state);
// Output: { victoria: { active: false } }

Even after explicitly clicking "Victoria", the logs showed active: false. The mutation was being ignored by the browser because we were trying to write to a read-only object.

The Fix: The "Buffer Pattern"

To solve this properly, we must never rely on mutating Store state directly from a component. Instead, we use a Local Reactive Buffer.

Step 1: Create a Mutable Copy

Instead of using the getter result directly, initialize a local reactive object by deep cloning the store data.

// ❌ BAD (Direct Reference)
// let filters = store.getters.getFilters;

// ✅ GOOD (Buffer Pattern)
import { reactive } from 'vue';
import { cloneDeep } from 'lodash';

// Create a totally independent, mutable copy
const filters = reactive(cloneDeep(store.getters.getFilters));

Step 2: Mutate the Buffer

Now, when users interact with the UI (e.g., clicking a checkbox), they modify your local buffer, not the Store. This is always allowed, in any environment.

// Component acts on 'filters', which is now just a local object.
// Mutation succeeds instantly.
filters.state['vic'].active = true;

Step 3: Sync Back to Store

Since the Store doesn't know about your buffer, you must explicitly commit the changes back.

const applyFilters = () => {
    // Send the Buffer to the Store
    store.dispatch('updateFilters', filters);
};

Step 4: Sync on Mount (Hydration)

If you use persistence (e.g., vuex-persistedstate), the Store might update silently during rehydration while your component holds a stale buffer. Re-sync on mount:

onMounted(() => {
    const freshState = store.getters.getFilters;
    // Wipe buffer and copy fresh state
    Object.keys(filters).forEach(k => delete filters[k]);
    Object.assign(filters, cloneDeep(freshState));
});

💡 Pro Tip: The Buffer Pattern ensures your components remain completely decoupled from Vuex's strict mode implementation, guaranteeing consistent behavior across all environments.

Other "Local vs. Production" Traps to Watch For

While debugging this issue, we identified other common scenarios where "It works on my machine" fails spectacularly:

1. Case Sensitivity (Filesystem)

Local (Windows/Mac): You import ./components/MyWidget.vue. The file is named myWidget.vue. It works because the OS is case-insensitive.

Production (Linux): The build fails or the component doesn't render because Linux is case-sensitive. ./components/MyWidget.vue does not exist.

✅ Fix: Always match the exact casing of your filenames.

2. API Race Conditions (Latency)

Local: Your API runs on localhost. Requests complete in 5ms. onMounted assumes data is available instantly.

Production: The API is across the world. Requests take 200ms. Your onMounted logic runs before the data arrives, causing undefined errors or empty lists.

✅ Fix: Always use v-if loading guards or await your dispatch actions.

3. Environment Variable Leaks

Local: You have a .env.local file with VUE_APP_API_KEY=secret.

Production: You forgot to add this variable to your CI/CD pipeline or deployment settings. The app deploys, but API calls return 401 Unauthorized.

✅ Fix: Document all required environment variables and verify them in your deployment checklist.

Key Takeaways

Production environments are unforgiving. Strict mode, read-only proxies, and real-world latency expose architectural flaws that development environments hide.

By adopting defensive coding patterns like the Buffer Pattern, you ensure that your components remain completely decoupled from the strict implementation details of your Store, guaranteeing identical behavior across all environments.

Quick Checklist

✅ Never mutate Store state directly from components
✅ Use the Buffer Pattern for complex state interactions
✅ Deep clone store data before local mutations
✅ Explicitly commit changes back to the Store
✅ Re-sync buffers on component mount
✅ Test with production-like conditions before deploying
✅ Match exact filename casing for imports
✅ Handle async data loading properly
✅ Verify all environment variables in production

Have you encountered this bug before? Share your experience in the comments below. If this guide helped you, consider sharing it with your team to prevent future production nightmares!

Last updated: February 4, 2026

Scaling Vue 3 Forms: A Pattern for Handling Heavy Data Reactivity

Abishek Dongol — Mon, 02 Feb 2026 06:46:06 +0000

Scaling Vue 3 Forms: A Pattern for Handling Heavy Data Reactivity

The Scenario

Imagine you are building a complex "Inventory Dashboard" for an e-commerce platform. One of the requirements is a granular filter system allowing users to select from thousands of nested product categories.

The backend provides a flat list of 5,000+ categories. Your job is to display these in a multi-select dropdown, pre-selecting user preferences stored in their profile.

The Symptoms

During development, everything seemed fine with mock data (10 items). But when testing with the production dataset, several critical issues emerged:

Main Thread Blocking: The page took 2-3 seconds to become interactive. The browser profile showed massive time spent in "Scripting" during the onMounted hook.
Input Lag: Typing in unrelated text inputs (like "Search Name") felt sluggish.
Mobile Crashes: On lower-end mobile devices, the browser would occasionally force-close due to memory pressure.
Reactivity Loops: Sometimes, resetting the filters triggered an infinite update loop between the parent container and the filter component.

Root Cause Analysis

The culprit was Eager Initialization of Deep Reactivity.

In Vue 3, reactive() uses Proxies. When we initialized the filter object with thousands of items—even if they were set to false—Vue created thousands of Proxy handlers.

// The Anti-Pattern: Eager Initialization
const allCategories = fetchCategories(); // Returns 5,000 items
// Creating 5,000+ reactive headers instantly
filters.categories = reactive(allCategories.map(c => ({ 
    id: c.id, 
    active: false 
})));

This heavy object persisted in memory. Every time a watcher ran a deep check, it traversed this massive tree.

The Solution: The "Sparse State" Pattern

We solved this by implementing a pattern we call Visual Separation with Just-In-Time Hydration. This involves three key changes.

1. Sparse State (Lazy Initialization)

Instead of populating the data model with 5,000 items, we start with an empty object.

// The Fix: Start empty
const filters = ref({
    categories: {} // No 5,000 items here!
});

This reduced the initial hydration time to near zero.

2. Visual Separation (View vs Model)

But how do we show the checklist? We use the static resources list for rendering, and check the sparse object for status.

// Template iterates the STATIC list (non-reactive or shallowRef)
<div v-for="category in staticCategoryList" :key="category.id">
    <checkbox 
        :label="category.name"
        :checked="getCategoryActive(category.id)" 
        @change="handleInteraction"
    />
</div>

// Helper function handles the logic
const getCategoryActive = (id) => {
    // 1. Check if user explicitly touched this item (Sparse Object)
    if (filters.value.categories[id]) {
        return filters.value.categories[id].active;
    }
    // 2. Fallback to User Preferences (Zero cost default)
    return userPreferences.includes(id);
};

This allows the UI to look populated while the underlying data model remains lightweight.

3. Just-In-Time Hydration

The user's default preferences (e.g., "Electronics", "Books") are displayed visually. But if they submit the form immediately, the filters object is empty! The API would receive {}, effectively wiping their preferences.

To fix this, we hydrate the state only when the user interacts.

const handleInteraction = (categoryId, newValue) => {
    // Is this the first interaction?
    if (!filters.value.hasInteracted) {
        // HYDRATE: Copy implicit preferences into the real object
        userPreferences.forEach(prefId => {
            filters.value.categories[prefId] = { active: true };
        });
        filters.value.hasInteracted = true;
    }

    // Now apply the specific change the user just made
    filters.value.categories[categoryId] = { active: newValue };
};

The Result

By distinguishing between the Visual State (what the user sees) and the Data State (what Vue tracks reactively), we achieved:

Instant Page Load: No heavy proxies on mount.
Snappy Input: No deep traversal overhead for unrelated fields.
Memory Safety: The application footprint reduced by 60%.
Data Integrity: Full data context is preserving correctly upon submission.

Takeaway: When dealing with heavy datasets in frontend forms, ask yourself: Does the framework need to track this data before the user touches it? If not, keep it sparse!

Cybersecurity Best Practices for Developers: A Practical Guide with Code Examples

Abishek Dongol — Tue, 27 Jan 2026 05:32:35 +0000

Security bugs are expensive. A single SQL injection can expose millions of user records. An XSS vulnerability can compromise user sessions. Let's skip the theory and dive into practical, actionable security practices with real code examples you can use today.

1. Authentication: Don't Roll Your Own Crypto

❌ Bad: Plain Text Passwords

# NEVER DO THIS
def create_user(username, password):
    db.execute("INSERT INTO users (username, password) VALUES (?, ?)", 
               username, password)

✅ Good: Hashed Passwords with bcrypt

import bcrypt

def create_user(username, password):
    # Generate salt and hash password
    salt = bcrypt.gensalt(rounds=12)
    hashed = bcrypt.hashpw(password.encode('utf-8'), salt)

    db.execute("INSERT INTO users (username, password_hash) VALUES (?, ?)", 
               username, hashed)

def verify_password(username, password):
    user = db.execute("SELECT password_hash FROM users WHERE username = ?", 
                      username).fetchone()

    if user and bcrypt.checkpw(password.encode('utf-8'), user['password_hash']):
        return True
    return False

Node.js Example:

const bcrypt = require('bcrypt');

async function createUser(username, password) {
    const saltRounds = 12;
    const hashedPassword = await bcrypt.hash(password, saltRounds);

    await db.query(
        'INSERT INTO users (username, password_hash) VALUES ($1, $2)',
        [username, hashedPassword]
    );
}

async function verifyPassword(username, password) {
    const result = await db.query(
        'SELECT password_hash FROM users WHERE username = $1',
        [username]
    );

    if (result.rows.length === 0) return false;

    return await bcrypt.compare(password, result.rows[0].password_hash);
}

2. SQL Injection: The Classic Vulnerability

❌ Bad: String Concatenation

# VULNERABLE TO SQL INJECTION
def get_user(username):
    query = "SELECT * FROM users WHERE username = '" + username + "'"
    return db.execute(query).fetchone()

# Attacker inputs: admin' OR '1'='1
# Resulting query: SELECT * FROM users WHERE username = 'admin' OR '1'='1'
# Returns all users!

✅ Good: Parameterized Queries

def get_user(username):
    query = "SELECT * FROM users WHERE username = ?"
    return db.execute(query, (username,)).fetchone()

# Even with malicious input, it's treated as a literal string

Node.js with PostgreSQL:

// ❌ VULNERABLE
async function getUser(username) {
    const query = `SELECT * FROM users WHERE username = '${username}'`;
    return await db.query(query);
}

// ✅ SAFE - Parameterized query
async function getUser(username) {
    const query = 'SELECT * FROM users WHERE username = $1';
    return await db.query(query, [username]);
}

ORM Examples (Even Safer):

# Using SQLAlchemy
from sqlalchemy import select

def get_user(username):
    stmt = select(User).where(User.username == username)
    return session.execute(stmt).scalar_one_or_none()

// Using Sequelize
async function getUser(username) {
    return await User.findOne({
        where: { username: username }
    });
}

3. XSS Prevention: Escape User Input

❌ Bad: Direct HTML Rendering

// VULNERABLE TO XSS
function displayComment(comment) {
    document.getElementById('comments').innerHTML += `
        <div class="comment">
            <p>${comment.text}</p>
            <span>By: ${comment.author}</span>
        </div>
    `;
}

// If comment.text = '<script>alert(document.cookie)</script>'
// The script executes!

✅ Good: Sanitize and Escape

function escapeHtml(unsafe) {
    return unsafe
        .replace(/&/g, "&amp;")
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;")
        .replace(/"/g, "&quot;")
        .replace(/'/g, "&#039;");
}

function displayComment(comment) {
    const div = document.createElement('div');
    div.className = 'comment';

    const p = document.createElement('p');
    p.textContent = comment.text; // textContent auto-escapes

    const span = document.createElement('span');
    span.textContent = `By: ${comment.author}`;

    div.appendChild(p);
    div.appendChild(span);
    document.getElementById('comments').appendChild(div);
}

React (Auto-Escapes by Default):

// ✅ Safe by default
function Comment({ comment }) {
    return (
        <div className="comment">
            <p>{comment.text}</p>
            <span>By: {comment.author}</span>
        </div>
    );
}

// ❌ Dangerous - only use when absolutely necessary
function RawComment({ htmlContent }) {
    return (
        <div dangerouslySetInnerHTML={{ __html: htmlContent }} />
    );
}

Backend Sanitization (Python):

import bleach

ALLOWED_TAGS = ['p', 'br', 'strong', 'em', 'a']
ALLOWED_ATTRIBUTES = {'a': ['href', 'title']}

def sanitize_html(dirty_html):
    return bleach.clean(
        dirty_html,
        tags=ALLOWED_TAGS,
        attributes=ALLOWED_ATTRIBUTES,
        strip=True
    )

def create_post(title, content):
    clean_content = sanitize_html(content)
    db.execute(
        "INSERT INTO posts (title, content) VALUES (?, ?)",
        (title, clean_content)
    )

4. Secure API Authentication with JWT

✅ Proper JWT Implementation:

const jwt = require('jsonwebtoken');
const crypto = require('crypto');

// Store this in environment variables, NOT in code
const JWT_SECRET = process.env.JWT_SECRET || crypto.randomBytes(64).toString('hex');
const JWT_EXPIRY = '1h';

function generateToken(userId) {
    return jwt.sign(
        { userId: userId },
        JWT_SECRET,
        { 
            expiresIn: JWT_EXPIRY,
            algorithm: 'HS256'
        }
    );
}

function verifyToken(token) {
    try {
        return jwt.verify(token, JWT_SECRET, { algorithms: ['HS256'] });
    } catch (error) {
        return null;
    }
}

// Middleware for protected routes
function authenticateToken(req, res, next) {
    const authHeader = req.headers['authorization'];
    const token = authHeader && authHeader.split(' ')[1]; // Bearer TOKEN

    if (!token) {
        return res.status(401).json({ error: 'Access token required' });
    }

    const decoded = verifyToken(token);
    if (!decoded) {
        return res.status(403).json({ error: 'Invalid or expired token' });
    }

    req.userId = decoded.userId;
    next();
}

// Usage
app.post('/api/login', async (req, res) => {
    const { username, password } = req.body;

    const user = await verifyUser(username, password);
    if (!user) {
        return res.status(401).json({ error: 'Invalid credentials' });
    }

    const token = generateToken(user.id);
    res.json({ token });
});

app.get('/api/protected', authenticateToken, (req, res) => {
    res.json({ message: 'Access granted', userId: req.userId });
});

5. Secure Session Management

✅ Express.js Secure Sessions:

const session = require('express-session');
const RedisStore = require('connect-redis').default;
const redis = require('redis');

const redisClient = redis.createClient();

app.use(session({
    store: new RedisStore({ client: redisClient }),
    secret: process.env.SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
    cookie: {
        secure: true,        // Only send over HTTPS
        httpOnly: true,      // Not accessible via JavaScript
        maxAge: 1000 * 60 * 60, // 1 hour
        sameSite: 'strict'   // CSRF protection
    }
}));

// Login handler
app.post('/login', async (req, res) => {
    const user = await verifyUser(req.body.username, req.body.password);

    if (user) {
        // Regenerate session ID to prevent session fixation
        req.session.regenerate((err) => {
            if (err) return res.status(500).json({ error: 'Login failed' });

            req.session.userId = user.id;
            req.session.username = user.username;
            res.json({ success: true });
        });
    } else {
        res.status(401).json({ error: 'Invalid credentials' });
    }
});

// Logout handler
app.post('/logout', (req, res) => {
    req.session.destroy((err) => {
        if (err) return res.status(500).json({ error: 'Logout failed' });
        res.clearCookie('connect.sid');
        res.json({ success: true });
    });
});

6. Input Validation: Never Trust User Input

✅ Comprehensive Validation (Node.js with express-validator):

const { body, validationResult } = require('express-validator');

app.post('/api/users',
    // Validation rules
    body('email')
        .isEmail()
        .normalizeEmail()
        .withMessage('Invalid email address'),
    body('username')
        .isLength({ min: 3, max: 20 })
        .matches(/^[a-zA-Z0-9_]+$/)
        .withMessage('Username must be 3-20 alphanumeric characters'),
    body('age')
        .optional()
        .isInt({ min: 13, max: 120 })
        .withMessage('Age must be between 13 and 120'),
    body('website')
        .optional()
        .isURL()
        .withMessage('Invalid URL'),

    // Handler
    async (req, res) => {
        const errors = validationResult(req);
        if (!errors.isEmpty()) {
            return res.status(400).json({ errors: errors.array() });
        }

        // Safe to use validated data
        const { email, username, age, website } = req.body;
        // ... create user
    }
);

Python with Pydantic:

from pydantic import BaseModel, EmailStr, HttpUrl, validator
from fastapi import FastAPI, HTTPException

app = FastAPI()

class UserCreate(BaseModel):
    email: EmailStr
    username: str
    age: int | None = None
    website: HttpUrl | None = None

    @validator('username')
    def validate_username(cls, v):
        if not 3 <= len(v) <= 20:
            raise ValueError('Username must be 3-20 characters')
        if not v.replace('_', '').isalnum():
            raise ValueError('Username must be alphanumeric')
        return v

    @validator('age')
    def validate_age(cls, v):
        if v is not None and not 13 <= v <= 120:
            raise ValueError('Age must be between 13 and 120')
        return v

@app.post("/api/users")
async def create_user(user: UserCreate):
    # Data is automatically validated
    # ... create user
    return {"message": "User created", "username": user.username}

7. CSRF Protection

✅ CSRF Tokens (Express):

const csrf = require('csurf');

// Setup CSRF protection
const csrfProtection = csrf({ cookie: true });

app.use(cookieParser());

// Send CSRF token to client
app.get('/form', csrfProtection, (req, res) => {
    res.render('form', { csrfToken: req.csrfToken() });
});

// Validate CSRF token on POST
app.post('/process', csrfProtection, (req, res) => {
    // If we get here, CSRF token is valid
    res.json({ success: true });
});

HTML Form:

<form action="/process" method="POST">
    <input type="hidden" name="_csrf" value="{{ csrfToken }}">
    <input type="text" name="data">
    <button type="submit">Submit</button>
</form>

Fetch API with CSRF:

async function submitForm(data) {
    const csrfToken = document.querySelector('[name=_csrf]').value;

    const response = await fetch('/process', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'CSRF-Token': csrfToken
        },
        body: JSON.stringify(data)
    });

    return response.json();
}

8. Secure File Uploads

✅ Safe File Upload Handler:

const multer = require('multer');
const path = require('path');
const crypto = require('crypto');

// Allowed file types
const ALLOWED_TYPES = {
    'image/jpeg': 'jpg',
    'image/png': 'png',
    'image/gif': 'gif',
    'application/pdf': 'pdf'
};

const MAX_FILE_SIZE = 5 * 1024 * 1024; // 5MB

const storage = multer.diskStorage({
    destination: (req, file, cb) => {
        cb(null, 'uploads/');
    },
    filename: (req, file, cb) => {
        // Generate random filename to prevent path traversal
        const randomName = crypto.randomBytes(16).toString('hex');
        const ext = ALLOWED_TYPES[file.mimetype];
        cb(null, `${randomName}.${ext}`);
    }
});

const upload = multer({
    storage: storage,
    limits: { fileSize: MAX_FILE_SIZE },
    fileFilter: (req, file, cb) => {
        // Check MIME type
        if (!ALLOWED_TYPES[file.mimetype]) {
            return cb(new Error('Invalid file type'), false);
        }
        cb(null, true);
    }
});

app.post('/upload', upload.single('file'), (req, res) => {
    if (!req.file) {
        return res.status(400).json({ error: 'No file uploaded' });
    }

    // Additional validation: check actual file content (magic bytes)
    const fileBuffer = fs.readFileSync(req.file.path);
    const fileType = require('file-type').fromBuffer(fileBuffer);

    if (!fileType || !ALLOWED_TYPES[fileType.mime]) {
        fs.unlinkSync(req.file.path); // Delete invalid file
        return res.status(400).json({ error: 'Invalid file content' });
    }

    res.json({ 
        message: 'File uploaded successfully',
        filename: req.file.filename
    });
});

9. API Rate Limiting

✅ Rate Limiting Middleware:

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');
const redis = require('redis');

const redisClient = redis.createClient();

// General API rate limit
const apiLimiter = rateLimit({
    store: new RedisStore({
        client: redisClient,
        prefix: 'rl:api:'
    }),
    windowMs: 15 * 60 * 1000, // 15 minutes
    max: 100, // 100 requests per windowMs
    message: 'Too many requests, please try again later',
    standardHeaders: true,
    legacyHeaders: false
});

// Stricter limit for authentication endpoints
const authLimiter = rateLimit({
    store: new RedisStore({
        client: redisClient,
        prefix: 'rl:auth:'
    }),
    windowMs: 15 * 60 * 1000,
    max: 5, // Only 5 login attempts per 15 minutes
    skipSuccessfulRequests: true, // Don't count successful logins
    message: 'Too many login attempts, please try again later'
});

app.use('/api/', apiLimiter);
app.use('/api/login', authLimiter);
app.use('/api/register', authLimiter);

10. Secrets Management: Never Hardcode Credentials

❌ Bad: Hardcoded Secrets

// NEVER DO THIS
const API_KEY = 'sk_live_51H7x2y3z4a5b6c7d8e9f0';
const DB_PASSWORD = 'mySecretPassword123';

✅ Good: Environment Variables

// .env file (add to .gitignore!)
/*
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
API_KEY=sk_live_51H7x2y3z4a5b6c7d8e9f0
JWT_SECRET=your-super-secret-jwt-key
SESSION_SECRET=your-session-secret
*/

// Load environment variables
require('dotenv').config();

const config = {
    database: process.env.DATABASE_URL,
    apiKey: process.env.API_KEY,
    jwtSecret: process.env.JWT_SECRET,
    sessionSecret: process.env.SESSION_SECRET
};

// Validate required env vars on startup
const requiredEnvVars = ['DATABASE_URL', 'API_KEY', 'JWT_SECRET'];
for (const envVar of requiredEnvVars) {
    if (!process.env[envVar]) {
        throw new Error(`Missing required environment variable: ${envVar}`);
    }
}

Python Example:

import os
from dotenv import load_dotenv

load_dotenv()

DATABASE_URL = os.getenv('DATABASE_URL')
API_KEY = os.getenv('API_KEY')
SECRET_KEY = os.getenv('SECRET_KEY')

# Validate
if not all([DATABASE_URL, API_KEY, SECRET_KEY]):
    raise ValueError("Missing required environment variables")

11. Security Headers

✅ Essential Security Headers:

const helmet = require('helmet');

app.use(helmet({
    contentSecurityPolicy: {
        directives: {
            defaultSrc: ["'self'"],
            styleSrc: ["'self'", "'unsafe-inline'"],
            scriptSrc: ["'self'"],
            imgSrc: ["'self'", "data:", "https:"],
            connectSrc: ["'self'"],
            fontSrc: ["'self'"],
            objectSrc: ["'none'"],
            mediaSrc: ["'self'"],
            frameSrc: ["'none'"]
        }
    },
    hsts: {
        maxAge: 31536000,
        includeSubDomains: true,
        preload: true
    }
}));

// Or manually
app.use((req, res, next) => {
    // Prevent clickjacking
    res.setHeader('X-Frame-Options', 'DENY');

    // Prevent MIME type sniffing
    res.setHeader('X-Content-Type-Options', 'nosniff');

    // Enable XSS filter
    res.setHeader('X-XSS-Protection', '1; mode=block');

    // Referrer policy
    res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');

    // Permissions policy
    res.setHeader('Permissions-Policy', 'geolocation=(), microphone=(), camera=()');

    next();
});

12. Secure Database Queries: Beyond SQL Injection

✅ Principle of Least Privilege:

-- Create a read-only user for reporting
CREATE USER 'reports'@'localhost' IDENTIFIED BY 'secure_password';
GRANT SELECT ON mydb.* TO 'reports'@'localhost';

-- Create an app user with limited permissions
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'secure_password';
GRANT SELECT, INSERT, UPDATE ON mydb.users TO 'appuser'@'localhost';
GRANT SELECT, INSERT ON mydb.posts TO 'appuser'@'localhost';

-- Never use root/admin for application connections

Connection String Example:

// Different connection pools for different purposes
const readOnlyPool = mysql.createPool({
    host: process.env.DB_HOST,
    user: 'reports',
    password: process.env.DB_REPORTS_PASSWORD,
    database: process.env.DB_NAME
});

const appPool = mysql.createPool({
    host: process.env.DB_HOST,
    user: 'appuser',
    password: process.env.DB_APP_PASSWORD,
    database: process.env.DB_NAME
});

13. Dependency Scanning in CI/CD

✅ GitHub Actions Security Workflow:

# .github/workflows/security.yml
name: Security Checks

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run npm audit
        run: npm audit --audit-level=high

      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          severity: 'CRITICAL,HIGH'

Package.json Scripts:

{
  "scripts": {
    "security-check": "npm audit && npm outdated",
    "security-fix": "npm audit fix",
    "precommit": "npm run security-check"
  }
}

14. Logging Security Events (Without Logging Sensitive Data)

✅ Secure Logging:

const winston = require('winston');

const logger = winston.createLogger({
    level: 'info',
    format: winston.format.json(),
    transports: [
        new winston.transports.File({ filename: 'error.log', level: 'error' }),
        new winston.transports.File({ filename: 'security.log' })
    ]
});

// Log security events
function logSecurityEvent(event, details) {
    logger.info({
        type: 'security',
        event: event,
        timestamp: new Date().toISOString(),
        ip: details.ip,
        userId: details.userId,
        userAgent: details.userAgent,
        // NEVER log passwords, tokens, or sensitive data
    });
}

// Usage in login handler
app.post('/login', async (req, res) => {
    const { username, password } = req.body;
    const user = await verifyUser(username, password);

    if (user) {
        logSecurityEvent('login_success', {
            ip: req.ip,
            userId: user.id,
            userAgent: req.headers['user-agent']
        });
        // ... handle successful login
    } else {
        logSecurityEvent('login_failure', {
            ip: req.ip,
            username: username, // OK to log username attempts
            userAgent: req.headers['user-agent']
        });

        // Check for brute force
        const attempts = await getFailedAttempts(req.ip);
        if (attempts > 5) {
            logSecurityEvent('brute_force_detected', {
                ip: req.ip,
                attempts: attempts
            });
            return res.status(429).json({ 
                error: 'Too many failed attempts' 
            });
        }

        res.status(401).json({ error: 'Invalid credentials' });
    }
});

15. CORS Configuration

❌ Bad: Wide Open CORS

// DANGEROUS - allows any origin
app.use(cors());

✅ Good: Restricted CORS:

const cors = require('cors');

const allowedOrigins = [
    'https://yourapp.com',
    'https://www.yourapp.com'
];

if (process.env.NODE_ENV === 'development') {
    allowedOrigins.push('http://localhost:3000');
}

app.use(cors({
    origin: (origin, callback) => {
        // Allow requests with no origin (mobile apps, Postman)
        if (!origin) return callback(null, true);

        if (allowedOrigins.includes(origin)) {
            callback(null, true);
        } else {
            callback(new Error('Not allowed by CORS'));
        }
    },
    credentials: true, // Allow cookies
    methods: ['GET', 'POST', 'PUT', 'DELETE'],
    allowedHeaders: ['Content-Type', 'Authorization']
}));

Quick Security Checklist

Before deploying to production, verify:

[ ] All passwords are hashed with bcrypt/Argon2
[ ] SQL queries use parameterized statements
[ ] User input is validated and sanitized
[ ] HTTPS is enforced (no HTTP)
[ ] Security headers are set (CSP, HSTS, X-Frame-Options)
[ ] CORS is properly configured
[ ] Rate limiting is enabled
[ ] Sessions use httpOnly, secure, sameSite cookies
[ ] File uploads are restricted and validated
[ ] No secrets in code (use environment variables)
[ ] Dependencies are up to date (npm audit)
[ ] Error messages don't leak sensitive info
[ ] Logging doesn't include passwords/tokens
[ ] Database users have minimal permissions
[ ] Authentication endpoints have rate limiting

Final Thoughts

Security isn't about being paranoid—it's about being responsible. Every line of code you write is potentially an attack vector. By following these practices and using the code examples above, you'll dramatically reduce your application's attack surface.

Remember: Security is not a feature you add at the end. It's a mindset you adopt from day one. Start with secure defaults, validate everything, trust nothing, and always assume your code will be attacked.

Building React Multiple Projects with a Single Codebase: A Shared-First Architecture Approach

Abishek Dongol — Wed, 21 Jan 2026 09:35:57 +0000

How we built a scalable multi-brand platform that serves multiple projects from one codebase

Introduction

Consider a scenario where you are building a talent marketplace platform. You start with one brand, let's call it TechCorp. It's successful, and now you want to launch HealthApp - a similar platform but for healthcare jobs. Then EduJobs for education, and FinanceHub for finance.

The challenge: Do you create separate codebases for each brand? Or can you build one codebase that serves all of them?

In this post, we'll explore how we implemented a shared-first architecture that allows us to run multiple brands from a single codebase, reducing maintenance overhead while maintaining brand-specific customizations.

The Problem: Code Duplication Hell

The Traditional Approach (What We Avoided)

The naive approach would be to create separate codebases:

project/
├── techcorp-frontend/     (500 files)
├── healthapp-frontend/    (500 files - mostly duplicated!)
├── edujobs-frontend/      (500 files - mostly duplicated!)
└── financehub-frontend/  (500 files - mostly duplicated!)

Problems with this approach:

❌ 4x maintenance: Fix a bug? Fix it 4 times!
❌ Code drift: Features get out of sync across brands
❌ Slow development: New features take 4x longer
❌ Testing nightmare: Test everything 4 times
❌ Resource waste: Same code, different locations

Real-World Example

Let's say you have an EmployerDashboard component:

TechCorp version:

// techcorp-frontend/src/pages/EmployerDashboard.tsx
export function EmployerDashboard() {
  return (
    <div>
      <h1>TechCorp Employer Dashboard</h1>
      <JobList />
      <StripePayment /> {/* TechCorp uses Stripe */}
    </div>
  );
}

HealthApp version:

// healthapp-frontend/src/pages/EmployerDashboard.tsx
export function EmployerDashboard() {
  return (
    <div>
      <h1>HealthApp Employer Dashboard</h1>
      <JobList />
      {/* HealthApp doesn't use payments */}
    </div>
  );
}

Notice: 90% of the code is identical! Only the payment flow differs.

The Solution: Shared-First Architecture

Core Principle

"Start with shared, override only when necessary"

Instead of duplicating code, we:

Create shared code that all brands use by default
Create brand-specific overrides only when there's a real difference
Use automatic resolution to pick the right code at runtime

Architecture Overview

src/
├── pages/
│   ├── shared/              # ✅ DEFAULT - Used by all brands
│   │   └── employer/
│   │       └── EmployerDashboard.tsx
│   │
│   └── brands/              # 🎨 OVERRIDES - Only when needed
│       ├── techcorp/
│       │   └── employer/
│       │       └── EmployerDashboard.tsx  # Only if different
│       └── healthapp/
│           └── employer/
│               └── EmployerDashboard.tsx  # Only if different
│
├── components/
│   ├── shared/              # Shared components
│   └── brands/              # Brand-specific overrides
│
├── services/
│   ├── shared/              # Shared API services
│   └── brands/              # Brand-specific services
│
└── config/
    ├── brands/              # Brand configurations
    ├── features/             # Feature flags
    └── locales/              # Translations per brand

How It Works

When the application needs a component, it follows this resolution:

1. Check: Does the current brand have its own version?
   ✅ YES → Use brand-specific version
   ❌ NO  → Continue to step 2

2. Check: Does shared version exist?
   ✅ YES → Use shared version
   ❌ NO  → Error (component missing)

Example:

TechCorp needs EmployerDashboard
- Checks: pages/brands/techcorp/employer/EmployerDashboard.tsx ❌ Not found
- Checks: pages/shared/employer/EmployerDashboard.tsx ✅ Found
- Result: Uses shared version
HealthApp needs EmployerDashboard
- Checks: pages/brands/healthapp/employer/EmployerDashboard.tsx ✅ Found!
- Result: Uses HealthApp-specific version

Implementation: Step by Step

Step 1: Brand Configuration

First, we define each brand's configuration:

// src/config/brands/brands/techcorp.ts
export const techcorpConfig: BrandConfig = {
  id: 'techcorp',
  name: 'TechCorp',
  region: 'US',
  locale: 'en-US',
  api: {
    baseUrl: 'https://api.techcorp.com/api/v1',
  },
  features: [
    'jobs.applications',
    'payments.stripe',        // ✅ Stripe enabled
    'payments.coupons',
    'jobs.places-autocomplete', // ✅ Google Maps enabled
  ],
  ui: {
    logo: '/techcorp-logo.png',
    primaryColor: '#3b82f6',
    theme: 'light',
  },
};

// src/config/brands/brands/healthapp.ts
export const healthappConfig: BrandConfig = {
  id: 'healthapp',
  name: 'HealthApp',
  region: 'US',
  locale: 'en-US',
  api: {
    baseUrl: 'https://api.healthapp.com/api/v1',
  },
  features: [
    'jobs.applications',
    // 'payments.stripe',     // ❌ Stripe disabled
    // 'jobs.places-autocomplete', // ❌ Google Maps disabled
  ],
  ui: {
    logo: '/healthapp-logo.png',
    primaryColor: '#10b981',
    theme: 'light',
  },
};

Step 2: Feature Flags System

We use feature flags to enable/disable features per brand:

// src/config/features/features.ts
export const FEATURES: Record<string, FeatureDefinition> = {
  'payments.stripe': {
    id: 'payments.stripe',
    name: 'Stripe Payments',
    description: 'Enable Stripe payment processing',
    category: 'payments',
    defaultEnabled: true,
  },
  'jobs.places-autocomplete': {
    id: 'jobs.places-autocomplete',
    name: 'Google Places Autocomplete',
    description: 'Enable Google Places autocomplete for job locations',
    category: 'jobs',
    defaultEnabled: true,
  },
};

Step 3: Shared Component with Feature Flags

Now we create a shared component that adapts based on feature flags:

// src/pages/shared/employer/EmployerDashboard.tsx
import { useFeature } from '@/hooks/useFeature';
import { useTranslation } from '@/hooks/useTranslation';

export function EmployerDashboard() {
  const hasStripe = useFeature('payments.stripe');
  const { t } = useTranslation();

  const handlePublishJob = async (jobId: string) => {
    if (!hasStripe) {
      // HealthApp: Direct publish without payment
      await publishJobDirectly(jobId);
      return;
    }

    // TechCorp: Show payment flow
    setShowPaymentDialog(true);
  };

  return (
    <div>
      <h1>{t('employer.dashboard.title')}</h1>
      <JobList />

      {hasStripe && (
        <StripePaymentDialog 
          open={showPaymentDialog}
          onComplete={handlePaymentComplete}
        />
      )}
    </div>
  );
}

Result:

TechCorp (hasStripe = true): Shows payment dialog
HealthApp (hasStripe = false): Publishes directly

Step 4: Dynamic Component Resolution

For components that need brand-specific versions, we use dynamic resolution:

// src/utils/brandResolver.ts
export async function resolveBrandPage(
  path: string
): Promise<{ default: ComponentType }> {
  const brandId = getCurrentBrandId();

  // Try brand-specific first
  try {
    const brandModule = await import(
      /* @vite-ignore */ `@/pages/brands/${brandId}/${path}.tsx`
    );
    return { default: brandModule.default };
  } catch (error) {
    // Fallback to shared
    const sharedModule = await import(
      /* @vite-ignore */ `@/pages/shared/${path}.tsx`
    );
    return { default: sharedModule.default };
  }
}

Usage in routing:

// src/App.tsx
import { lazy } from 'react';
import { resolveBrandPage } from '@/utils/brandResolver';

const EmployerDashboard = lazy(() => 
  resolveBrandPage('employer/EmployerDashboard')
);

function App() {
  return (
    <Routes>
      <Route 
        path="/employer/dashboard" 
        element={<EmployerDashboard />} 
      />
    </Routes>
  );
}

Step 5: Service Resolution

Services (API calls) also use brand-specific resolution:

// src/utils/brandServiceResolver.ts
export async function resolveServiceModule(
  servicePath: string
): Promise<any> {
  const brandId = getCurrentBrandId();

  try {
    // Try brand-specific service
    return await import(
      /* @vite-ignore */ `@/services/brands/${brandId}/${servicePath}.ts`
    );
  } catch (error) {
    // Fallback to shared service
    return await import(
      /* @vite-ignore */ `@/services/shared/${servicePath}.ts`
    );
  }
}

Usage:

// In a component
const fetchJobs = async () => {
  // Automatically resolves to:
  // - services/brands/techcorp/employer/jobBoardApi.ts (if exists)
  // - services/shared/employer/jobBoardApi.ts (fallback)
  const jobApi = await resolveServiceModule('employer/jobBoardApi');
  const jobs = await jobApi.getJobPosts();
  return jobs;
};

Real-World Example: Location Input

Let's see a complete example of how we handle different UI requirements.

The Requirement

TechCorp: Needs Google Places Autocomplete for location input
HealthApp: Simple text input is sufficient

Implementation

1. Define the feature:

// src/config/features/features.ts
'jobs.places-autocomplete': {
  id: 'jobs.places-autocomplete',
  name: 'Google Places Autocomplete',
  description: 'Enable Google Places autocomplete for job locations',
  category: 'jobs',
  defaultEnabled: true,
},

2. Enable for TechCorp:

// src/config/brands/brands/techcorp.ts
features: [
  'jobs.places-autocomplete', // ✅ Enabled
],

3. Create shared component with conditional rendering:

// src/pages/shared/employer/CreateJobAd.tsx
import { useFeature } from '@/hooks/useFeature';
import PlacesAutocomplete from 'react-places-autocomplete';

export function CreateJobAd() {
  const hasPlacesAutocomplete = useFeature('jobs.places-autocomplete');
  const [isGoogleMapsLoaded, setIsGoogleMapsLoaded] = useState(false);

  // Only load Google Maps if feature is enabled
  useEffect(() => {
    if (!hasPlacesAutocomplete) {
      setIsGoogleMapsLoaded(true); // Not needed
      return;
    }

    loadGoogleMapsScript()
      .then(() => setIsGoogleMapsLoaded(true))
      .catch(console.error);
  }, [hasPlacesAutocomplete]);

  return (
    <form>
      <label>Job Location *</label>

      {hasPlacesAutocomplete ? (
        // TechCorp: PlacesAutocomplete
        !isGoogleMapsLoaded ? (
          <div>Loading location services...</div>
        ) : (
          <PlacesAutocomplete
            value={location}
            onChange={setLocation}
            onSelect={handleLocationSelect}
          >
            {({ getInputProps, suggestions, getSuggestionItemProps }) => (
              <div>
                <input {...getInputProps({ placeholder: 'Select city' })} />
                {suggestions.map((suggestion) => (
                  <div {...getSuggestionItemProps(suggestion)}>
                    {suggestion.description}
                  </div>
                ))}
              </div>
            )}
          </PlacesAutocomplete>
        )
      ) : (
        // HealthApp: Simple input
        <input
          type="text"
          value={location}
          onChange={(e) => setLocation(e.target.value)}
          placeholder="Enter location"
        />
      )}
    </form>
  );
}

Result:

TechCorp: Gets Google Places Autocomplete with suggestions
HealthApp: Gets simple text input
Same component: No code duplication!

Translation System

Each brand can have its own translations:

// src/config/locales/translations/techcorp/en-US.ts
export const techcorpTranslations = {
  common: {
    welcome: 'Welcome to TechCorp',
    submit: 'Submit',
  },
  employer: {
    dashboard: {
      title: 'TechCorp Employer Dashboard',
    },
  },
};

// src/config/locales/translations/healthapp/en-US.ts
export const healthappTranslations = {
  common: {
    welcome: 'Welcome to HealthApp',
    submit: 'Submit',
  },
  employer: {
    dashboard: {
      title: 'HealthApp Employer Dashboard',
    },
  },
};

Usage:

import { useTranslation } from '@/hooks/useTranslation';

function Header() {
  const { t } = useTranslation();

  return <h1>{t('common.welcome')}</h1>;
  // TechCorp: "Welcome to TechCorp"
  // HealthApp: "Welcome to HealthApp"
}

Type System: Shared-First Pattern

Types also follow the shared-first pattern:

// src/types/shared/employer/jobs.ts
export interface Job {
  id: string;
  title: string;
  description: string;
  status: 'draft' | 'published' | 'closed';
}

// src/types/brands/techcorp/employer/jobs.ts
// Only if TechCorp needs additional types
export interface TechCorpJob extends Job {
  techStack: string[]; // TechCorp-specific field
}

Usage:

// Always import from shared first
import { Job } from '@/types/shared/employer/jobs';

// Brand-specific types override automatically if they exist

Benefits: Why This Approach Works

1. Reduced Maintenance

Before (separate codebases):

Bug fix: Fix in 4 places
New feature: Implement 4 times
Testing: Test 4 times

After (shared-first):

Bug fix: Fix once, all brands benefit
New feature: Implement once, all brands get it
Testing: Test once (with brand variations)

2. Consistency

All brands share the same core functionality, ensuring:

Consistent user experience
Same bug fixes across brands
Unified feature set

3. Faster Development

New features roll out to all brands simultaneously
Less code to write and maintain
Easier onboarding for new developers

4. Flexibility

Brand-specific customizations when needed
Feature flags for gradual rollouts
Easy to add new brands

5. Cost Efficiency

Single codebase to maintain
Shared infrastructure
Reduced development time

Best Practices

1. Start with Shared

✅ DO:

// Create shared component first
// src/components/shared/employer/JobCard.tsx
export function JobCard({ job }) {
  return <div>{job.title}</div>;
}

❌ DON'T:

// Don't create brand-specific "just in case"
// Wait until you actually need it

2. Use Feature Flags for Conditional Behavior

✅ DO:

const hasFeature = useFeature('feature.id');
{hasFeature ? <FeatureComponent /> : <DefaultComponent />}

❌ DON'T:

// Don't create brand-specific component for simple conditionals
if (brandId === 'techcorp') {
  return <TechCorpComponent />;
}

3. Create Brand-Specific Only When Necessary

✅ Create brand-specific when:

Different API endpoints
Completely different UI structure
Different business logic that can't be conditional
Different validation rules

❌ Don't create brand-specific for:

Text differences (use translations)
Styling differences (use CSS/theme)
Simple conditional behavior (use feature flags)

4. Keep Brand-Specific Code Minimal

// ✅ GOOD: Minimal brand-specific override
// src/pages/brands/healthapp/employer/EmployerDashboard.tsx
import SharedDashboard from '@/pages/shared/employer/EmployerDashboard';

export function EmployerDashboard() {
  // Only override what's different
  return (
    <SharedDashboard 
      showPayment={false} // HealthApp-specific prop
    />
  );
}

// ❌ BAD: Duplicating entire component
export function EmployerDashboard() {
  // Copying 500 lines of shared code...
}

Migration Strategy

If you're migrating from separate codebases:

Step 1: Identify Shared Code

# Compare files across brands
diff techcorp/src/pages/Dashboard.tsx healthapp/src/pages/Dashboard.tsx

Step 2: Move to Shared

# Move shared code
mv techcorp/src/pages/Dashboard.tsx shared/src/pages/Dashboard.tsx

Step 3: Update Imports

// Before
import Dashboard from '@/pages/brands/techcorp/Dashboard';

// After
import Dashboard from '@/pages/shared/Dashboard';

Step 4: Handle Differences

// Use feature flags or brand-specific overrides
const hasFeature = useFeature('feature.id');

Step 5: Test

Test with each brand
Verify brand-specific overrides work
Ensure shared code works for all brands

Performance Considerations

Code Splitting

Each brand only loads what it needs:

// Lazy loading with brand resolution
const EmployerDashboard = lazy(() => 
  resolveBrandPage('employer/EmployerDashboard')
);

Bundle Size

Shared code: Loaded once
Brand-specific code: Only loaded when needed
Feature flags: No runtime overhead

Caching

Shared components cached across brands
Brand-specific components cached per brand
Translations cached per brand

Common Patterns

Pattern 1: Conditional UI

const hasFeature = useFeature('feature.id');
return (
  <div>
    {hasFeature && <FeatureComponent />}
    <DefaultComponent />
  </div>
);

Pattern 2: Conditional Logic

const handleAction = async () => {
  if (hasFeature) {
    return await complexFlow();
  }
  return await simpleFlow();
};

Pattern 3: Brand-Specific Override

// Shared component
// src/components/shared/employer/JobCard.tsx
export function JobCard({ job }) {
  return <div>{job.title}</div>;
}

// Brand-specific override
// src/components/brands/healthapp/employer/JobCard.tsx
export function JobCard({ job }) {
  return (
    <div className="healthapp-theme">
      <h2>{job.title}</h2>
      <p>{job.description}</p>
    </div>
  );
}

Testing Strategy

Unit Tests

describe('EmployerDashboard', () => {
  it('works with Stripe enabled', () => {
    setBrand('techcorp');
    const { getByText } = render(<EmployerDashboard />);
    expect(getByText('Payment')).toBeInTheDocument();
  });

  it('works without Stripe', () => {
    setBrand('healthapp');
    const { queryByText } = render(<EmployerDashboard />);
    expect(queryByText('Payment')).not.toBeInTheDocument();
  });
});

Integration Tests

describe('Brand Resolution', () => {
  it('resolves brand-specific component', async () => {
    setBrand('healthapp');
    const component = await resolveBrandPage('employer/Dashboard');
    expect(component).toBeDefined();
  });

  it('falls back to shared component', async () => {
    setBrand('techcorp');
    const component = await resolveBrandPage('employer/Dashboard');
    expect(component).toBeDefined();
  });
});

Challenges and Solutions

Challenge 1: Vite Dynamic Imports

Problem: Vite doesn't support dynamic template literals in imports.

Solution: Use static import maps or /* @vite-ignore */:

const brandId = getCurrentBrandId();
const module = await import(
  /* @vite-ignore */ `@/pages/brands/${brandId}/Dashboard.tsx`
);

Challenge 2: TypeScript Type Resolution

Problem: TypeScript can't resolve dynamic imports.

Solution: Use shared types as base, brand-specific types extend:

// Always import from shared
import { Job } from '@/types/shared/employer/jobs';

// Brand-specific types override if they exist

Challenge 3: Testing Multiple Brands

Problem: Need to test with different brand configurations.

Solution: Use test utilities:

function setBrandForTesting(brandId: string) {
  process.env.VITE_BRAND_ID = brandId;
  // Re-initialize brand config
}

Conclusion

Building multiple projects with a single codebase is not only possible but highly beneficial when done right. The shared-first architecture pattern allows us to:

✅ Maintain one codebase instead of multiple
✅ Customize per brand when needed
✅ Deploy faster with shared features
✅ Reduce bugs with single source of truth
✅ Scale easily by adding new brands

Key Takeaways

Start with shared code - Default to shared implementations
Override only when necessary - Create brand-specific files sparingly
Use feature flags - For conditional behavior instead of duplication
Use translations - For text differences, not code duplication
Test thoroughly - With all brands to ensure compatibility

Next Steps

If you're considering this approach:

Start small - Migrate one component at a time
Use feature flags - For gradual migration
Document everything - Keep track of brand-specific differences
Test continuously - Ensure all brands work correctly

"Simple and basic mood" Happy coding!

Have questions or feedback? Feel free to reach out!

AI-Powered Development: Building Smarter with Prompt Engineering

Abishek Dongol — Thu, 15 Jan 2026 15:12:30 +0000

AI-Powered Development: Building Smarter with Prompt Engineering

Introduction: The New Way to Code

Software development has changed forever. Developers worldwide are using AI as a coding partner, turning hours of work into minutes of conversation. Whether you're a beginner or an expert, AI tools are making development faster, easier, and more accessible than ever.

The Fascinating Paradox: Complex AI, Simple Code

Here's something interesting: when you ask AI to solve a simple problem, it uses sophisticated neural networks worth millions in research—but delivers clean, simple code anyone can understand.

Real Example

You need email validation. You could spend 30 minutes searching Stack Overflow, or ask AI: "Create an email validation function in JavaScript."

AI instantly provides:

function validateEmail(email) {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

Behind the scenes, AI processed billions of parameters to understand your request. But the result? Simple, maintainable code that works.

How AI Accelerates Development

Traditional Approach: 60 minutes

Search Stack Overflow (15 min)
Read multiple answers (10 min)
Adapt to your needs (20 min)
Debug issues (15 min)

AI-Assisted Approach: 10 minutes

Describe what you need (2 min)
Review generated code (3 min)
Make adjustments (5 min)

Result: 6x faster development

Major Benefits of AI-Assisted Development

For Developers

40-60% faster completion on routine tasks
Less mental fatigue - AI handles boilerplate code
Faster learning - see professional patterns instantly
Better quality - AI suggests best practices and security measures

For Teams

Quick onboarding - new members get up to speed faster
Consistent code - AI enforces standards across the team
Auto documentation - AI generates docs as code evolves
Better collaboration - even non-technical people can prototype ideas

Prompt Engineering: The Skill That Changes Everything

As AI becomes essential, a new critical skill emerges: prompt engineering—the art of communicating effectively with AI.

What Makes a Good Prompt?

Poor Prompt: "Make a login system"

Engineered Prompt: "Create a secure login system for Node.js/Express using JWT authentication. Include input validation, bcrypt password hashing, rate limiting for brute force protection, and error handling. Provide user model, auth routes, and middleware."

The difference? Specificity, context, and clear requirements.

5 Essential Prompt Engineering Techniques

Be Specific - Include language, framework, and constraints
Provide Examples - Show AI what you want with samples
Define Constraints - Specify what to avoid and performance needs
Iterate Refine - Start broad, then narrow based on results
Request Explanations - Ask AI to explain its reasoning

The Future of Prompt Engineering: Massive Opportunities

Market Reality

Prompt engineering roles: $175K-$335K annually
Freelance rates: $100-$300 per hour
Demand growing across all industries

Why Prompt Engineering Courses Matter

1. Structured Learning - Move beyond trial-and-error to proven methods
2. Domain Expertise - Learn specialized prompts for coding, content, analysis
3. Advanced Techniques - Master chain-of-thought, few-shot learning, prompt chaining
4. Cross-Platform Skills - Work with GPT, Claude, Gemini, and specialized tools

Real Results: Case Studies

Solo Developer → SaaS in 3 Months

Using AI assistance, one developer built a complete SaaS application (typically needs a team and 9-12 months) in just 3 months by mastering prompt engineering.

Enterprise Team: 45% Faster

Fortune 500 company results after 6 months:

45% faster deployment
30% fewer production bugs
60% quicker onboarding
25% more features delivered

Cons and Challenges of AI-Assisted Development

While AI offers tremendous benefits, it's crucial to understand the limitations and potential pitfalls:

1. Over-Reliance and Skill Degradation

The Problem: Developers who constantly rely on AI may not develop deep problem-solving skills. Copy-pasting without understanding creates a shallow knowledge base.

Impact: When AI isn't available or gives incorrect solutions, developers struggle to debug or build from scratch.

2. Code Quality Inconsistency

The Problem: AI-generated code quality varies significantly. The same prompt can produce excellent code one time and mediocre or buggy code another.

Impact: Inconsistent outputs require constant vigilance and code review, sometimes negating time savings.

3. Security Vulnerabilities

The Problem: AI may generate code with security flaws, outdated patterns, or vulnerable dependencies. It doesn't always follow latest security best practices.

Impact: Applications become vulnerable to SQL injection, XSS attacks, authentication bypasses, and data breaches.

4. Hidden Technical Debt

The Problem: AI-generated code might work but use inefficient algorithms, poor architecture patterns, or create maintainability issues down the line.

Impact: Projects become harder to scale, modify, or debug as they grow, requiring expensive refactoring later.

5. Lack of Contextual Understanding

The Problem: AI doesn't understand your specific business logic, existing codebase patterns, or team conventions without explicit guidance.

Impact: Generated code may conflict with existing architecture, duplicate functionality, or miss critical edge cases specific to your domain.

6. Dependency and Licensing Issues

The Problem: AI might suggest libraries with restrictive licenses, deprecated packages, or dependencies with known vulnerabilities.

Impact: Legal complications, security risks, and maintenance nightmares from outdated dependencies.

7. False Confidence

The Problem: AI delivers answers with confidence even when wrong. Beginners especially may trust incorrect solutions without verification.

Impact: Bugs make it to production, projects fail, and developers learn incorrect patterns that harm their long-term growth.

8. Cost and Access Barriers

The Problem: Premium AI tools require subscriptions ($20-$100/month). Not everyone has equal access, creating a digital divide.

Impact: Individual developers and small teams in developing countries may be priced out of competitive advantages.

9. Privacy and Data Concerns

The Problem: Sharing proprietary code with AI tools may expose sensitive business logic, credentials, or confidential information.

Impact: Potential data breaches, intellectual property theft, and violation of NDAs or client agreements.

10. Limited Creative Problem-Solving

The Problem: AI excels at known patterns but struggles with truly novel solutions. It can't "think outside the box" or innovate beyond its training data.

Impact: Breakthrough innovations and unique solutions still require human creativity and insight.

Balancing Benefits and Risks

The key to successful AI-assisted development is awareness and balance:

✅ Do: Use AI to accelerate routine tasks and learn new concepts
❌ Don't: Blindly trust or copy without understanding

✅ Do: Review and test all AI-generated code thoroughly
❌ Don't: Skip security audits because "AI wrote it"

✅ Do: Build foundational coding skills alongside AI usage
❌ Don't: Let AI replace learning fundamentals

✅ Do: Use AI as a learning tool and productivity enhancer
❌ Don't: Become dependent on AI for every small task

Best Practice: Treat AI as a junior developer who's fast but needs supervision, not as an infallible expert.

Your Action Plan: Get Started Today

Week 1-2: Foundation

Choose an AI tool (GitHub Copilot, Claude, ChatGPT)
Practice with small tasks daily
Document what works

Week 3-4: Build Skills

Take a prompt engineering course
Build a small AI-assisted project
Join developer communities

Month 2-3: Specialize

Focus on your main framework
Create prompt templates
Share your learnings

Month 4+: Master

Take advanced courses
Build complex projects
Consider teaching others

Recommended Resources

Courses:

DeepLearning.AI: Prompt Engineering for Developers
Coursera: Prompt Engineering Specialization
Udemy: Advanced Prompt Engineering

Practice:

PromptBase (marketplace & learning)
GitHub Copilot Labs
AI coding playgrounds

Communities:

r/PromptEngineering
AI Development Discord
Dev.to AI tags

The Future: Human-AI Collaboration

AI won't replace developers—it will amplify them. The winning combination:

Humans provide: Creative direction, architecture, business logic
AI handles: Implementation, boilerplate, optimization
Together: Achieve what neither could alone

The developers who master this collaboration through prompt engineering will lead the next generation of innovation.

Conclusion: Your Journey Starts Now

AI-assisted development is here. Prompt engineering is one of the most valuable skills in tech today. The opportunity is massive, the learning curve is accessible, and the results speak for themselves.

Start small. Practice daily. Learn continuously. Your journey into AI-powered development begins with a single prompt—make it a good one.

Laravel Api Documentation with Swagger and Passport

Abishek Dongol — Thu, 11 Jun 2020 07:45:24 +0000

First, let’s see what we are going to have in this article:

Brief introduction about Swagger and its Importance.
Install and configure Laravel with Passport.
Integration of Swagger in Laravel Application.
How to use Swagger generated documentation.

What is Swagger?

As per Swagger: swagger is the most popular, and widely used tool for implementing the OpenAPI specification. The swagger consists of a toolset that includes a mix of open-source, free, and commercial tools while using at different stages of the API lifecycle.

Important for Implementing OpenAPI/Swagger

There are many reasons for implementing an OpenApi specification between frontend and backend can be valuable.

1. Consistency and easy to collaborate on API Design

From initial to the end of the project several developers, parties, and clients will be involved. So, to make API design flexible and consistent we need to follow certain rules and structures which make others understand and collaborate easily.

2. Save Time and Avoid Errors When Writing Code

While building software we need to count on all aspects which can affect the deadline of the project. One of the major aspects that need to be mentioned and managed to build applications is nonother then time. So, swagger is one of the most powerful tools which helps to manage time and reduce the problem of getting errors because of its code-generators while developing APIs.

3. Generate Beautiful and Interactive Documentation

Besides consistency, collaborative and time saving good documentation are one of the crucial parts of every API because it helps to understand the business logic of API and method of calling it for the developer who is involved while using API. Swagger provides a set of great tools like swagger editor, swagger codegen, Swagger UI, Swagger inspector for designing APIs. Among them, Swagger UI is the first tool that interacts with clients and developers which displays a list of available API operations which makes it easy to send a request in their browser with required parameters to test and get responses before writing code.

4. Distribution of API in the market

OpenAPI/Swagger covers all the required things to build a better and attractive application. But there is another best benefit of using it which is distribution/publishing of OpenAPI which allows client developers to use their preferred tools to combine and to use with the base API.

Before moving on to integration of swagger let’s take a look at the result of the documentation page that we are going to generate.

Install and configure Laravel with Passport

Let’s create our new Laravel application using the following mentioned command

composer create-project --prefer-dist laravel/laravel blog
created a database and then update the values of the following variables within the .env file:

DB_DATABASE
DB_USERNAME
DB_PASSWORD
Install Laravel Passport using composer

composer require laravel/passport
Run the following command to migrate your database

php artisan migrate
Next, to create the encryption keys needed to generate secured access tokens and save at secure place, run the command below

php artisan passport:install
Immediately after the installation process from the preceding command is finished, add the Laravel\Passport\HasApiTokens trait to your App\User model as shown here



// app/User.php
<?php
namespace App;
...
use Laravel\Passport\HasApiTokens; // include this
class User extends Authenticatable
{
    use Notifiable, HasApiTokens; // update this line
    ...
}

open the app/Providers/AuthServiceProvider file and update its content as shown below



// app/Providers/AuthServiceProvider.php

<?php
namespace App\Providers;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;
use Laravel\Passport\Passport; // add this

class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
         'App\Model' => 'App\Policies\ModelPolicy', // uncomment this line
    ];

    /**
     * Register any authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();
        Passport::routes(); // Add this
    }
}

to authenticate any incoming API requests, open the config/auth configuration file and set the driver option of the API authentication guard to passport



// config/auth

<?php

return [
    ...

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'api' => [
            'driver' => 'passport', // set this to passport
            'provider' => 'users',
            'hash' => false,
        ],
    ],

    ...
];

Integration of Swagger in Laravel Application

Now install the Swagger according to the Laravel version that you have installed. For more information please feel free to visit DarkaOnLine/L5-Swagger

composer require "darkaonline/l5-swagger"
You can publish Swagger’s configuration and view files into your project by running the following command

php artisan vendor:publish --provider "L5Swagger\L5SwaggerServiceProvider"
Now we have config/l5-swagger.php file with huge amount of options in which we need to add middleware in api array as below.



'api' => [
        /*
        |--------------------------------------------------------------------------
        | Edit to set the api's title
        |--------------------------------------------------------------------------
        */
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
        \Illuminate\Routing\Middleware\SubstituteBindings::class,
        \Laravel\Passport\Http\Middleware\CreateFreshApiToken::class,
        'auth',
        'title' => 'Integration Swagger in Laravel with Passport Auth',
    ],

Again, to enable passport authentication we need to uncomment Open API 3.0 support in security array of config/l5-swagger.php file



'security' => [

        // Open API 3.0 support
        'passport' => [ // Unique name of security
            'type' => 'oauth2', // The type of the security scheme. Valid values are "basic", "apiKey" or "oauth2".
            'description' => 'Laravel passport oauth2 security.',
            'in' => 'header',
            'scheme' => 'https',
            'flows' => [
                "password" => [
                    "authorizationUrl" => config('app.url') . '/oauth/authorize',
                    "tokenUrl" => config('app.url') . '/oauth/token',
                    "refreshUrl" => config('app.url') . '/token/refresh',
                    "scopes" => []
                ],
            ],
        ],
    ],

Before dive into deep lets get general information about Swagger Annotations
- @oa<Method-name>() refers to what kind of HTTP method we’ll use. The method can be GET, POST, PUT or DELETE.
- @oa\Parameter refers to the name of the parameters that will pass to API.
- @oa\Response() which kind of response and code will we return if the data is correct or incorrect.
- The magic parameter is required to include for passport authorization inside controller of specific method comment



     // magic parameter
     *security={
     *{
     *"passport": {}},
     *},

Now, we need to create routes for API. So, here’s routes/api



<?php

use Illuminate\Http\Request;

/*
|--------------------------------------------------------------------------
| API Routes
|--------------------------------------------------------------------------
|
| Here is where you can register API routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| is assigned the "api" middleware group. Enjoy building your API!
|
*/



Route::group([
    'prefix' => 'v1',
    'as' => 'api.',
    'middleware' => ['auth:api']
], function () {
    //lists all users
    Route::post('/all-user', 'API\ V1\ApiController@allUsers')->name('all-user');
});

//auth routes
Route::post('v1/user-register', 'API\ V1\AuthController@register');
Route::post('v1/user-login', 'API\ V1\AuthController@login');

//lists all active tests
Route::post('v1/test', 'API\ V1\ApiController@getActiveTest');

//lists payment detail of an individual
Route::post('v1/paymentdetail/{id}', 'API\ V1\API@paymentDetail');

//lists test user details
Route::post('v1/testuser', 'API\ V1\ApiController@testUsers');

//lists all active packages
Route::post('v1/package', 'API\ V1\ApiController@getPackages');

//lists every tests within the package
Route::post('v1/packagedetail/{id}', 'API\ V1\ApiController@getPackageDetails');

//lists all test details(test sections, questions, options)
Route::post('v1/testdetail/{id}', 'API\ V1\ApiController@testDetails');

At first, we need to add few Swagger Annotations in Controller.php which is located at app/Http/Controllers/Controller.php



<?php

namespace App\Http\Controllers;

use Illuminate\Foundation\Auth\Access\AuthorizesRequests;
use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Routing\Controller as BaseController;

class Controller extends BaseController
{
    /**
     * @OA\Info(
     *      version="1.0.0",
     *      title="Integration Swagger in Laravel with Passport Auth Documentation",
     *      description="Implementation of Swagger with in Laravel",
     *      @OA\Contact(
     *          email="admin@admin.com"
     *      ),
     *      @OA\License(
     *          name="Apache 2.0",
     *          url="http://www.apache.org/licenses/LICENSE-2.0.html"
     *      )
     * )
     *
     * @OA\Server(
     *      url=L5_SWAGGER_CONST_HOST,
     *      description="Demo API Server"
     * )

     *
     *
     */
    use AuthorizesRequests, DispatchesJobs, ValidatesRequests;
}

Now create two controller named ApiController and AuthController inside app/Http/Controllers/Api/V1 directory. In Laravel controller can be created via the following the command

php artisan make:controller Api/V1/ApiController

php artisan make:controller Api/V1/AuthController
Here is my code of AuthController



<?php

namespace App\Http\Controllers\API\Mobile\V1;

use App\Http\Controllers\Controller;
use App\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Validator;
use Symfony\Component\HttpFoundation\Response;

class AuthController extends Controller
{

    /**
     * @OA\Post(
     ** path="/v1/user-login",
     *   tags={"Login"},
     *   summary="Login",
     *   operationId="login",
     *
     *   @OA\Parameter(
     *      name="email",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *           type="string"
     *      )
     *   ),
     *   @OA\Parameter(
     *      name="password",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *          type="string"
     *      )
     *   ),
     *   @OA\Response(
     *      response=200,
     *       description="Success",
     *      @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *   ),
     *   @OA\Response(
     *      response=401,
     *       description="Unauthenticated"
     *   ),
     *   @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     *   @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      )
     *)
     **/
    /**
     * login api
     *
     * @return \Illuminate\Http\Response
     */
    public function login(Request $request)
    {
        $validator = $request->validate([
            'email' => 'email|required',
            'password' => 'required'
        ]);


        if (!auth()->attempt($validator)) {
            return response()->json(['error' => 'Unauthorised'], 401);
        } else {
            $success['token'] = auth()->user()->createToken('authToken')->accessToken;
            $success['user'] = auth()->user();
            return response()->json(['success' => $success])->setStatusCode(Response::HTTP_ACCEPTED);
        }
    }

    /**
     * @OA\Post(
     ** path="/v1/user-register",
     *   tags={"Register"},
     *   summary="Register",
     *   operationId="register",
     *
     *  @OA\Parameter(
     *      name="name",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *           type="string"
     *      )
     *   ),
     *  @OA\Parameter(
     *      name="email",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *           type="string"
     *      )
     *   ),
     *   @OA\Parameter(
     *       name="mobile_number",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *           type="integer"
     *      )
     *   ),
     *   @OA\Parameter(
     *      name="password",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *           type="string"
     *      )
     *   ),
     *      @OA\Parameter(
     *      name="password_confirmation",
     *      in="query",
     *      required=true,
     *      @OA\Schema(
     *           type="string"
     *      )
     *   ),
     *   @OA\Response(
     *      response=201,
     *       description="Success",
     *      @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *   ),
     *   @OA\Response(
     *      response=401,
     *       description="Unauthenticated"
     *   ),
     *   @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     *   @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      )
     *)
     **/
    /**
     * Register api
     *
     * @return \Illuminate\Http\Response
     */
    public function register(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'name' => 'required',
            'email' => 'required|email|unique:users',
            'password' => 'required|confirmed',
            'mobile_number' => 'required|unique:users'
        ]);

        if ($validator->fails()) {
            return response()->json(['error' => $validator->errors()], 401);
        }

        $input = $request->all();
        $input['password'] = Hash::make($input['password']);
        $user = User::create($input);
        $success['token'] =  $user->createToken('authToken')->accessToken;
        $success['name'] =  $user->name;
        return response()->json(['success' => $success])->setStatusCode(Response::HTTP_CREATED);
    }
    /**
     * details api
     *
     * @return \Illuminate\Http\Response
     */
    public function details()
    {
        $user = Auth::user();
        return response()->json(['success' => $user], $this->successStatus);
    }
}

Here is my code of ApiController with related Resource collection but you can use your own function logic



<?php

namespace App\Http\Controllers\API\Mobile\V1;

use App\Http\Controllers\Controller;
use App\Package;
use App\Payment;
use App\Test;
use App\User;
use Illuminate\Http\Request;
use Illuminate\Http\Response;
use App\Http\Resources\User as UserResource;
use App\Http\Resources\ActiveTest as ActiveTestResource;
use App\Http\Resources\Test as TestResource;
use App\Http\Resources\Payment as PaymentResource;
use App\Http\Resources\PackageDetail as PackageDetailResource;
use App\Http\Resources\Package as PackageResource;


use App\Http\Resources\UserTest as UserTestResource;

class ApiController extends Controller
{


    /**
     * @OA\Post(
     *      path="/v1/all-user",
     *      operationId="getUserList",
     *      tags={"Users"},
     * security={
     *  {"passport": {}},
     *   },
     *      summary="Get list of users",
     *      description="Returns list of users",
     *      @OA\Response(
     *          response=200,
     *          description="Successful operation",
     *          @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *      ),
     *      @OA\Response(
     *          response=401,
     *          description="Unauthenticated",
     *      ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      ),
     * @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     * @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *  )
     */
    public function allUsers()
    {
        $users = User::all();
        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'users' => UserResource::collection($users)
            ],

            'message' => 'All users pulled out successfully'

        ]);
    }

    /**
     * @OA\Post(
     *      path="/v1/test",
     *      operationId="getActiveTestList",
     *      tags={"Tests"},

     *      summary="Get list of active tests",
     *      description="Returns list of active tests",
     *      @OA\Response(
     *          response=200,
     *          description="Successful operation",
     *          @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *      ),
     *      @OA\Response(
     *          response=401,
     *          description="Unauthenticated",
     *      ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      ),
     * @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     * @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *  )
     */
    public function getActiveTest()
    {
        $tests = Test::where('status', 1)->get();
        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'test' => ActiveTestResource::collection($tests)
            ],

            'message' => 'Active tests pulled out successfully'
        ]);
    }

    /**
     * @OA\Post(
     ** path="/v1/testdetail/{id}",
     *   tags={"Tests"},
     *   summary="Test Detail",
     *   operationId="testdetails",
     *
     *   @OA\Parameter(
     *      name="id",
     *      in="path",
     *      required=true,
     *      @OA\Schema(
     *           type="integer"
     *      )
     *   ),
     *
     *   @OA\Response(
     *      response=200,
     *       description="Success",
     *      @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *   ),
     *   @OA\Response(
     *      response=401,
     *      description="Unauthenticated"
     *   ),
     *   @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     *   @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      )
     *)
     **/
    public function testDetails($id)
    {
        $test = Test::with('testSections', 'testSections.questions')->findOrFail($id);
        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'test' => new TestResource($test)
            ],

            'message' => 'Test detail pulled out successfully'
        ]);
    }

    /**
     * @OA\Post(
     ** path="/v1/paymentdetail/{id}",
     *   tags={"Payments"},
     *   summary="Payment Detail",
     *   operationId="paymentdetails",
     *
     *   @OA\Parameter(
     *      name="id",
     *      in="path",
     *      required=true,
     *      @OA\Schema(
     *           type="integer"
     *      )
     *   ),
     *
     *   @OA\Response(
     *      response=200,
     *       description="Success",
     *      @OA\MediaType(
     *          mediaType="application/json",
     *      )
     *   ),
     *   @OA\Response(
     *      response=401,
     *       description="Unauthenticated"
     *   ),
     *   @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     *   @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      )
     *)
     **/
    public function paymentDetail($id)
    {
        $paymentDetail = Payment::where('user_id', $id)->get();
        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'paymentDetail' => PaymentResource::collection($paymentDetail)
            ],

            'message' => 'Payment detail of the user pulled out successfully'
        ]);
    }

    /**
     * @OA\Post(
     *      path="/v1/package",
     *      operationId="getPackageList",
     *      tags={"Packages"},

     *      summary="Get list of Packages",
     *      description="Returns list of packages",
     *      @OA\Response(
     *          response=200,
     *          description="Successful operation",
     *          @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *      ),
     *      @OA\Response(
     *          response=401,
     *          description="Unauthenticated",
     *      ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      ),
     * @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     * @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *  )
     */
    public function getPackages()
    {
        $packages = Package::where('status', 1)->get();
        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'active packages' => PackageResource::collection($packages)
            ],

            'message' => 'All active packages pulled out successfully'
        ]);
    }

    /**
     * @OA\Post(
     *      path="/v1/packagedetail/{id}",
     *      operationId="getPackageDetail",
     *      tags={"Packages"},
     *      summary="Get list of Packages detail",
     *      description="Returns list of packages detail",
     *  @OA\Parameter(
     *      name="id",
     *      in="path",
     *      required=true,
     *      @OA\Schema(
     *           type="integer"
     *      )
     *   ),
     *      @OA\Response(
     *          response=200,
     *          description="Successful operation",
     *           @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *      ),
     *      @OA\Response(
     *          response=401,
     *          description="Unauthenticated",
     *      ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      ),
     * @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     * @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *  )
     */
    public function getPackageDetails(Request $request, $id)
    {
        $package = Package::findOrFail($id);
        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'test package detail' => new PackageDetailResource($package)
            ],

            'message' => 'Test list within the package pulled out successfully'
        ]);
    }

    /**
     * @OA\Post(
     *      path="/v1/testuser",
     *      operationId="getTestUserList",
     *      tags={"Users"},

     *      summary="Get list of Test users",
     *      description="Returns list of test Users",
     *      @OA\Response(
     *          response=200,
     *          description="Successful operation",
     *          @OA\MediaType(
     *           mediaType="application/json",
     *      )
     *      ),
     *      @OA\Response(
     *          response=401,
     *          description="Unauthenticated",
     *      ),
     *      @OA\Response(
     *          response=403,
     *          description="Forbidden"
     *      ),
     * @OA\Response(
     *      response=400,
     *      description="Bad Request"
     *   ),
     * @OA\Response(
     *      response=404,
     *      description="not found"
     *   ),
     *  )
     */
    public function testUsers()
    {
        $user = User::findOrFail(3);

        return response()->json([
            'status' => 'success',
            'status_code' => Response::HTTP_OK,
            'data' => [
                'test' => UserTestResource::collection($user->testUser)
            ],

            'message' => 'Test users\' detail pulled out successfully'
        ]);
    }
}

To generate the swagger documentation file just run php artisan l5-swagger: generate command.
Now, test all the logic implemented so far by running the application with php artisan serve
The generated swagger documentation can be access via entering http:///api/documentation in your project.
The generated documentation can look like this.

How to use Swagger generated documentation

After run php artisan l5-swagger: generate command we need to enter http:///api/documentation address in our web browser.

If we click on any endpoint, it expands with all the parameters we had provided, and even with example response.
Let’s try with Login endpoint which does not require authentication.

At first, we need to click Try it out button. After that we need to fill the email and password then click the Execute button. If there is not any error then it will return server response as follows:

Now let’s try with Get list of users which marked with an unlocked icon under Users endpoints which required authentication.

Before accessing authentication endpoint we need to authorize it. So, In order to authorize we need to click the Authorize button.

A popup form will be displayed where we need to fill username and password with our project login credentials and need to provide a password grant client key with client_id and client_secret which we had generated using php artisan passport:install command and click Authorize button.

And it marks as authorized by displaying the popup.

After successfully authorized. Now unlocked icon changed into a locked icon which means we can access that endpoint api.

Now we can get all user data by just clicking the try it out button followed by the Execute button.

If you enjoyed this post, I’d be very grateful if you’d help it spread by emailing it to a friend, or sharing it on Twitter or Facebook. Thank you!

Laravel Test Driven Development

Abishek Dongol — Mon, 08 Jun 2020 11:22:53 +0000

Test Driven Development (TDD) is an established technique which is used to develop software faster with a consistent pattern. TDD is also known as part of the Agile process. It helps to build software from dust to dawn which initially starts with a failed test before writing production code itself. There are numbers of ways to implement TDD like Unit Testing, Feature testing, etc. As of today, test driven development is an integral practice in many software projects. However, this practice is still difficult to master and presents significant challenges and risks if not applied right.

When TDD is implemented in any project it ensures to cover all required aspects to develop robust applications. The main concept of the TDD is using small tests to design bottom-up in an emergent manner and rapidly get some value while building confidence in the system.

The advantages of TDD are

To build robust software.
To avoid errors while introducing new features.
To track project processes.
To create self-documented software.
To encourage simple designs and inspire confidence in code writing.
To analyze feasibility of logic while implementing new features.

Implementation of TDD is dependent upon the developer. Developers can create their own way to test a single line of code. Every single line can cause a crash, every missing line will not meet requirements which need to be tracked down and solved one after another.But there are simply three steps required to follow the TDD process.

Write a unit test that fails which shows a red signal.
Write enough code to make the test pass with a green signal. At this step we don’t care about good code.
Refactor your code from the previous step.

In the real world case scenario let’s implement TDD in Laravel with feature test.

Implementation

Create a project using command “composer create-project laravel/laravel exampleinsert”
Make few changes in ‘phpunit.xml by adding this two lines.

Server name=”DB_CONNECTION” value=”sqlite”
Server name=”DB_DATABASE” value=”:memory:”
Create a test case file by using “php artisan make:test ExampleInsertTest” which will create a ExampleInsertTest.php file inside tests/Feature/Folder and add below code.

    /** @test */

    Public function a_exampleinsert_can_be_added()
    {
        $this->withoutExceptionHandling();

        $response = $this->post(‘/exampleInsert’,[
            ‘title’ => ‘John Deo’,
            ‘address’ => ‘Nepal, Kathmandu’
        ]);

        $response->assertOk();
        $this->assertCount(1, Example::all());
         }

Now run vendor/bin/phpunit from project root directory.
After running above command we get following error

ERRORS! With red color, it is because the route which we are trying to hit isn’t created yet and we get the 404 status code in response. So let’s create route in our web.php file.

Route::post(‘/exampleInsert’,’ExampleInsertController@store’);
After creating route, run the test case and we get the error of ExampleInsertController does not exist.

Now create a controller with a store method and run the test case again and see the output console. We will get the following error. This error says that the Model of ExampleInsert is not available which we are calling in the assertCount method.

After creating the Model name with ExampleInsert yet we get another error output as follows with no such table.So we need to create a migration file.

Finally, after adding the migration file and store method with insert logic we get success green output.

Here, we developed the test case and then we moved on to the development of the insert feature of ExampleInsert.

At this point, we have finished our piece of implementation with TDD in mind, we have needed minimal code changes to pass all the rest cases and satisfy all requirements with refactoring, ensuring that we have great code quality.