Forum Discussion
Architectural Feedback: Is SPFx + Azure Database a viable choice for an internal ticketing system?
Hi everyone,
I am currently evaluating the architecture for a new interdepartmental ticketing system and would love to get your feedback, real-world experiences, or best practices regarding our proposed approach.
Our goal is to centralize and streamline requests, tracking, and communication across various departments within the organization. We want to provide an intuitive interface that integrates seamlessly into our existing workplace (SharePoint Online / Microsoft Teams).
Proposed Architecture
Frontend / UI: Custom web parts developed using SPFx (SharePoint Framework), embedded into SharePoint pages and surfaced in Microsoft Teams.
Backend / Database: Azure Database for PostgreSQL for managing relational data, audit logs, complex ticket statuses, and SLA metrics.
Integration Layer: Custom REST APIs (hosted via Azure Functions / App Service) to handle transactions securely between SPFx and PostgreSQL
Rationale Behind This Choice
User Experience: SPFx provides a native look and feel within Microsoft 365, minimizing user onboarding friction.
Relational Data Complexity: We prefer PostgreSQL over standard SharePoint Lists due to data volume projections, complex relational data models, granular access control requirements per department, and advanced analytics needs.
Questions
- Architecture Viability: Do you consider using SPFx purely as a frontend consumer for external REST APIs connected to PostgreSQL a clean and sustainable pattern long-term?
- SharePoint Lists / Dataverse vs. External DB: Is the added overhead of maintaining a custom API + PostgreSQL in Azure justified, or would you strongly favor Dataverse or native SharePoint Lists for this specific use case?
- Authentication & Security: Any specific tips when securing SPFx calls to Azure API/Functions using Microsoft Entra ID (Azure AD) to ensure proper department-level data segregation?
- Maintenance & Governance: Are there any major maintenance, lifecycle, or performance bottlenecks we should prepare for when maintaining a hybrid SPFx + external DB solution?
Thanks in advance for any insights, lessons learned, or potential red flags!
1 Reply
SPFx as the user interface, an Entra-secured API, and PostgreSQL behind that API is a valid pattern. The web part should never connect directly to the database. Use SPFx AadHttpClient to call the registered API, validate tenant, issuer, audience, scopes, and user identity server-side, and enforce department authorization from trusted data rather than a client-supplied department value. Let the Function or App Service use managed identity and PostgreSQL Microsoft Entra authentication so no database secret reaches SPFx. Lists are preferable for simpler workflows and modest relationships; Dataverse is stronger when you need managed business rules, auditing, and role-based application security; PostgreSQL is justified for complex relational queries, volume, custom SLA processing, and SQL analytics. Budget for API versioning, database backup and high availability, private networking, telemetry, throttling, deployment pipelines, and supported SPFx/Node versions. Prototype authorization and expected ticket volume first, then compare operational cost and licensing with Dataverse before committing.
