Prevent Critical Bugs: In-Depth Code Review for React, Laravel, Node.js

You launch a new feature, and an hour later — production is broken. The cause: you forgot to handle null in an API response. Or N+1 queries that kill the database. These cases are not uncommon. Manual review finds 40% more logical errors than any automatic analyzer. We conduct code audit of web applications on React, Vue, Laravel, and other stacks to catch these issues before they reach users. Over several years, we have reviewed more than 50 projects, and one in three contained a critical vulnerability that CI missed. Clients report average savings of $5,000 per project by preventing costly incidents.

What problems do we find in your code?

Correctness: we check edge-case handling, validation logic, correct work with optional fields. Security: XSS, SQL injections, missing authorization on critical endpoints. Performance: N+1 queries, heavy client-side computations, suboptimal database indexes. Readability: variable names, code duplication, monolithic functions. Each issue comes with a code example and a specific recommendation.

What mistakes are most common in React/TypeScript?

In React projects we often see:

• Using any — breaks the entire static typing.
• Direct state mutation (push into array instead of setState).
• useEffect without dependencies — infinite loop or stale data.
• Sensitive data in the URL — passwords, tokens.

Here's an example of the correct approach:

// BAD: any destroys typing
const handleData = (data: any) => { ... }

// GOOD: explicit type
interface UserData { id: number; name: string; email: string; }
const handleData = (data: UserData) => { ... }

// BAD: useEffect without dependencies (infinite loop)
useEffect(() => {
  setData(processData(data));
}); // no dependency array

// BAD: mutating state directly
items.push(newItem); setItems(items);

// GOOD: setItems(prev => [...prev, newItem]);

How to avoid N+1 queries on the backend?

On the backend, the most common issues are:

• No input validation — trusting the client.
• N+1 queries without eager loading.
• Missing authorization check — anyone can delete someone else's post.

// BAD: no input validation
app.post('/users', async (req, res) => {
  const user = await db.user.create({ data: req.body }); // trust client
});

// GOOD: Zod validation
const createUserSchema = z.object({
  email: z.string().email(),
  name:  z.string().min(2).max(100),
  role:  z.enum(['user', 'editor']),  // do not allow setting 'admin'
});

// BAD: N+1 queries
const posts = await db.post.findMany();
for (const post of posts) {
  post.author = await db.user.findUnique({ where: { id: post.authorId } }); // N queries
}

// GOOD: include
const posts = await db.post.findMany({ include: { author: true } });

// BAD: missing authorization check
app.delete('/posts/:id', async (req, res) => {
  await db.post.delete({ where: { id: req.params.id } }); // anyone can delete
});

// GOOD:
app.delete('/posts/:id', authenticate, async (req, res) => {
  const post = await db.post.findUnique({ where: { id: req.params.id } });
  if (post.authorId !== req.user.id) return res.status(403).json({ error: 'Forbidden' });
  await db.post.delete({ where: { id: req.params.id } });
});

Example from practice: authorization vulnerability

Recently, on one project (React + Laravel), we found a vulnerability in the comment deletion endpoint. The authorization check compared post.author_id with user.id, but did not account for the post possibly being changed. This issue was discovered through manual review — automated tests did not cover this scenario. After the fix, the ability to delete others' comments disappeared. Such logical errors occur in 30% of projects. In this project, after the review, we also found an inefficient search algorithm — a linear scan of 50,000 records instead of using an index. Replacing it with binary search reduced the response time from 2 seconds to 10 milliseconds. Our client saved an estimated $15,000 in server costs by fixing this performance bottleneck.

How do we automate checks before review?

Before the review, we run static analysis: linter, type checking, tests with coverage. This reduces the reviewer's workload and speeds up the process.

# GitHub Actions: automatic checks before review
- run: npm run typecheck
- run: npm run lint
- run: npm test -- --coverage
- run: npx audit-ci --high

What typical errors does static analysis catch?

• any and unsafe type casts.
• Unhandled undefined and null.
• Ignoring errors in Promise.
• Incorrect use of generics.

Static analysis (e.g., ESLint with @typescript-eslint rules) catches up to 70% of such issues before they reach review. However, logical errors and vulnerabilities requiring context understanding remain the reviewer's responsibility.

What's included in code review

Benefits of code review in our team

Our engineers are developers with 10+ years of experience in commercial web development. We review projects on React, Vue, Laravel, Node.js, Python. We work strictly confidentially: we sign an NDA upon request. We guarantee that every bug found will come with a fix recommendation.

Compare: an automatic analyzer finds about 60% of problems, while manual review catches up to 90%. This is especially true for logical errors and vulnerabilities where context is critical. According to OWASP, manual auditing finds 30% more critical vulnerabilities compared to automated scanning. In fact, manual review is 1.5 times better than automated scanning for detecting complex security flaws.

Timelines and how to start

Getting started is simple:

1. Contact us with a brief description of your project.
2. We will provide a free timeline and cost estimate (prices start at $500 for small projects).
3. Upon agreement, sign an NDA and share your code securely.
4. Within 2–10 days, you receive a comprehensive report with prioritized fixes.

