Skip to content
Almathal Handbook

ADR-0025: Java + TS/JS + Python Used Per Concern

Accepted

Date: 2026-06-10

Context

A polyglot Component Library multiplies curation effort but reflects how real enterprises actually build software. A monoglot library would force unnatural choices (Java data pipelines, Python frontends) that don’t match real-world practice.

Decision

The MVP supports three languages, each used where strongest:

  • Java — primary backend language. Spring Boot, JPA, security, messaging. Enterprise-aligned.
  • TypeScript / JavaScript — primary frontend language. React, Next.js, Tailwind, shadcn/ui.
  • Python — primary for data and AI workloads. FastAPI for AI/data services, pandas, ETL, ML, embedding pipelines.

An Archetype picks the language per concern, not per app. A typical generated app might be Java backend + React frontend + Python data ingestion service.

Cross-language seams (API contracts, queue messages, gRPC) are first-class Layer 1 concerns.

Rationale

  • Matches real-world enterprise practice; generated apps look like what their teams would write.
  • Each language slice’s Component Library can be smaller and more focused than a one-language-everywhere approach would require.
  • Cross-language coordination is well-understood (OpenAPI, gRPC, async messaging) — manageable.
  • Java aligns with the platform team’s reported strength (a 20-year Java architect leading); production velocity is high.

Consequences

  • Curation effort across three slices is ~3x a single-slice approach, partially offset by smaller per-slice scope.
  • Cross-language Adapters (Java-to-Python gRPC, OpenAPI-driven TS clients) become first-class library entries.
  • Archetypes that span languages need explicit cross-language seam contracts.
  • Future expansion to other languages (Go, Rust, C#) is possible but deferred past MVP.

References