Engineering proof

Bz Info is not only a portfolio. It is a verifiable product system.

This page exposes the technical logic behind the platform: web architecture, NestJS backend, quality, tests, operations, SEO, i18n and delivery discipline.

Husky pre-pushESLint + Prettierportfolio-api/test9 quality phasesmodule runners.reports output

Generated pages

714

Static pages generated after expertise, tools and localized routes were added.

Active languages

French, English, Arabic, Spanish, German and Dutch with dedicated routes.

Quality chain

Typecheck + Build

Systematic frontend validation before freezing changes.

Backend quality is module-owned.

Each serious module can expose its own perf, contract, unit, integration, E2E, smoke, security and mutation phases.

System map

A platform designed as a complete product.

The proof does not come from one page. It comes from the whole system: public website, API, admin, documentation, tools, localized content and quality.

01 · Visible

Public web

Next.js, localized routes, SEO, sitemap, expertise pages and documentation.

02 · Architecture

Backend API

NestJS API for contact, chatbot, analytics, communication and product workflows.

03 · Operations

Admin system

Future supervision for requests, conversations, logs, statistics and operations.

04 · Expansion

Tools lab

Developer packs, scripts, transactional SMS gateway and local AI workstation.

Backend proof

The backend is treated as the product backbone.

The goal is to show the ability to structure modules, contracts, validation, domain flows, security and integrations without turning the project into a fragile showcase.

NestJS

Modular architecture

Modules, services, DTOs, guards, validation and maintainable API contracts.

Prisma

Controlled persistence

Models, transactions, constraints and clear separation between domain and storage.

Realtime

Live flows

Chat, support, notifications and admin interfaces connected to real system state.

Communication

Email, SMS and notifications

Transactional channels designed with limits, logs, security and precise usage.

HTTP request

Controller receives a public operation through a documented route.

DTO validation

class-validator, Swagger metadata and ValidationPipe must stay aligned.

Guard / auth

Access rules, JWT context, throttling and role checks protect the boundary.

Service decision

Business rules are isolated, testable and protected by explicit branches.

Prisma / storage

Transactions, constraints and persistence shape are verified by tests.

Reports

Schemathesis, smoke, ZAP, k6 and Stryker expose behavior from outside.

Backend methodology

A progressive method that works across frameworks.

NestJS, Spring Boot, Python, Go or .NET: the principle stays the same. Understand, lock, improve, measure, harden and document.

Reconnaissance

Read routes, DTOs, guards, services, database access, errors and public contracts.

Understand the system before changing it.

Light refactor

Clarify responsibilities without rewriting the product or breaking existing behavior.

Reduce debt without creating a risky migration.

Basic tests

Lock existing behavior with simple but useful tests.

Create a safety net before deeper corrections.

Deep tests

Test branches, errors, boundaries, transactions, null, undefined and exception paths.

Attack blind spots that superficial tests ignore.

Integration & E2E

Validate real boundaries between API, authentication, database and services.

Prove behavior outside isolation.

Performance

Measure latency, concurrency, database contention, N+1 patterns, throttling, memory and slow paths.

Find what breaks when the backend is no longer alone.

Contract testing

Use OpenAPI and Schemathesis to confront the public contract with real behavior.

Fix DTOs, Swagger, ValidationPipe and documented responses.

Runtime security

Add smoke checks, ZAP, logs and runtime verification around exposed behavior.

Observe the system as it really runs.

Mutation testing

100% coverage is not enough; Stryker verifies that assertions truly protect behavior.

portfolio-api/test

Module-by-module quality factory

Each backend module owns the same quality surface, from contract checks to mutation testing, with a dedicated global runner and local README.

01-perf

Load, latency and concurrency baseline.

02-schemathesis

OpenAPI contract attack against real endpoints.

03-unit

DTOs, services, guards, modules and branch decisions.

04-integration

Database, providers and cross-service boundaries.

05-e2e

Real API flows through the application surface.

06-smoke

Runtime availability and critical path sanity checks.

07-zap

Basic exposed security signals.

08-mutation

Stryker mutation strength and test robustness.

Sample modules already shaped with this convention

admin-authadmin-dashboardadmin-supportaudit-logschatchatbotcontacthealthleadsmonitoringnotifications

test/<module>/
├── 01-perf
├── 02-schemathesis
├── 03-unit
├── 04-integration
├── 05-e2e
├── 06-smoke
├── 07-zap
├── 08-mutation
├── scripts/run-<module>-global.sh
└── README.md

bash

Global module runner

One command can run the module quality chain with explicit toggles.