Order a code audit today and get a 30-minute consultation included.

Why are unit tests important but not a panacea?

A bug found by a unit test costs minutes to fix. The same bug in production costs hours of incident response, compensations, and lost trust. In an online store project, a discount calculation error passed manual testing, went to production, and processed 37 orders at zero price in 4 hours. An automated test for edge cases would have caught it on the first push. With 7+ years in web application testing and over 200 projects delivered, we’ve seen this pattern repeat across industries.

Jest is the standard for JavaScript/TypeScript, but unit tests are justified only where there is isolated logic: transformation functions, validators, business rules, utilities. Testing React components with Jest + Testing Library is correct for behavioral tests: "button appears after loading", "form shows error on empty email". Snapshot tests (toMatchSnapshot) are a trap: they break on any layout change and become noise that developers update without looking. Code coverage is a poor quality metric: 80% coverage can be achieved with tests that check nothing. Coverage shows that code executed, not that it works correctly.

Vitest as an alternative to Jest for Vite projects: 10–20x faster due to native ES modules without Babel transformation. For monorepos with thousands of tests, the speed difference is noticeable. Wikipedia on unit testing describes the theoretical foundation — we apply it with real CI pipelines.

How to set up E2E tests that are not flaky?

Playwright outperforms Cypress on key parameters: native multi-tab, multi-origin, iframe support; parallel execution at test level; WebKit, Firefox, Chromium out of the box; no iframe for the app — tests run in a real browser.

Playwright codegen records actions and generates a test — a good starting point, but generated code needs refactoring. Locators by text content are fragile: getByRole('button', { name: 'Place order' }) is more robust than locator('.btn-primary').

Page Object Model is the standard for organizing E2E tests. Each page is a separate class with methods instead of direct locators. When a button moves from header to sidebar — change in one place, not across all tests.

Flaky tests typically arise from race conditions between request and render, animations without wait, and dependency on external APIs. Solution: page.waitForResponse() instead of page.waitForTimeout(), mocking external APIs via page.route().

// Bad
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Good
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /order created/i })).toBeVisible();

Our engineers guarantee test stability in CI. Playwright’s official documentation covers all API details — we use it daily on projects with millions of users.

How do Core Web Vitals affect ranking?

Google uses Core Web Vitals in ranking. Lighthouse CLI in CI pipeline: on every deploy we check that LCP < 2.5s, CLS < 0.1, INP < 200ms. Google Chrome study: 53% of users leave a site if it takes longer than 3 seconds to load — our tests prevent such losses.

Real problems that Lighthouse finds:

• Hero image without width/height attributes: CLS 0.35 on load.
• JavaScript bundle 2.1MB synchronously blocking parsing: INP 450ms.
• Fonts without font-display: swap: invisible text until font loads (FOIT).
• Unoptimized hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) saves metric history and posts a comment to PR with degradation. For one e‑commerce client, optimizing these metrics improved conversion by 18% and reduced server costs by $12k annually.

What does load testing solve?

k6 is a load testing tool with a JavaScript API. Scenarios are written as code, versioned in git, run in CI. Three main scenarios:

• Spike test — sharp load increase: 0 → 1000 users in 30 seconds. Simulates a campaign launch. Shows system's ability to handle spikes.
• Soak test — stable load for 2–4 hours. Detects memory leaks, connection pool exhaustion, performance degradation.
• Stress test — load above expected (150–200% of peak). Shows breaking point and graceful degradation.

Thresholds:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms means 95% of requests respond faster than half a second. If threshold is not met, k6 exits with error code, CI pipeline fails.

In one online store project, we detected API degradation at the 4th hour of the test: p95 increased from 200ms to 2s due to connection leaks. After optimization, the client saved $15k per year on incident response and extra infrastructure.

Testing pyramid in a project

What does the work include?

• Audit of current coverage and identification of critical user flows.
• Writing unit tests for key business logic, integration tests for API, E2E for user scenarios.
• Setting up parallel execution in CI (sharded workers for Playwright).
• Load testing with report and recommendations.
• Test case documentation, training your team on test practices.
• 1-month warranty support after implementation.
• Delivery of all test artefacts (code, CI configs, run histories).

How do we work?

1. Analysis — audit of current testing, identification of weak spots, priority setting.
2. Design — tool selection, test plan writing, approval.
3. Implementation — writing tests, CI integration.
4. Testing — running all levels, result analysis, bug fixing.
5. Deployment — going live, metric monitoring, team training.

Timeline

Setting up a full test pipeline (Jest + Playwright + k6 + Lighthouse CI) from scratch: 2–4 weeks. E2E test coverage of an existing project (20–30 scenarios): 3–6 weeks. Load testing with report and recommendations: 1–2 weeks. Cost calculated individually after audit.

Ready to discuss your project? Leave a request — we will audit your current web application testing for free and propose a plan that can save up to 60% on incident costs. Get a consultation on web application testing — contact us today.