Uncategorized

If your Node.js app is starting to feel sluggish because it handles heavy tasks like sending emails, resizing images, generating PDFs or calling slow third-party APIs, you need a background job system. In this Bull queue Node.js tutorial, we will build a real, working setup using Redis, process jobs with retries, and monitor everything with Bull Board. This is a hands-on guide. By the end, you will have a production-ready pattern you can drop into any Node.js project. Why Use Bull Queue in Node.js? Node.js is single-threaded. When you run a CPU-heavy or slow I/O task inside a web request, you block the event loop and your API becomes slow for everyone. Bull solves this by pushing work into a Redis-backed queue that gets processed by separate workers. Reliability: jobs survive restarts because they live in Redis. Retries: failed jobs can retry automatically with backoff. Concurrency: process many jobs in parallel. Scheduling: delayed and repeatable (cron-like) jobs out of the box. Monitoring: a clean dashboard via Bull Board. Bull vs BullMQ: which one should you pick? This is the most common question. Here is a quick comparison so you can choose with confidence. Feature Bull BullMQ Status Mature, maintenance mode Actively developed API Callback / Promise based Modern async, class-based TypeScript Good Excellent Flows (parent/child jobs) No Yes Recommended for new projects If stack already uses it Yes In this tutorial we use the classic bull package because it is still extremely popular and most existing projects use it. The concepts translate almost 1:1 to BullMQ. Prerequisites Node.js 20 LTS or newer A running Redis instance (local Docker, Upstash, Redis Cloud, etc.) Basic knowledge of Express Spin up Redis quickly with Docker: docker run -d –name redis -p 6379:6379 redis:7-alpine Step 1: Project Setup mkdir bull-tutorial && cd bull-tutorial npm init -y npm install express bull ioredis nodemailer sharp npm install @bull-board/express @bull-board/api npm install -D nodemon Create the basic folder structure: bull-tutorial/ src/ queues/ workers/ routes/ server.js Step 2: Create the Redis Connection and Queues Create src/queues/index.js: const Queue = require(‘bull’); const redisConfig = { redis: { host: process.env.REDIS_HOST || ‘127.0.0.1’, port: process.env.REDIS_PORT || 6379, }, }; const emailQueue = new Queue(’email’, redisConfig); const imageQueue = new Queue(‘image’, redisConfig); module.exports = { emailQueue, imageQueue }; Step 3: Adding Jobs to the Queue Create src/routes/jobs.js. This Express router accepts requests and pushes jobs to the queue instead of processing them inline. const express = require(‘express’); const { emailQueue, imageQueue } = require(‘../queues’); const router = express.Router(); router.post(‘/send-email’, async (req, res) => { const { to, subject, body } = req.body; const job = await emailQueue.add( ‘send-welcome’, { to, subject, body }, { attempts: 5, backoff: { type: ‘exponential’, delay: 3000 }, removeOnComplete: 100, removeOnFail: 500, } ); res.json({ jobId: job.id, status: ‘queued’ }); }); router.post(‘/process-image’, async (req, res) => { const { imageUrl, userId } = req.body; const job = await imageQueue.add( ‘resize’, { imageUrl, userId }, { attempts: 3, priority: 1 } ); res.json({ jobId: job.id, status: ‘queued’ }); }); module.exports = router; Notice the important options: attempts: how many times Bull should retry the job before marking it failed. backoff: wait strategy between retries (fixed or exponential). removeOnComplete / removeOnFail: keep Redis clean by trimming old jobs. priority: lower number = higher priority. Step 4: Creating the Workers Workers are the processes that actually do the work. Keep them in separate files so you can scale them independently. Email worker Create src/workers/email.worker.js: const { emailQueue } = require(‘../queues’); const nodemailer = require(‘nodemailer’); const transporter = nodemailer.createTransport({ host: process.env.SMTP_HOST, port: 587, auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS, }, }); emailQueue.process(‘send-welcome’, 5, async (job) => { const { to, subject, body } = job.data; await job.progress(10); const info = await transporter.sendMail({ from: ‘[email protected]’, to, subject, html: body, }); await job.progress(100); return { messageId: info.messageId }; }); emailQueue.on(‘completed’, (job, result) => { console.log(`Email job ${job.id} completed`, result); }); emailQueue.on(‘failed’, (job, err) => { console.error(`Email job ${job.id} failed:`, err.message); }); The number 5 in emailQueue.process(‘send-welcome’, 5, …) is the concurrency: this worker will process up to 5 emails in parallel. Image processing worker Create src/workers/image.worker.js: const { imageQueue } = require(‘../queues’); const sharp = require(‘sharp’); const fs = require(‘fs/promises’); const path = require(‘path’); imageQueue.process(‘resize’, 2, async (job) => { const { imageUrl, userId } = job.data; const response = await fetch(imageUrl); const buffer = Buffer.from(await response.arrayBuffer()); const sizes = [ { name: ‘thumb’, width: 150 }, { name: ‘medium’, width: 600 }, { name: ‘large’, width: 1200 }, ]; const outputs = []; for (const [index, size] of sizes.entries()) { const outPath = path.join(‘uploads’, `${userId}-${size.name}.webp`); await sharp(buffer).resize(size.width).webp({ quality: 80 }).toFile(outPath); outputs.push(outPath); await job.progress(Math.round(((index + 1) / sizes.length) * 100)); } return { outputs }; }); Step 5: Monitoring with Bull Board Bull Board gives you a clean web UI to inspect waiting, active, completed and failed jobs, and re-run them manually. This is a game changer in production. Create src/server.js: const express = require(‘express’); const { createBullBoard } = require(‘@bull-board/api’); const { BullAdapter } = require(‘@bull-board/api/bullAdapter’); const { ExpressAdapter } = require(‘@bull-board/express’); const { emailQueue, imageQueue } = require(‘./queues’); require(‘./workers/email.worker’); require(‘./workers/image.worker’); const jobsRouter = require(‘./routes/jobs’); const app = express(); app.use(express.json()); const serverAdapter = new ExpressAdapter(); serverAdapter.setBasePath(‘/admin/queues’); createBullBoard({ queues: [new BullAdapter(emailQueue), new BullAdapter(imageQueue)], serverAdapter, }); app.use(‘/admin/queues’, serverAdapter.getRouter()); app.use(‘/api/jobs’, jobsRouter); app.listen(3000, () => { console.log(‘Server on http://localhost:3000’); console.log(‘Dashboard on http://localhost:3000/admin/queues’); }); Run it: npx nodemon src/server.js Open http://localhost:3000/admin/queues and you will see your queues live. In a real deployment, protect this route with basic auth or an admin middleware. Step 6: Scheduled and Repeatable Jobs Need a job to run every night at 2 AM, or to fire 10 minutes after signup? Bull supports both. // Delayed: send a reminder 24h after signup await emailQueue.add( ‘send-welcome’, { to: ‘[email protected]’, subject: ‘Day 1 reminder’, body: ‘…’ }, { delay: 24 * 60 * 60 * 1000 } ); // Repeatable: nightly cleanup at 02:00 await imageQueue.add( ‘cleanup’, {}, { repeat: { cron: ‘0 2 * * *’ } } ); Production Best Practices Separate

If you’re building a web application, the database schema is the foundation everything else rests on. Get it right, and your app scales gracefully. Get it wrong, and you’ll be paying technical debt for years. In this hands-on guide, we’ll walk through how to design a database schema for a real SaaS web application using PostgreSQL, covering entities, relationships, indexes, normalization, and the pitfalls we see most often at Coding4. Unlike generic tutorials, this article uses a concrete example: a multi-tenant SaaS project management tool. You’ll get actual SQL you can adapt, not just theory. What Is a Database Schema? A database schema is the blueprint that defines how your data is organized: the tables, columns, data types, constraints, and relationships between entities. A good schema enforces data integrity at the database level rather than relying solely on application code, which is the single most reliable way to keep your data clean over time. The 7 Steps to Design a Database Schema Before writing a single CREATE TABLE, follow this process: Understand the business requirements. What does the application actually need to do? Identify entities. Nouns in your requirements usually become tables (User, Project, Task). Define attributes. What properties does each entity have? Map relationships. One-to-one, one-to-many, many-to-many. Apply normalization. Eliminate redundancy (usually up to 3NF). Add constraints and indexes. Primary keys, foreign keys, unique constraints, and performance indexes. Review and iterate. Validate the schema against real query patterns. Step 1: Defining the Scope of Our Sample SaaS App Our example is a project management SaaS where: Organizations sign up and have multiple users (multi-tenancy). Each organization has projects. Projects contain tasks assigned to users. Tasks have comments and tags. We track audit information (created_at, updated_at) on everything. Step 2: Identifying Entities and Relationships From the requirements above, we can extract these core entities: Entity Purpose Key Relationships organizations Tenant root Has many users, projects users Authenticated accounts Belongs to organization projects Work containers Belongs to organization, has many tasks tasks Units of work Belongs to project, assigned to user comments Discussion on tasks Belongs to task and user tags Labels for tasks Many-to-many with tasks Step 3: Normalization in Practice Normalization is the process of structuring tables so that each piece of data lives in exactly one place. For most web apps, aiming for Third Normal Form (3NF) is the sweet spot. The three rules in plain English: 1NF: Every column holds one value (no arrays-as-strings, no comma-separated lists). 2NF: Every non-key column depends on the whole primary key. 3NF: No column depends on another non-key column. When to denormalize: Only when you have measured a real performance problem. Premature denormalization is one of the most common schema mistakes. Step 4: The Complete Sample Schema in PostgreSQL Here is the full schema with proper types, constraints, and timestamps: — Extension for UUID generation CREATE EXTENSION IF NOT EXISTS “pgcrypto”; — Organizations (tenants) CREATE TABLE organizations ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name VARCHAR(150) NOT NULL, slug VARCHAR(80) NOT NULL UNIQUE, plan VARCHAR(30) NOT NULL DEFAULT ‘free’, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); — Users CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), organization_id UUID NOT NULL REFERENCES organizations(id) ON DELETE CASCADE, email CITEXT NOT NULL, password_hash TEXT NOT NULL, full_name VARCHAR(150), role VARCHAR(20) NOT NULL DEFAULT ‘member’, is_active BOOLEAN NOT NULL DEFAULT TRUE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), UNIQUE (organization_id, email) ); — Projects CREATE TABLE projects ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), organization_id UUID NOT NULL REFERENCES organizations(id) ON DELETE CASCADE, name VARCHAR(200) NOT NULL, description TEXT, status VARCHAR(20) NOT NULL DEFAULT ‘active’, created_by UUID REFERENCES users(id) ON DELETE SET NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); — Tasks CREATE TABLE tasks ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), project_id UUID NOT NULL REFERENCES projects(id) ON DELETE CASCADE, assignee_id UUID REFERENCES users(id) ON DELETE SET NULL, title VARCHAR(255) NOT NULL, description TEXT, status VARCHAR(20) NOT NULL DEFAULT ‘todo’, priority SMALLINT NOT NULL DEFAULT 3 CHECK (priority BETWEEN 1 AND 5), due_date DATE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); — Comments CREATE TABLE comments ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), task_id UUID NOT NULL REFERENCES tasks(id) ON DELETE CASCADE, user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE, body TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); — Tags CREATE TABLE tags ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), organization_id UUID NOT NULL REFERENCES organizations(id) ON DELETE CASCADE, name VARCHAR(50) NOT NULL, color VARCHAR(7), UNIQUE (organization_id, name) ); — Junction table for tasks/tags (many-to-many) CREATE TABLE task_tags ( task_id UUID NOT NULL REFERENCES tasks(id) ON DELETE CASCADE, tag_id UUID NOT NULL REFERENCES tags(id) ON DELETE CASCADE, PRIMARY KEY (task_id, tag_id) ); Step 5: Indexing Strategy Primary keys and unique constraints get indexes automatically. For everything else, index based on how the application actually queries the data. — Foreign key lookups (PostgreSQL does NOT auto-index FKs) CREATE INDEX idx_users_organization_id ON users(organization_id); CREATE INDEX idx_projects_organization_id ON projects(organization_id); CREATE INDEX idx_tasks_project_id ON tasks(project_id); CREATE INDEX idx_tasks_assignee_id ON tasks(assignee_id); CREATE INDEX idx_comments_task_id ON comments(task_id); — Composite index for typical dashboard queries CREATE INDEX idx_tasks_project_status ON tasks(project_id, status); — Partial index: only active tasks with a due date CREATE INDEX idx_tasks_due_active ON tasks(due_date) WHERE status <> ‘done’ AND due_date IS NOT NULL; Indexing rules of thumb: Always index foreign key columns in PostgreSQL. Add composite indexes for the most frequent query filters, in the order of selectivity. Use partial indexes when only a subset of rows is ever queried. Don’t over-index. Every index slows down writes. Common Pitfalls to Avoid Using integer auto-increment IDs in a distributed system. UUIDs avoid collisions and prevent enumeration attacks. Storing dates as strings. Use TIMESTAMPTZ for all timestamps to handle time zones correctly. Soft-delete columns everywhere. Only add deleted_at where you actually need to recover data. Putting JSON everywhere. JSONB is great

