Polyglot Backend Architecture

This portfolio demonstrates how different backend languages can be used intentionally behind a single API gateway, based on workload characteristics rather than preference.

Try It Out

Interact with different backend implementations

Node.js

Framework: Fastify

API & integrations

Rapid iteration and a rich ecosystem for user-facing APIs.

Use Cases

•REST APIs
•BFFs
•Third-party integrations

Select Backend

Health Check

Verify backend service status

Contact Form

Send a message to the backend

Contact Demo

Sends POST /contact to the selected backend.

Name *

Email *

Message *

Architecture Overview

Understanding the system design

Next.js

Frontend

Traefik

API Gateway

Node.js

Fastify

net/http

PHP

Laravel

Rust

Axum

The frontend communicates with a single API gateway. Requests are routed by path prefix to multiple backend implementations, each written in a different language but conforming to the same API contract.

Design Decisions

Rationale behind architectural choices

Why a single API gateway?

The API gateway centralizes routing, prefix handling, and cross-cutting concerns, allowing backend services to remain simple and unaware of external URLs or clients.

Why a polyglot backend?

Different workloads benefit from different language strengths. This architecture allows each service to be implemented in the most suitable language without impacting the frontend or other services.

Why a shared API contract?

All backends expose the same endpoints and response shapes, enabling runtime switching and ensuring the frontend remains decoupled from implementation details.

Why keep backend routes prefix-free?

Backends do not know they are mounted behind/api/<service>. This responsibility belongs to the gateway, keeping services portable and easy to deploy independently.