MODULE_NAME="admin-auth"RUN_ADMIN_AUTH_SCHEMATHESIS="${RUN_ADMIN_AUTH_SCHEMATHESIS:-true}"RUN_ADMIN_AUTH_SMOKE="${RUN_ADMIN_AUTH_SMOKE:-true}"RUN_ADMIN_AUTH_UNIT="${RUN_ADMIN_AUTH_UNIT:-true}"RUN_ADMIN_AUTH_INTEGRATION="${RUN_ADMIN_AUTH_INTEGRATION:-true}"RUN_ADMIN_AUTH_E2E="${RUN_ADMIN_AUTH_E2E:-true}"RUN_ADMIN_AUTH_MUTATION="${RUN_ADMIN_AUTH_MUTATION:-true}"

bash

Schemathesis contract attack

OpenAPI is fetched from the running API, then attacked in Docker.

SCHEMA_FETCH_URL="${SCHEMA_FETCH_URL:-http://localhost:4002/api/docs-json}"SCHEMATHESIS_BASE_URL="${SCHEMATHESIS_BASE_URL:-http://host.docker.internal:4002}"SCHEMATHESIS_PATH_REGEX="${SCHEMATHESIS_PATH_REGEX:-^/api/v1/admin/auth/(login|refresh|logout|me)$}"docker run --rm --add-host=host.docker.internal:host-gateway \  ghcr.io/schemathesis/schemathesis:stable run openapi-admin-auth.json

json

Stryker mutation gate

Mutation score is a hard quality threshold, not a vanity metric.

{  "testRunner": "jest",  "mutate": ["src/modules/admin-auth/**/*.ts"],  "coverageAnalysis": "perTest",  "thresholds": {    "high": 100,    "low": 100,    "break": 100  }}

javascript

k6 health baseline

Performance tests expose latency and failure-rate risks outside unit isolation.

export const options = {  thresholds: {    http_req_failed: ["rate<0.01"],    checks: ["rate>0.99"],    "http_req_duration{endpoint:health}": ["p(95)<250", "p(99)<500"],  },};

Tool → risk

Each tool attacks a different category of risk.

The quality chain is not a stack of logos. Each step has a precise reason and covers an angle the others do not cover.

TypeScript

Static mistakes

Detects type inconsistencies before runtime, especially in DTOs, services and internal contracts.

Unit tests

Fragile business decisions

Lock important rules, branches, errors and isolated edge cases.

Integration tests

Invisible boundaries

Verify interactions between services, transactions, database and internal dependencies.

E2E tests

Incomplete API flows

Validate real flows from the endpoint to the expected product behavior.

Load and concurrency

Exposes latency, locks, N+1 patterns, contention and behavior that isolated tests do not reveal.

Schemathesis

Wrong OpenAPI contract

Reveals mismatches between Swagger, DTOs, ValidationPipe, HTTP statuses and real responses.

ZAP

Exposed runtime surface

Finds basic security signals visible from outside the system.

Stryker

Weak tests

Proves whether the test suite actually detects behavioral mutations.

Confidence model

Confidence grows when multiple risks are attacked.

This chart is a teaching model, not a scientific statistic. It shows how confidence increases when validation covers more angles.

Static

20%

The code compiles and obvious mistakes are reduced.

Unit

38%

Key business decisions start to be locked.

Integration

55%

Service/database/API boundaries become safer.

E2E

68%

Real user-facing flows are validated end to end.

Contract

80%

The public contract is automatically attacked.

Runtime

88%

Performance, smoke and runtime security add a real-world view.

Mutation

95%

The test suite proves it can detect dangerous changes.

Quality pipeline

Quality is a chain, not decoration.

Each step reduces a category of risk: typing, contract, business behavior, runtime, security or test robustness.

Static confidence

Check typing, formatting, conventions and obvious errors before runtime.

TypeScriptESLintPrettierBuild

Behavior confidence

Test business decisions, integrations and end-to-end user paths.

UnitIntegrationE2ESmoke

Contract confidence

Attack API contracts and verify that documentation reflects real behavior.

OpenAPISchemathesisSwaggerDTO validation

Hardening confidence

Actively look for weaknesses instead of stopping at a green build.

StrykerZAPk6Audit logs

What this proves

The value is in repeated discipline.

This page does not claim abstract perfection. It shows a method: structure, verify, document, localize, measure and refactor when a limit appears.

Readable architecture

Pages, content, components and routes are separated to stay maintainable.

Real refactoring

Oversized files are split instead of being accepted as silent debt.

Verifiable SEO

Sitemap, canonical, hreflang and localized routes are treated as public contracts.

Proof through product

The site itself demonstrates the expected level: content, UI, architecture and validation.

Usable proof

A technical discussion can start from concrete proof, not only claims.

For a backend mission, technical recovery or product platform, this page acts as a technical entry point.

Discuss the need View documentation