If you build React applications and care about SEO, you have probably hit a frustrating wall: search engines need structured data in your HTML, but React renders everything client-side by default. Adding React schema markup the right way means understanding JSON-LD, picking the correct injection method, and handling server-side rendering when it matters. In this hands-on guide, we walk through exactly how to inject valid Schema.org JSON-LD into a React app using react-helmet, with copy-paste examples for articles, products, and breadcrumbs. We also cover the SSR pitfalls that most tutorials skip. Why Schema Markup Matters for React Apps Schema markup is structured data that helps Google, Bing, and other search engines understand the content on your page. When implemented correctly, it can unlock rich results: star ratings, product prices, FAQ accordions, breadcrumb trails, and more. For React developers specifically, the challenge is twofold: Client-side rendering means crawlers may not see your JSON-LD on first load Dynamic content (product pages, blog articles) needs schema generated per route JSON-LD is the format Google officially recommends. It lives inside a <script type=”application/ld+json”> tag in the document head, which makes it perfect for tools like react-helmet. Choosing Your Approach: react-helmet vs react-schemaorg vs Next.js Before writing code, pick the right tool for your stack. Approach Best For SSR Support Type Safety react-helmet-async CRA, Vite, custom SSR Yes No react-schemaorg Teams needing strict typing Yes (via Helmet) Yes (TypeScript) Next.js Metadata API Next.js 13+ App Router Built-in Partial Raw script tag in index.html Static, global schema only N/A No For this guide, we focus on react-helmet-async because it works across most React setups and handles SSR cleanly. Setting Up react-helmet-async Install the package: npm install react-helmet-async Wrap your app with the provider in index.js or main.tsx: import { HelmetProvider } from ‘react-helmet-async’; import App from ‘./App’; ReactDOM.createRoot(document.getElementById(‘root’)).render( <HelmetProvider> <App /> </HelmetProvider> ); Example 1: Article Schema for Blog Posts Create a reusable component that accepts post data and injects the correct JSON-LD: import { Helmet } from ‘react-helmet-async’; function ArticleSchema({ post }) { const schema = { “@context”: “https://schema.org”, “@type”: “Article”, “headline”: post.title, “description”: post.excerpt, “image”: post.featuredImage, “datePublished”: post.publishedAt, “dateModified”: post.updatedAt, “author”: { “@type”: “Person”, “name”: post.author.name, “url”: post.author.profileUrl }, “publisher”: { “@type”: “Organization”, “name”: “Coding4”, “logo”: { “@type”: “ImageObject”, “url”: “https://coding4.net/logo.png” } }, “mainEntityOfPage”: { “@type”: “WebPage”, “@id”: post.url } }; return ( <Helmet> <script type=”application/ld+json”> {JSON.stringify(schema)} </script> </Helmet> ); } export default ArticleSchema; Drop it into any blog post page: <ArticleSchema post={currentPost} />. Validating Your Output Always test with Google’s Rich Results Test and the Schema.org Validator. Common mistakes to watch for: Dates must be in ISO 8601 format Image URLs must be absolute, not relative The author field requires a Person or Organization with a name Example 2: Product Schema for E-commerce Product schema unlocks price, availability, and review stars directly in search results. function ProductSchema({ product }) { const schema = { “@context”: “https://schema.org”, “@type”: “Product”, “name”: product.name, “image”: product.images, “description”: product.description, “sku”: product.sku, “brand”: { “@type”: “Brand”, “name”: product.brand }, “offers”: { “@type”: “Offer”, “url”: product.url, “priceCurrency”: product.currency, “price”: product.price, “availability”: product.inStock ? “https://schema.org/InStock” : “https://schema.org/OutOfStock”, “itemCondition”: “https://schema.org/NewCondition” }, “aggregateRating”: product.reviewCount > 0 ? { “@type”: “AggregateRating”, “ratingValue”: product.averageRating, “reviewCount”: product.reviewCount } : undefined }; return ( <Helmet> <script type=”application/ld+json”> {JSON.stringify(schema)} </script> </Helmet> ); } Notice the conditional aggregateRating: Google penalizes pages that declare ratings without actual reviews, so only include the field when data exists. Example 3: BreadcrumbList Schema Breadcrumbs are simple but high-value. They replace your URL in search results with a clean navigation path. function BreadcrumbSchema({ items }) { const schema = { “@context”: “https://schema.org”, “@type”: “BreadcrumbList”, “itemListElement”: items.map((item, index) => ({ “@type”: “ListItem”, “position”: index + 1, “name”: item.name, “item”: item.url })) }; return ( <Helmet> <script type=”application/ld+json”> {JSON.stringify(schema)} </script> </Helmet> ); } // Usage const breadcrumbs = [ { name: “Home”, url: “https://coding4.net/” }, { name: “Blog”, url: “https://coding4.net/blog/” }, { name: “React Schema Markup”, url: “https://coding4.net/blog/react-schema-markup/” } ]; Handling Multiple Schemas on One Page It is perfectly valid to include several JSON-LD blocks on the same page. For example, an article page can have Article, BreadcrumbList, and Organization schemas at once. You have two options: Multiple Helmet components, each with its own script tag. React-helmet-async merges them correctly. A single graph object using @graph to bundle entities together. The graph approach looks like this: const schema = { “@context”: “https://schema.org”, “@graph”: [ { “@type”: “Article”, … }, { “@type”: “BreadcrumbList”, … }, { “@type”: “Organization”, … } ] }; The SSR Problem (and How to Solve It) Google’s crawler can now execute JavaScript, but relying on client-side rendering for structured data is risky. Indexation can be delayed by days, and other crawlers (Bing, social platforms) often skip JS entirely. Here are your real options: Next.js App Router: Use the generateMetadata function or inline a <script> tag in server components Remix: Use the meta export or render directly in route components (they SSR by default) Vite + react-helmet-async with SSR: Call HelmetProvider with a context object on the server and inject collected tags into your HTML template Static prerendering: Tools like react-snap or vite-plugin-prerender bake schema into HTML at build time Next.js App Router Pattern If you are on Next.js 14 or 15, the cleanest pattern looks like this: // app/blog/[slug]/page.tsx export default async function Page({ params }) { const post = await getPost(params.slug); const jsonLd = { “@context”: “https://schema.org”, “@type”: “Article”, “headline”: post.title, // … }; return ( <> <script type=”application/ld+json” dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }} /> <article>{post.content}</article> </> ); } This renders the JSON-LD server-side with zero extra dependencies. Common Mistakes to Avoid Escaping quotes manually: Use JSON.stringify instead of writing JSON inline as a string Mismatched content: The data in your schema must match what users see on the page Stale schema after navigation: When using SPAs, ensure your schema component re-renders on route change Forgetting absolute URLs: Always use full https:// URLs for images, authors, and pages Adding schema for content that does not exist: Do not declare a FAQ schema

If you have been writing web apps for a while, you have probably heard your colleagues say “it works on my machine” way too often. Docker is the tool that quietly killed that sentence. In this docker tutorial for web developers, we will skip the theory dumps and go straight into something useful: we will dockerize a real Node.js + Express app, explain the concepts as we hit them, and show you the gotchas nobody warns you about the first time. By the end of this guide you will have a working Dockerfile, a docker-compose.yml, hot reload during development, and a clear mental model of what containers, images and volumes actually are. Why Docker matters for web developers in 2026 Web stacks have become heavier. A single project may need Node.js 22, Postgres 16, Redis, a queue worker, maybe a Python script for image processing. Installing all of that on your laptop, switching versions between projects, and onboarding a new teammate is painful. Docker solves three concrete problems: Consistency: the same app runs the same way on your Mac, your colleague’s Windows machine, and the production Linux server. Isolation: project A uses Node 18, project B uses Node 22, and they do not fight each other. Speed of onboarding: a new developer clones the repo, runs one command, and is coding 5 minutes later. The 3 Docker concepts you actually need to know 1. Image An image is a read only template. Think of it as a snapshot of a filesystem plus the instructions to run a process. node:22-alpine is an image. Your app, once built, becomes an image. 2. Container A container is a running instance of an image. You can start, stop and delete containers without affecting the image. You can run 10 containers from the same image. 3. Volume A volume is persistent storage that lives outside the container. When a container is destroyed, its internal filesystem is gone. Volumes are how you keep database data, uploaded files, or share your source code with the container during development. Concept Analogy Lifetime Image A class in OOP Permanent until deleted Container An instance of that class Until you stop or remove it Volume An external hard drive Independent of containers Step 1: Install Docker Desktop Head to docker.com and download Docker Desktop for your OS. After installation, verify it works: docker –version docker run hello-world If you see a friendly hello message, you are ready. Step 2: Create a simple Node.js + Express app Let’s build a tiny API so we have something real to containerize. mkdir docker-node-demo && cd docker-node-demo npm init -y npm install express Create a server.js file: const express = require(‘express’); const app = express(); const PORT = process.env.PORT || 3000; app.get(‘/’, (req, res) => { res.json({ message: ‘Hello from inside a container!’, time: new Date() }); }); app.listen(PORT, () => { console.log(`Server running on port ${PORT}`); }); Update the scripts section of package.json: “scripts”: { “start”: “node server.js”, “dev”: “node –watch server.js” } Step 3: Write your first Dockerfile Create a file named Dockerfile (no extension) at the root of the project: # Use an official lightweight Node image FROM node:22-alpine # Set the working directory inside the container WORKDIR /app # Copy package files first to leverage Docker’s layer cache COPY package*.json ./ # Install only production dependencies RUN npm ci –omit=dev # Copy the rest of the source code COPY . . # Document the port the app listens on EXPOSE 3000 # Default command CMD [“node”, “server.js”] Also add a .dockerignore file. This is the single most forgotten file by beginners and it will save you from copying node_modules into your image: node_modules npm-debug.log .git .env Dockerfile docker-compose.yml Step 4: Build and run the image Build the image and tag it: docker build -t docker-node-demo . Run a container from it: docker run -p 3000:3000 –name my-api docker-node-demo Open http://localhost:3000 in your browser. Done. Your Node.js app is running inside a container. Understanding the port mapping The -p 3000:3000 flag means host port : container port. The first number is what you type in your browser, the second is what your app listens to inside the container. They do not need to match. Step 5: Add docker-compose for a real dev workflow Running long docker run commands gets old fast. Docker Compose lets you describe your stack in a YAML file. It also makes adding a database trivial. Create docker-compose.yml: services: api: build: . container_name: node-api ports: – “3000:3000” environment: – NODE_ENV=development – PORT=3000 volumes: – .:/app – /app/node_modules command: npm run dev db: image: postgres:16-alpine container_name: node-db environment: – POSTGRES_USER=demo – POSTGRES_PASSWORD=demo – POSTGRES_DB=demo ports: – “5432:5432″ volumes: – pgdata:/var/lib/postgresql/data volumes: pgdata: Start everything with one command: docker compose up To stop and remove the containers: docker compose down What the volumes do here .:/app mounts your local source code into the container, so editing a file on your laptop updates it inside the container instantly. Combined with node –watch, you get hot reload. /app/node_modules is a trick: it tells Docker to keep the container’s own node_modules folder and not let your host folder overwrite it. This avoids the classic “binary built for the wrong OS” error. pgdata is a named volume that survives container restarts. Your database data is safe. Common gotchas web developers hit the first time Forgetting .dockerignore: your image ends up huge and slow because node_modules got copied in. Wrong host binding: if your app listens on 127.0.0.1 instead of 0.0.0.0, Docker cannot expose it. Always bind to 0.0.0.0 inside containers. Cache busted on every build: copy package.json and run npm ci before copying the rest of the code. This keeps your dependency layer cached. node_modules conflict between host and container: use the anonymous volume trick shown above (/app/node_modules). Hardcoded secrets in Dockerfile: never. Use environment variables or a .env file referenced from compose. Using latest tag: pin your base images to a specific version like node:22-alpine. Future you will thank present you. File

Choosing between GraphQL and REST is still one of the most debated architectural decisions backend teams face in 2026. Both are mature, both are widely adopted, and both can power production systems at massive scale. But they solve API design problems very differently, and picking the wrong one can cost you weeks of refactoring later. At Coding4, we build APIs for clients across fintech, e-commerce, and SaaS. We’ve shipped both REST and GraphQL backends in production, so this guide isn’t theoretical. It’s the same decision framework we use internally when starting a new project. Quick Answer: GraphQL vs REST If you need a fast take before diving in: Pick REST when you need simplicity, strong HTTP caching, public APIs, or microservice-to-microservice communication. Pick GraphQL when you have complex, nested data, multiple client types (web, mobile, IoT), or when frontend teams need flexibility without backend changes. Use both (hybrid) when different parts of your system have different needs. This is increasingly the norm. What REST Actually Is REST (Representational State Transfer) is an architectural style built on top of HTTP. You expose resources through URLs, and clients interact with them using standard HTTP verbs: GET, POST, PUT, PATCH, DELETE. A typical REST request looks like this: GET /api/users/42 GET /api/users/42/orders GET /api/orders/1337/items Each endpoint returns a fixed data structure. If you want the user, their orders, and the items in those orders, you typically make three requests (or the backend builds a custom endpoint for you). What GraphQL Actually Is GraphQL is a query language and runtime for APIs, created by Facebook in 2015 and now governed by the GraphQL Foundation. Instead of multiple endpoints, you expose a single endpoint (usually /graphql) with a strongly typed schema. The client asks for exactly the fields it needs. The equivalent of the REST example above: query { user(id: 42) { name orders { id items { name price } } } } One request. One response. Only the fields requested. Side-by-Side Comparison Criteria REST GraphQL Endpoints Multiple, resource-based Single endpoint Data fetching Fixed payloads, prone to over/under-fetching Client picks exactly what it needs Caching Native HTTP caching, CDN-friendly Requires client-side libs (Apollo, urql, Relay) Versioning URL or header based (v1, v2) Schema evolution with deprecation Learning curve Low, everyone knows HTTP Moderate, schema and resolvers required Tooling Postman, OpenAPI, Swagger GraphiQL, Apollo Studio, Hasura Error handling HTTP status codes Always 200 OK with errors in payload File uploads Native multipart support Requires extensions Real-time SSE or WebSockets bolted on Subscriptions built into the spec Performance: Who Actually Wins? This is where most articles oversimplify. The honest answer: it depends on the workload. Where GraphQL Wins on Performance Mobile and low-bandwidth clients. Asking for only 4 fields instead of 40 reduces payload size dramatically. Aggregating multiple resources. One round-trip instead of N requests means less latency on high-RTT networks. Avoiding over-fetching. A REST /users/42 endpoint may return 50 fields when the UI only needs 3. Where REST Wins on Performance HTTP caching at the edge. CDNs like Cloudflare cache GET responses out of the box. GraphQL needs persisted queries or custom cache layers to get close. Predictable query cost. A REST endpoint has a known database fingerprint. A GraphQL query can be a deeply nested bomb if you don’t add query depth limits and complexity analysis. Streaming and large files. REST handles binary data and streaming far more naturally. Caching: The Biggest Practical Difference REST inherits the entire HTTP caching stack: Cache-Control, ETag, If-None-Match, 304 responses, CDN tiers. It just works. GraphQL, because it uses POST and a single endpoint, doesn’t get any of that for free. You have to: Use a client cache like Apollo Client or Relay. Implement persisted queries so queries become cacheable GET requests with hashes. Set up a smart gateway (Hasura, Apollo Router, GraphCDN-style services) for edge caching. If your API is read-heavy and public (think product catalogs, news, documentation), REST gives you wins for free that GraphQL makes you earn. Learning Curve and Team Considerations REST has a near-zero onboarding cost. Any developer who’s used curl can be productive in an hour. OpenAPI specs generate clients in 30+ languages automatically. GraphQL requires your team to understand: Schema Definition Language (SDL) Resolvers and the N+1 problem (solved with DataLoader) Query complexity and depth limiting Authorization at the field level, not just the endpoint level This isn’t a deal-breaker, but underestimating it is the #1 reason GraphQL projects fail. Budget for it. Real Use Cases: When Each One Wins Use REST When… You’re building a public API consumed by third parties. Stripe, GitHub, and Twilio all stayed primarily REST for a reason: it’s predictable, documentable, and easy to bill per call. Microservice-to-microservice communication where each service owns a clear domain. CRUD-heavy admin panels with simple, flat data. You need aggressive CDN caching for read-heavy traffic. Your team is small and you can’t afford a steep learning curve. Use GraphQL When… You have multiple client types (iOS, Android, web, smart TV) consuming the same backend with different data needs. Your data graph is deeply relational. Social feeds, dashboards, e-commerce product detail pages with reviews, recommendations, and inventory. Frontend velocity matters more than backend simplicity. Frontend teams can ship features without waiting for new endpoints. You’re aggregating multiple downstream services. GraphQL makes a great BFF (Backend For Frontend) layer. You need real-time subscriptions as a first-class citizen. The Hybrid Approach (Often the Right Answer) Many of our clients in 2026 run both. A common pattern: REST for internal service-to-service calls, webhooks, and public APIs. GraphQL as a gateway/BFF for frontend apps that aggregate data from those REST services. This is roughly how Netflix, Shopify, and GitHub structure their stacks. You get the cacheability and simplicity of REST at the service layer with the client flexibility of GraphQL at the edge. What About gRPC? Worth a quick mention since it comes up constantly. gRPC is excellent for internal microservices where you control both ends, need low latency, and want strong typing via

If your website feels sluggish, images are almost certainly the culprit. On the average web page, images account for more than 50% of total page weight, and unoptimized assets are the number one reason developers fail their Core Web Vitals audits. The good news? Image optimization is one of the few performance wins where the effort-to-impact ratio is extremely high. In this guide, we’ll walk through how to optimize images for website performance using techniques that actually move the needle in 2026: modern formats like WebP and AVIF, lazy loading, responsive srcset, smart compression, and CDN delivery. We’ll also show before/after Core Web Vitals numbers from real projects we’ve shipped at Coding4. Why Image Optimization Matters More Than Ever in 2026 Google’s Core Web Vitals have become a ranking factor that punishes slow sites without mercy. The two metrics most affected by images are: LCP (Largest Contentful Paint): usually the hero image or a large above-the-fold visual CLS (Cumulative Layout Shift): caused by images loading without reserved space On a recent client project, we cut LCP from 4.2s to 1.1s simply by applying the techniques in this article. No backend changes. No framework migration. Just better image handling. 1. Choose the Right Modern Format: WebP and AVIF JPEG and PNG are no longer the default choice. Modern formats deliver the same visual quality at a fraction of the file size. Format Avg. Size vs JPEG Browser Support Best For JPEG Baseline (100%) Universal Legacy fallback WebP ~25-35% smaller 98%+ General purpose default AVIF ~50% smaller 94%+ Photos, hero images PNG Variable Universal Transparency only SVG Tiny Universal Icons, logos Use the <picture> element to serve the best format each browser supports: <picture> <source srcset=”hero.avif” type=”image/avif”> <source srcset=”hero.webp” type=”image/webp”> <img src=”hero.jpg” alt=”Product hero” width=”1200″ height=”600″> </picture> 2. Compress Aggressively (But Smartly) Compression is where most of the file-size wins come from. The trick is finding the sweet spot where visual quality is preserved but bytes are slashed. Recommended Compression Tools Squoosh (web.dev): drag-and-drop browser tool, perfect for one-offs ImageOptim: free macOS app, strips metadata and recompresses losslessly sharp (Node.js): best for build pipelines and automated workflows cwebp / avifenc: command-line tools for batch conversion As a rule of thumb, target quality 75-85 for JPEG/WebP and quality 50-65 for AVIF. Most users can’t tell the difference from the original. 3. Resize Images to Their Actual Display Size Serving a 4000px-wide image into a 400px container is the single most common mistake we see in audits. Always resize to the maximum dimension the image will ever be displayed at, then let the browser handle the rest. 4. Use Responsive Images with srcset and sizes A mobile phone should never download a desktop-sized image. The srcset attribute lets the browser pick the right file based on viewport and device pixel ratio. <img src=”product-800.webp” srcset=”product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w, product-1600.webp 1600w” sizes=”(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px” alt=”Product photo” width=”800″ height=”600″> Pro tip: Always include explicit width and height attributes. This eliminates layout shift and protects your CLS score. 5. Lazy Load Below-the-Fold Images Browsers now support native lazy loading. Add one attribute and offscreen images will only load when the user scrolls toward them: <img src=”gallery-3.webp” alt=”Gallery shot 3″ loading=”lazy” width=”800″ height=”600″> Important: Never lazy load your LCP image (typically the hero). That will hurt performance, not help it. Instead, use fetchpriority=”high” on the hero: <img src=”hero.avif” alt=”Hero” fetchpriority=”high” width=”1200″ height=”600″> 6. Deliver Images Through a CDN A CDN caches images at edge locations close to your users, which dramatically reduces latency. Modern image CDNs go further and perform on-the-fly format conversion, resizing, and compression. Popular options in 2026: Cloudflare Images and Polish Cloudinary imgix Bunny.net Optimizer Vercel Image Optimization (great for Next.js) A URL like https://cdn.example.com/image.jpg?w=800&fm=avif&q=70 returns a perfectly sized AVIF, even if you uploaded a JPEG. 7. Preload Critical Hero Images For the single most important image on the page (usually the LCP element), tell the browser to fetch it as early as possible: <link rel=”preload” as=”image” href=”hero.avif” type=”image/avif” fetchpriority=”high”> This single line of HTML routinely shaves 300-800ms off LCP times. 8. Strip Metadata and Use Progressive Encoding Camera EXIF data, color profiles, and thumbnails embedded in image files can add 20-50 KB of pure waste. Tools like ImageOptim and the –strip-all flag in mozjpeg remove this overhead automatically. For JPEGs, also enable progressive encoding. The image renders in increasing quality as it downloads, which feels much faster to users. 9. Use Blurred Placeholders (LQIP) Low Quality Image Placeholders show a tiny, blurred preview while the full image loads. This improves perceived performance significantly. Frameworks like Next.js and Astro generate these automatically with a placeholder=”blur” prop. Real Before/After: Core Web Vitals Impact Here’s a snapshot from a Coding4 client e-commerce site we optimized earlier this year. Same pages, same content, only image handling changed: Metric Before After Improvement LCP 4.2s 1.1s -74% CLS 0.31 0.02 -94% Total page weight 4.8 MB 1.2 MB -75% PageSpeed score (mobile) 42 94 +52 pts The Image Optimization Checklist Before pushing any image to production, run through this list: Is it in AVIF or WebP with a JPEG fallback? Is it resized to the actual display dimensions? Does it have a srcset with multiple widths? Are width and height attributes set? Is below-the-fold content using loading=”lazy”? Is the LCP image preloaded with fetchpriority=”high”? Is it served through a CDN? Has metadata been stripped? Is the alt text descriptive (for accessibility and SEO)? FAQ Is PNG or JPEG better for SEO? Neither directly affects SEO, but JPEG (or better, WebP/AVIF) produces smaller files than PNG for photos, which improves page speed and therefore ranking. Reserve PNG for images that need transparency, and use SVG for logos and icons. What is the best image format for a website in 2026? AVIF is the best format for photos thanks to its superior compression. WebP is the safest universal default given its near-100% browser support. Use the <picture> element to serve both with a JPEG fallback. Does

Choosing a backend for your mobile app is one of those decisions that quietly shapes everything: your build speed, your monthly invoice, your ability to scale on launch day, and even how quickly you can hire help. If you have landed on the classic showdown of Firebase vs MongoDB, you are in the right place. This is a practical comparison written for indie developers and small startup teams who want a clear answer rather than a marketing pitch. At coding4.net, we have shipped mobile backends on both stacks. Here is how they actually compare in 2026, with the trade-offs we wish someone had told us upfront. Firebase vs MongoDB: The Short Answer Pick Firebase if you are a solo dev or small team building a mobile-first app that needs real-time sync, authentication, push notifications and offline support out of the box. Pick MongoDB (Atlas) if your app has complex queries, heavy analytics, multi-platform clients, or you expect to scale into millions of records where query flexibility and predictable cost matter. Now let’s dig into why. What Firebase and MongoDB Actually Are People often compare them as if they were the same thing. They are not. Firebase Firebase is a Backend-as-a-Service (BaaS) owned by Google. You don’t just get a database, you get a full ecosystem: Firestore or Realtime Database, Authentication, Cloud Functions, Cloud Messaging (FCM), Hosting, Remote Config, Crashlytics and Analytics. The database (Firestore) is a NoSQL document store, but it lives inside a wider serverless stack. MongoDB MongoDB is a document-oriented NoSQL database. With MongoDB Atlas, you get a managed cloud version that runs on AWS, Google Cloud or Azure. To make it a full mobile backend, you typically pair it with Atlas App Services (formerly Realm) or your own API layer (Node.js, Go, etc.). So really, the fair fight is Firebase (Firestore + Auth + Functions) versus MongoDB Atlas + App Services / a custom API. Side-by-Side Comparison Criteria Firebase MongoDB (Atlas) Type BaaS, serverless Managed NoSQL database Data model Documents in collections Documents (BSON) in collections Query power Limited, no joins, weak on complex filters Rich query language, aggregation pipeline, joins via $lookup Real-time sync Native, first-class Via change streams or App Services Sync Offline support (mobile) Built-in for Firestore Via Atlas Device Sync / Realm SDK Auth Firebase Authentication included Bring your own or use App Services Auth Pricing model Pay per read/write/delete + storage + bandwidth Pay per cluster size + storage + transfer Free tier Generous Spark plan Free M0 cluster (512 MB) Scaling Auto, transparent Manual or auto-scale tier, sharding available Vendor lock-in High (Google ecosystem) Low (MongoDB is open source) Best for MVPs, chat apps, social, live dashboards SaaS, e-commerce, analytics-heavy apps 1. Pricing: Where the Surprise Bills Come From This is where most indie devs get burned, so let’s be specific. Firebase pricing Firebase charges you per document read, write and delete, plus storage and outbound bandwidth. The free Spark plan is great for prototyping, but on the paid Blaze plan things get unpredictable. An infinite scroll list that re-reads documents every render? That’s thousands of reads per session. A real-time listener on a 500-document collection? Every change recounts toward your bill. Cloud Functions cold starts and invocations add up fast at scale. MongoDB Atlas pricing Atlas charges you per cluster (compute + RAM + storage). You know roughly what you will pay each month because it is tied to infrastructure, not user behavior. Free M0 tier for development. Shared clusters start around a few dollars per month. Dedicated clusters scale predictably as you grow. Bottom line: Firebase is cheaper at very low usage and during early validation. MongoDB becomes cheaper and more predictable once you have steady traffic, especially if your app does many reads per user. 2. Scalability Both scale, but differently. Firebase scales automatically. You don’t think about servers, regions or sharding. The trade-off is the per-operation cost and Firestore’s hard query limitations on large datasets. MongoDB scales horizontally with sharding and vertically by upgrading clusters. You have more control, which also means more responsibility. Atlas auto-scaling helps, but you still pick the strategy. If your roadmap involves complex aggregations over millions of documents (think feeds, search, recommendations), MongoDB will treat you better. Firestore queries are intentionally simple to keep things fast, but you will hit walls. 3. Real-Time Features This is Firebase’s home turf. Firestore and Realtime Database push changes to connected clients out of the box. You attach a listener and you are done. Perfect for chat, multiplayer, collaboration, live scores. MongoDB offers change streams, and through Atlas Device Sync you can get a similar experience, but you do more wiring. The mobile SDK (Realm) is excellent though. If real-time is the core feature of your app, Firebase will get you to market faster. 4. Offline Support Both stacks support offline-first mobile apps, but the developer experience differs. Firestore: Offline persistence is enabled by default on iOS and Android. Writes queue up, reads come from cache. It just works. MongoDB Realm / Atlas Device Sync: Realm is arguably the best mobile database on the market for offline-first apps. Sync conflicts, partial sync, and local queries are all handled cleanly. For a field worker app, a travel app, or anything where users go offline often, MongoDB + Realm is actually a stronger choice than Firestore in 2026. 5. Developer Experience Firebase DX Console is polished and beginner-friendly. SDKs for Flutter, React Native, iOS, Android, Web are mature. Authentication takes literally minutes to set up. Cloud Functions in Node.js or Python for custom logic. Less code to write to ship a v1. MongoDB DX You write more code, usually a Node.js, NestJS or Go API in front of Atlas. Query language is expressive once you learn it. Tooling (Compass, Atlas UI, Charts) is excellent. You own your architecture, which is great for long-term flexibility. For a solo developer racing toward an MVP, Firebase wins on speed. For a team of two or three planning to grow the

Shipping a Node.js application without an automated pipeline in 2026 is like driving a car without a seatbelt. It works, until it doesn’t. A well-configured CI/CD pipeline for Node.js catches bugs before they reach production, removes the manual “works on my machine” drama, and lets your team focus on building features instead of babysitting deployments. In this guide, we walk through the exact steps to set up a complete CI/CD pipeline for a Node.js application using GitHub Actions, including real YAML configurations, deployment to a cloud host, and the pitfalls most tutorials forget to mention. What You’ll Build By the end of this tutorial, you’ll have a pipeline that automatically: Runs on every push and pull request Installs dependencies with caching Lints your code Runs your test suite Builds your application Deploys to a cloud host (we’ll use a generic VPS/cloud server example) Prerequisites A Node.js project (version 20 LTS or 22 LTS recommended in 2026) A GitHub repository A cloud host (DigitalOcean, AWS EC2, Render, Railway, or similar) Basic knowledge of Git and the terminal Step 1: Understand the CI/CD Pipeline Stages Before writing a single line of YAML, let’s clarify what each stage does: Stage Purpose Tools Checkout Pull the code from the repo actions/checkout Install Install dependencies with caching actions/setup-node, npm/yarn/pnpm Lint Enforce code style ESLint, Biome Test Run unit and integration tests Jest, Vitest, Node test runner Build Compile TS or bundle assets tsc, esbuild, webpack Deploy Push to production SSH, Docker, cloud CLI Step 2: Prepare Your Node.js Project Make sure your package.json contains the scripts the pipeline will call: { “name”: “my-node-app”, “version”: “1.0.0”, “scripts”: { “start”: “node dist/index.js”, “dev”: “node –watch src/index.js”, “lint”: “eslint .”, “test”: “node –test”, “build”: “tsc” }, “engines”: { “node”: “>=20” } } Pro tip: The engines field is more than documentation. Some hosts and CI tools read it to determine the runtime version. Step 3: Create Your First GitHub Actions Workflow Inside your repository, create the folder .github/workflows/ and add a file named ci.yml: name: CI on: push: branches: [main, develop] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest strategy: matrix: node-version: [20.x, 22.x] steps: – name: Checkout code uses: actions/checkout@v4 – name: Setup Node.js ${{ matrix.node-version }} uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: ‘npm’ – name: Install dependencies run: npm ci – name: Run linter run: npm run lint – name: Run tests run: npm test – name: Build application run: npm run build What This Workflow Does Triggers on pushes to main/develop and on pull requests targeting main Tests against both Node 20 and 22 in parallel (the matrix strategy) Caches node_modules via the cache: ‘npm’ option, cutting build time significantly Uses npm ci instead of npm install for reproducible, lockfile-strict installs Step 4: Add Continuous Deployment Now let’s extend the pipeline to deploy automatically when code lands on main. Create a second workflow at .github/workflows/deploy.yml: name: Deploy to Production on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest needs: [] environment: production steps: – name: Checkout code uses: actions/checkout@v4 – name: Setup Node.js uses: actions/setup-node@v4 with: node-version: ’22.x’ cache: ‘npm’ – name: Install production dependencies run: npm ci – name: Build application run: npm run build – name: Deploy via SSH uses: appleboy/[email protected] with: host: ${{ secrets.SERVER_HOST }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SSH_PRIVATE_KEY }} script: | cd /var/www/my-node-app git pull origin main npm ci –omit=dev npm run build pm2 reload my-node-app Storing Secrets Safely Never hardcode credentials. In your GitHub repository, go to Settings > Secrets and variables > Actions and add: SERVER_HOST: your server IP or domain SERVER_USER: the SSH user (often deploy or ubuntu) SSH_PRIVATE_KEY: the private key paired with a public key on the server Step 5: Alternative Deploy Targets Not everyone runs their own VPS. Here are common alternatives: Deploy to Render or Railway Both platforms auto-deploy on push to your default branch. You only need the CI part of the workflow. Add a deploy hook URL as a secret and trigger it with curl: – name: Trigger Render deploy run: curl -X POST ${{ secrets.RENDER_DEPLOY_HOOK }} Deploy to AWS via Docker Build a Docker image, push to ECR, and update an ECS service or App Runner. This works well when you already containerize your app. Deploy to Vercel or Netlify For Node.js APIs running as serverless functions, the official Vercel/Netlify CLIs can be triggered directly inside the workflow. Step 6: Add a Status Badge Show off your green builds. Add this to your README.md:  Common Pitfalls to Avoid After helping dozens of teams set this up, here are the mistakes we see most often: Using npm install instead of npm ci: npm install can mutate your lockfile and introduce non-deterministic builds. Skipping the cache: Without dependency caching, every workflow run wastes 30 to 90 seconds reinstalling identical packages. Running tests against only one Node version: If your library or app supports multiple LTS versions, test them all in a matrix. Storing .env files in the repo: Use GitHub Secrets and inject env vars at runtime. No branch protection: Enforce that CI must pass before a PR can be merged. Configure this under Settings > Branches. Deploying without a health check: Always verify the app responds after deploy. A failed deploy that doesn’t roll back is worse than no deploy. Ignoring workflow concurrency: Use concurrency: to cancel in-progress runs when a new commit arrives. Saves CI minutes. Bonus: Concurrency Configuration concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true Going Further: Production-Grade Enhancements Add code coverage with c8 or nyc and upload to Codecov. Run security audits with npm audit –audit-level=high as a separate job. Use environments with required reviewers for production deploys. Implement blue-green or canary deployments if downtime matters. Add Slack or Discord notifications on deploy success/failure. Final Thoughts A solid CI/CD pipeline for a Node.js app isn’t just a nice-to-have in 2026. It’s the baseline. With GitHub Actions, you can go from zero to fully automated testing and deployment in under an hour. Start

SQL injection remains one of the most dangerous and most common vulnerabilities affecting PHP applications in 2026. Despite being well documented for over two decades, our security audits at Coding4 still uncover SQLi flaws in production codebases every single month. The good news: preventing SQL injection in PHP is straightforward once you know the right patterns. This practical guide walks you through 7 proven techniques to defend your PHP applications, with side-by-side vulnerable vs secure code examples so you can immediately spot and fix the issues in your own projects. What Is SQL Injection in PHP? SQL injection (SQLi) happens when an attacker is able to inject malicious SQL fragments into a query because user-supplied data is concatenated directly into the SQL string. The attacker can then read sensitive data, modify records, drop tables, or even gain remote code execution depending on database privileges. Here is the textbook example of a vulnerable PHP query: // VULNERABLE – never do this $username = $_POST[‘username’]; $password = $_POST[‘password’]; $sql = “SELECT * FROM users WHERE username = ‘$username’ AND password = ‘$password'”; $result = mysqli_query($conn, $sql); If a user submits ‘ OR ‘1’=’1 as the username, the resulting query becomes SELECT * FROM users WHERE username = ” OR ‘1’=’1′ AND password = ”, which authenticates the attacker without any valid credentials. Let’s fix this for good. 1. Use PDO With Prepared Statements (The Gold Standard) According to the official PHP manual and every security authority, the recommended way to prevent SQL injection is by binding all data via prepared statements. PDO (PHP Data Objects) gives you a clean, database-agnostic API to do exactly that. Vulnerable Code $id = $_GET[‘id’]; $pdo->query(“SELECT * FROM products WHERE id = $id”); Secure Code With PDO $dsn = ‘mysql:host=localhost;dbname=shop;charset=utf8mb4’; $pdo = new PDO($dsn, $user, $pass, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES => false, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, ]); $stmt = $pdo->prepare(‘SELECT * FROM products WHERE id = :id’); $stmt->execute([‘id’ => $_GET[‘id’]]); $product = $stmt->fetch(); The critical detail: set PDO::ATTR_EMULATE_PREPARES to false. With emulation enabled, PDO builds the query string itself, which weakens the protection. With it disabled, the query and parameters are sent separately to the database engine, making injection mathematically impossible. 2. Use MySQLi Prepared Statements If your project relies on the MySQLi extension, the principle is identical: separate the query structure from the data. Vulnerable Code $email = $_POST[’email’]; $result = mysqli_query($conn, “SELECT id FROM users WHERE email = ‘$email'”); Secure Code With MySQLi $stmt = $conn->prepare(‘SELECT id FROM users WHERE email = ?’); $stmt->bind_param(‘s’, $_POST[’email’]); $stmt->execute(); $result = $stmt->get_result(); $user = $result->fetch_assoc(); The type indicator string passed to bind_param() follows this mapping: Type Meaning s String i Integer d Double / float b Blob (sent in packets) 3. Validate and Sanitize User Input Prepared statements protect against injection, but input validation is your second line of defense and helps reject obviously malformed data before it ever reaches the database. Cast numeric IDs explicitly: $id = (int) $_GET[‘id’]; Use filter_var() for emails, URLs, IPs, and booleans Use allow-lists (whitelists) for values from a fixed set (e.g. sort order) Reject input that exceeds expected length Example: Validating a Sort Column // Column names cannot be bound as parameters, so use a whitelist $allowedSort = [‘name’, ‘price’, ‘created_at’]; $sort = in_array($_GET[‘sort’] ?? ”, $allowedSort, true) ? $_GET[‘sort’] : ‘name’; $stmt = $pdo->prepare(“SELECT * FROM products ORDER BY $sort LIMIT :limit”); $stmt->bindValue(‘:limit’, (int) ($_GET[‘limit’] ?? 20), PDO::PARAM_INT); $stmt->execute(); 4. Stop Using mysql_real_escape_string() as Your Only Defense The legacy mysql_* extension was removed back in PHP 7.0, but we still see codebases relying on mysqli_real_escape_string() as the sole protection. Escaping is fragile: it depends on the correct connection charset, it only works inside quoted strings, and it cannot protect identifiers or numeric contexts. Why Escaping Alone Fails // Looks safe, but it’s NOT $id = mysqli_real_escape_string($conn, $_GET[‘id’]); $sql = “SELECT * FROM users WHERE id = $id”; // unquoted numeric context // Attacker submits: 1 UNION SELECT password FROM admins // Escaping does nothing because there are no quotes to escape The fix is the same as always: use a prepared statement. Treat escaping as a legacy fallback only. 5. Use an ORM or Query Builder Modern PHP frameworks ship with battle-tested ORMs and query builders that produce parameterized SQL by default. If you are starting a new project in 2026, leverage them. Eloquent (Laravel) // Safe – values are bound automatically $user = User::where(’email’, $request->input(’email’))->first(); // Also safe with the query builder $products = DB::table(‘products’) ->where(‘category_id’, $categoryId) ->where(‘price’, ‘<‘, $maxPrice) ->get(); Doctrine DBAL $qb = $conn->createQueryBuilder(); $qb->select(‘*’) ->from(‘orders’) ->where(‘user_id = :uid’) ->setParameter(‘uid’, $userId); $orders = $qb->executeQuery()->fetchAllAssociative(); Warning: ORMs are not magic. Raw query methods like DB::raw() or whereRaw() bypass parameter binding. Always pass user data through bindings, never through string concatenation. // VULNERABLE even in Laravel DB::select(“SELECT * FROM users WHERE name = ‘”.$request->name.”‘”); // SECURE DB::select(‘SELECT * FROM users WHERE name = ?’, [$request->name]); 6. Apply the Principle of Least Privilege Even with bulletproof query code, you should harden the database account itself. If the worst happens, you want to limit the blast radius. Create a dedicated database user per application Grant only the minimum required privileges (SELECT, INSERT, UPDATE, DELETE on specific tables) Never run your app with root or DBA credentials Use a separate read-only account for reporting and analytics Disable FILE, EXECUTE, and SUPER privileges unless strictly necessary — Example: minimal MySQL user for a web app CREATE USER ‘webapp’@’10.0.%’ IDENTIFIED BY ‘strong_password_here’; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO ‘webapp’@’10.0.%’; FLUSH PRIVILEGES; 7. Add a WAF and Continuous Security Testing Defense in depth means your application is protected even if a single layer fails. In 2026 there is no excuse for skipping these: Web Application Firewall (WAF): Cloudflare, AWS WAF, or ModSecurity can block known SQLi payloads before they reach PHP Static analysis: Tools like Psalm, PHPStan with security plugins, or Snyk Code catch dangerous patterns in CI Dependency scanning: composer audit is built in since Composer 2.4; run it in every

After years of shipping production code and reviewing thousands of pull requests at coding4.net, we’ve noticed the same common web development mistakes show up again and again. The good news? Most of them are easy to fix once you can spot them. This isn’t a generic “make your site mobile-friendly” listicle. We’re going deeper, into the technical, workflow, and architectural traps that quietly destroy projects. Each mistake comes with a real fix and a code or workflow example you can apply today. Why These Mistakes Matter in 2026 Web development in 2026 is more demanding than ever. Core Web Vitals, accessibility regulations like the European Accessibility Act (now fully enforced), AI-assisted coding tools, and edge computing have raised the bar. Yet beginners and even mid-level devs keep falling into the same patterns. Let’s break them down. 1. Ignoring Accessibility Until the End Accessibility is treated as a final polish step, but by then it’s too late. Color contrast, semantic HTML, keyboard navigation, and ARIA labels need to be baked in from day one. The Fix Use semantic HTML elements and test with a screen reader weekly. <!– Bad –> <div onclick=”submit()”>Send</div> <!– Good –> <button type=”submit” aria-label=”Send contact form”>Send</button> Add axe-core or Pa11y to your CI pipeline so accessibility regressions break the build. 2. Poor Git Habits Commits like “fix stuff”, force-pushing to shared branches, or 2,000-line pull requests make collaboration painful and rollbacks impossible. The Fix Write atomic commits that do one thing Use Conventional Commits for clarity and automated changelogs Keep PRs under 400 lines when possible # Bad git commit -m “updates” # Good git commit -m “feat(auth): add password reset email flow” git commit -m “fix(cart): prevent negative quantity on update” 3. Skipping Tests “Because There’s No Time” You’ll spend ten times more debugging in production than you would have writing the test. This is the most expensive shortcut in software. The Fix Start with one test for any new feature. Build the habit, not perfection. Use Vitest or Jest for units and Playwright for end-to-end. // Vitest example import { describe, it, expect } from ‘vitest’; import { calculateTotal } from ‘./cart’; describe(‘calculateTotal’, () => { it(‘applies 10% discount above 100 EUR’, () => { expect(calculateTotal([{ price: 120 }])).toBe(108); }); }); 4. Over-Engineering Simple Problems Reaching for Redux, microservices, or a custom framework when a plain function would do. Complexity has a compounding cost. The Fix Apply the YAGNI principle (You Aren’t Gonna Need It). Start small, refactor when you have real pain. Situation Over-engineered Right-sized Toggle dark mode Redux store + middleware CSS variable + localStorage Contact form Custom backend with auth Serverless function or Formspree Small blog Headless CMS + microservices Static site generator 5. Not Handling Errors Properly Empty catch blocks, swallowed promises, and generic “Something went wrong” messages leave users frustrated and developers blind. The Fix // Bad try { await fetchUser(id); } catch (e) {} // Good try { await fetchUser(id); } catch (err) { logger.error({ err, userId: id }, ‘Failed to fetch user’); if (err.status === 404) return showNotFound(); showRetryToast(); } Pair this with a tool like Sentry for production error tracking. 6. Hardcoding Values and Secrets API keys in source code, magic numbers everywhere, and environment-specific URLs scattered through files. This is how leaks and “works on my machine” bugs happen. The Fix Use environment variables and a config layer. // .env API_URL=https://api.example.com STRIPE_KEY=sk_live_xxx // config.js export const config = { apiUrl: process.env.API_URL, stripeKey: process.env.STRIPE_KEY, }; Always add .env to your .gitignore and use a secret manager (AWS Secrets Manager, Doppler, Vault) in production. 7. Ignoring Performance Until It’s Broken Shipping 4MB of JavaScript on the homepage, unoptimized images, and no lazy loading. Then wondering why bounce rates are high. The Fix Run Lighthouse and WebPageTest before shipping Use modern formats: AVIF or WebP for images Code-split routes and lazy-load below-the-fold content Set a performance budget in CI (e.g. fail build if JS bundle > 200KB) <img src=”hero.avif” loading=”lazy” width=”1200″ height=”600″ alt=”Team collaborating”> 8. Forgetting Input Validation and Sanitization Trusting client-side validation, concatenating SQL strings, or rendering raw user HTML. These are the root causes of XSS and SQL injection in 2026, just like in 2010. The Fix Validate on both client and server. Use parameterized queries and schema validation libraries like Zod or Valibot. import { z } from ‘zod’; const UserSchema = z.object({ email: z.string().email(), age: z.number().int().min(13).max(120), }); const result = UserSchema.safeParse(req.body); if (!result.success) return res.status(400).json(result.error); 9. No Documentation, Not Even a README Future-you (or your replacement) will hate present-you. A repo without setup instructions is a time bomb. The Fix Every project should have a README answering: What does this project do? How do I install and run it locally? How do I deploy it? What are the environment variables? Who do I contact when it breaks? 10. Copy-Pasting AI-Generated Code Without Understanding It This is the new classic. AI assistants are powerful, but pasting code you don’t understand creates technical debt and security holes faster than ever. The Fix Read every line before committing Ask the AI to explain trade-offs and edge cases Run the code through linters, tests, and security scanners Verify dependencies actually exist and are maintained 11. Not Using a Linter or Formatter Inconsistent code style creates noise in PRs, hides real bugs, and slows reviews. The Fix Set up ESLint and Prettier on day one with a pre-commit hook via Husky and lint-staged. // package.json “lint-staged”: { “*.{js,ts,tsx}”: [“eslint –fix”, “prettier –write”] } 12. Treating SEO and Metadata as an Afterthought Missing meta tags, no Open Graph data, broken canonical URLs, and JavaScript-only rendering kill organic discoverability. The Fix <head> <title>Page Title – Brand</title> <meta name=”description” content=”Concise summary under 160 chars”> <link rel=”canonical” href=”https://coding4.net/page”> <meta property=”og:title” content=”Page Title”> <meta property=”og:image” content=”https://coding4.net/og.jpg”> <meta name=”twitter:card” content=”summary_large_image”> </head> Use server-side rendering or static generation when SEO matters. Test with Google Search Console and structured data validators. Quick Reference: All 12 Mistakes # Mistake Quick Fix 1 Ignoring accessibility Semantic HTML + axe-core