A multi-service food product insights platform combining multi-tenant admin governance, emissions analytics, ingredient alternatives, and scenario tooling across React, Express, Postgres, and Python Azure Function Apps.
Executive Summary
Core Pattern
React UI + Node API boundary + Python analytics services
Data Strategy
Postgres + denormalized emissions read models + JSONB version history
Governance
Multi-tenant RBAC, soft delete lifecycle, admin-only category controls
Resilience
Proxy fallback handling and local Postgres compute paths
Overview
The Problem
Teams needed a single platform to manage product composition, maintain governed ingredient/emissions master data, and run emissions-driven comparisons and alternatives without exposing backend keys or fragmenting workflows across tools.
The Opportunity
Build a product-first admin platform that combines multi-tenant governance, auditable product versioning, and resilient emissions/alternatives analytics behind a secure API boundary.
My Role
Product architect and hands-on builder across system design, API patterns, data modeling, admin workflows, proxy/fallback strategy, and alignment of Python analytics services with the Postgres-backed platform.
Key Constraints
Architecture Decisions
Deovise uses a pragmatic split between the admin application, the Node API, and Python analytics services. The Node layer is not just CRUD middleware; it acts as the security and resiliency boundary for analytics integrations.
Frontend Web App
React 18 (CRA) + MUI 7 with MUI X Data Grid Pro for admin-heavy CRUD, table workflows, and inline detail/compare views. Redux Toolkit manages global state with persisted auth/user/UI mode.
Node API Boundary
Express API with CORS, Helmet, Morgan, JSON parsing, centralized 404/error handling, JWT middleware, role checks, and proxy routes that keep Function App keys private from the browser.
Postgres Data Layer
Primary datastore via pg, wrapped in a small abstraction that supports MSSQL-like @param query ergonomics while safely binding Postgres positional params, plus a lightweight transaction helper.
Python Function Services
Azure Function Apps for emissions aggregation and category-based ingredient alternatives, implemented with SQLAlchemy + pandas, reading Postgres credentials from environment variables.
Request / Compute Flow
Why These Decisions
Security boundary at Express
Why: Function keys remain server-side and client integrations stay stable even if analytics endpoints move.
Impact: Improves security posture and allows fallback logic/caching in one place.
JSONB snapshots for product versioning
Why: Version history needed to be auditable, diffable, and restorable without brittle per-field patch logic.
Impact: Enabled restore flows and structured diffs with transaction-safe writes.
Denormalized emissions views
Why: Emissions reads and comparisons are repeated, analytics-heavy workloads that benefit from optimized read models.
Impact: Reduced query complexity and improved practical responsiveness for grid/compare workflows.
Soft-delete lifecycle pattern
Why: Admin systems need reversibility, governance, and clean auditability across entities.
Impact: Consistent behaviour across organisations, users, roles, categories, and master data.
Cached role and mapping lookups
Why: Role checks and subcategory mapping resolution were repeated frequently in admin and emissions flows.
Impact: Lower DB roundtrips while keeping authorization and mapping logic centralized.
Postgres-first migration path
Why: Some ancillary tooling historically assumed Azure SQL/Key Vault, but platform direction aligned around Postgres + env-driven secrets.
Impact: Cleaner operational model and more consistent local/dev/deploy parity.
Key Features
The platform combines standard admin capabilities with domain-specific emissions and alternatives tooling. The important part is how these workflows connect across governance, composition data, and analytics.
JWT login, admin-mediated user registration, password reset tokens with generic initiation responses, and Gmail OAuth2 email delivery with branded templates.
Organisations, users, roles, and user-role assignments with soft delete and role-aware filtering behaviour.
Scoped product CRUD with category hierarchy tagging and ingredient composition percentages, returned via server-built snapshots for consistent responses.
Dedicated product_version table with JSONB snapshot + changes, structured diffing, and restore support built around transactions.
Grid-style master data workflows for ingredients/emissions with subcategory normalization, country resolution helpers, and org/system scope rules.
3-level product and ingredient category hierarchies with admin-only mutation, soft delete + reassignment, and ingredient swap mappings for alternatives logic.
Express proxy under /emissions-data/* injects keys and forwards to Python services, with path/URL fallbacks and local Postgres compute fallback when functions are unavailable.
Product library emissions views, compare flows, expanded details, and client-managed swap scenario state with graceful degradation in partially deployed environments.
Python function apps, scenario composer tooling, notebooks, and a Streamlit upload helper for ingestion validation, fuzzy matching, and repeatable mapping workflows.
Tradeoffs & Constraints
The platform decisions prioritized secure integration boundaries, operator usability, and resilient analytics workflows. That required accepting some complexity in the API and data layers.
CRA frontend vs immediate Next.js migration
Rationale: CRA allowed fast delivery of admin-heavy workflows with MUI Data Grid Pro while architecture effort focused on data/model reliability and analytics integration.
Tradeoff: SSR/SEO is not a priority benefit for internal/admin workflows, but migration to Next would later improve app shell consistency and deployment ergonomics.
Proxy + fallback complexity vs direct function calls
Rationale: Centralizing function access in Express protects keys and enables resiliency patterns that client apps should not own.
Tradeoff: More server code and operational paths to test, but significantly better security and failure handling.
Denormalized read models vs pure normalized queries
Rationale: Emissions analytics and compare flows are read-heavy and repeated; denormalized views simplify query logic and improve response times.
Tradeoff: Higher maintenance burden on data definitions and validation, but improved UX for data-heavy screens.
Soft delete everywhere vs hard delete simplicity
Rationale: Admin/governance systems benefit from reversibility and audit context, especially with dependent category/product relationships.
Tradeoff: Extra filtering and lifecycle logic across endpoints, but safer operational behaviour.
Outcomes / Metrics
This portfolio version emphasizes architecture and delivery signals. Quantitative metrics are not publicly disclosed here, but the implementation outcomes and quality signals below reflect production-minded engineering decisions.
Outcomes / Delivery Signals
Testing & Quality Signals
What I'd Improve Next
The platform foundation is strong. The next gains come from contract consistency across services, deeper observability, and sharper product analytics on scenario usage and outcomes.
Expand public case-study metrics once acceptable commercial disclosure boundaries are defined.
Complete migration alignment for all ancillary tooling to Postgres + env-driven secrets.
Formalize API contracts/shared schemas across Node and Python services to reduce drift.
Add deeper observability on proxy fallback frequency and analytics endpoint performance.
Continue extracting reusable product/admin domain modules as the platform footprint grows.
Contact
I work best on product platforms where data models, delivery constraints, and system boundaries matter as much as UI polish.