AppGrape ERP Builder

AppGrape Studio is a low-code platform for building custom business applications (ERP). The platform evolved from our internal code base and architecture used to deliver software consultancy projects. In this article, I will briefly outline its architecture and key aspects.

Architectural Summary

The architecture is built on three main pillars, utilizing a metadata-driven approach where the database dictates both the data structure and the application's UI layout.

1. Frontend (AppGrape Studio & appgrape-ui)

The frontend layer is built with React and TypeScript, functioning as a dynamic, schema-driven interface engine.

• AppGrape Studio serves as the dashboard boilerplate and the main client-facing application shell.
• appgrape-ui is our modular component library that automatically generates tables, forms, and complex relationship dropdowns (like 1:M and M:M mappings) based on the database's configuration, drastically reducing frontend boilerplate. All access to the database is done using the Supabase JS Client which natively respects the RLS policies.

I consider building appgrape-ui library in the most modular way as the defining feature of this platform. I will elaborate on this in a separate blog post.

2. Core Infrastructure (Self-hosted Supabase & PostgreSQL)

This is the foundation of the platform, handling all data persistence, automated API routing, and state management. PostgreSQL acts as the absolute source of truth, heavily augmented by Supabase's microservices. Some of the key aspects of this foundation are:

• Schema-Based Multi-Tenancy
  • The platform achieves strict data isolation for SME clients by utilizing a schema-per-tenant architecture. This allows multiple organizations to safely share a single PostgreSQL instance without any risk of data bleed.
• Standard Create, Read, Update, and Delete operations completely bypass the need for traditional API routes. The frontend and backend interact directly with PostgreSQL via Supabase's instant REST API (via PostgREST), ensuring high-speed data access.
• Security is strictly enforced directly at the database layer by Row Level Security (RLS) polciies. Every single request, whether originating from the frontend or the custom FastAPI backend, must authenticate through PostgreSQL's RLS policies using the client's JWT, guaranteeing a zero-trust environment.
• PostgreSQL serves as the brain of the platform. Custom SQL functions hold the core application logic—driving the metadata engine (generating UI schemas on the fly), enforcing tenant isolation protocols, and executing the bulk of the business logic.
• When a database schema or configuration changes, Supabase Realtime broadcasts these updates immediately to the frontend. This ensures the dynamically generated UI is always perfectly in sync with the database's current state. This greatly improves the developer experience when building a custom business app.
• Secure & Isolated Storage
  • File and document storage is deeply integrated with the database architecture. Access to attachments (like PDFs or images) is governed by the exact same RLS policies and tenant isolation rules as the tabular data, ensuring all client assets are securely partitioned.

3. Custom Backend (FastAPI / Python)

We have a persistent, heavy-compute backend integrated directly into the self-hosted Supabase ecosystem. Note that all of the CRUD operations and business logic processes are carried out by Supabase REST API and RPC calls to SQL functions. The Python backend only handles long-running background tasks that serverless functions can't, such as dynamic PDF document generation and asynchronous bulk WhatsApp dispatches. Some key features of this approach are:

• Zero-Trust Security: The FastAPI service does not connect directly to the database. Instead, it receives requests from the frontend and securely routes its operations back through Supabase's Auth and REST API layers (using Supabase Python Client).
• RLS Enforcement: By querying the database using the client's JWT, the Python backend strictly adheres to PostgreSQL Row Level Security (RLS) policies.
• While we do not use an ORM here, we still use Pydantic models automatically generated by Supabase CLI which provides type safety and convenience during data manipulation. It also remains automatically in sync with our database.

This structure allows the platform to remain incredibly lean, offloading security, routing, and real-time syncing to the database layer instead of reinventing those wheels in the frontend or Python backend. The architecture also enables the rapid development speed of a low-code platform while retaining the raw compute power and strict security of a custom enterprise backend.