A production-style .NET backend demonstrating REST + GraphQL parity, PostgreSQL-driven query logic, and clean architecture using Minimal APIs and Dapper.
This project demonstrates how REST and GraphQL can share the same repository layer and PostgreSQL functions, eliminating duplicated business logic while supporting multiple API paradigms.
“Different clients have different needs — the backend should adapt to them.”
This repository is the .NET / C# implementation of a multi-stack movie platform that shares a common PostgreSQL function layer with the Node.js API.
flowchart TD
subgraph UI["🎨 Frontend Layer"]
ReactUI["React Movie Dashboard<br/>Filtering • CRUD • API Toggle"]
end
subgraph API["⚙️ API Layer"]
DotNetAPI["DotNetMovieApi<br/>.NET Minimal APIs • C#<br/>REST + GraphQL"]
NodeAPI["NodeMovieApi<br/>TypeScript • Express<br/>REST + GraphQL"]
end
subgraph DATA["🐘 Data Platform Layer"]
Functions["PostgreSQL Function Layer<br/>Filtering • Paging • Sorting • CRUD"]
Tables["Relational Model<br/>movies • genres • movie_genres"]
end
ReactUI --> DotNetAPI
DotNetAPI --> Functions
Functions --> Tables
ReactUI -. Alternative implementation .-> NodeAPI
NodeAPI -. Shares same data layer .-> Functions
classDef frontend fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0f172a;
classDef primaryApi fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#0f172a;
classDef secondaryApi fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,color:#374151;
classDef data fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#0f172a;
class ReactUI frontend;
class DotNetAPI primaryApi;
class NodeAPI secondaryApi;
class Functions,Tables data;
sequenceDiagram
participant UI as React Dashboard
participant API as DotNetMovieApi
participant Repo as Repository Layer
participant PG as PostgreSQL Functions
UI->>API: REST or GraphQL request
alt REST
API->>API: Minimal API endpoint
else GraphQL
API->>API: GraphQL resolver
end
API->>Repo: Shared repository call
Repo->>PG: Execute PostgreSQL function
PG-->>Repo: Query results
Repo-->>API: Typed response
API-->>UI: JSON / GraphQL response
- .NET 10
- C#
- ASP.NET Core Minimal APIs
- Dapper
- PostgreSQL (
Npgsql) - Hot Chocolate GraphQL
- Swagger / Swashbuckle
This project uses ASP.NET Core Minimal APIs instead of traditional MVC controllers.
Minimal APIs help:
- reduce framework ceremony
- keep endpoint registration lightweight
- simplify routing configuration
- improve readability for focused APIs
- make endpoint composition easier to organize
The architecture still maintains separation of concerns through repository abstractions, service registration extensions, middleware organization, and PostgreSQL-backed query layers.
- REST and GraphQL endpoints over a shared repository layer
- Advanced filtering, sorting, and pagination powered by PostgreSQL functions
- Partial updates via GraphQL using JSONB patching
- Centralized logging, correlation IDs, and error handling
- Swagger UI for API exploration
Modern applications often need to support multiple API paradigms while sharing the same underlying business and query logic.
This project was built to demonstrate how ASP.NET Core Minimal APIs and GraphQL can coexist over a shared PostgreSQL-driven repository layer without duplicating filtering, paging, or CRUD workflows.
The goal was to showcase:
- reusable backend architecture
- centralized data access patterns
- API flexibility
- scalable query systems
- production-minded .NET application design
Rather than implementing separate business logic for REST and GraphQL, both interfaces share the same repository and PostgreSQL function layer, keeping the system predictable, maintainable, and easier to evolve.
GET /moviesGET /movies/{id}POST /moviesPUT /movies/{id}PATCH /movies/{id}DELETE /movies/{id}GET /genresGET /genres/{id}GET /health
👉 Swagger UI:
http://localhost:5000/swagger
GET /graphqlPOST /graphql
query {
movies(filters: { search: "avatar", searchMode: "general", page: 1, pageSize: 10 }) {
items {
id
movieName
releaseDate
genres
}
totalCount
totalPages
}
}- .NET 10 SDK
- PostgreSQL
dotnet restore
dotnet build
dotnet run- Demonstrates REST + GraphQL parity over a shared repository layer
- Uses PostgreSQL functions to centralize filtering, paging, and CRUD workflows
- Shows Minimal API architecture patterns with clean endpoint organization
- Supports reusable query logic across multiple backend implementations
- Designed with production-minded concerns including logging, correlation IDs, and error handling
This project emphasizes:
- centralized query logic
- reusable repository patterns
- API consistency across REST and GraphQL
- scalable filtering and pagination
- PostgreSQL-backed business logic
- separation of concerns
- predictable endpoint behavior
- maintainable Minimal API organization
The architecture is intentionally designed so backend implementations can evolve independently while the underlying data platform remains stable.
src/
├── Endpoints/ # REST endpoint mappings
├── GraphQL/ # GraphQL schema and resolvers
├── Repositories/ # Shared data access layer
├── Middleware/ # Logging and error handling
├── Models/ # DTOs and domain types
├── Infrastructure/ # PostgreSQL + Dapper integration
├── Extensions/ # Service and middleware registration
└── Program.cs # App entry point
React + TypeScript frontend application showcasing REST and GraphQL integration, advanced filtering, pagination, sorting, and reusable UI architecture. Project
Centralized PostgreSQL data platform featuring Dockerized infrastructure, overloaded SQL functions, reusable query architecture, and shared business logic powering multiple APIs and applications. Project
Node.js + TypeScript API implementation using Express and GraphQL Yoga, demonstrating reusable backend architecture and centralized data access patterns. Project
Production-minded Retrieval-Augmented Generation (RAG) application using OpenAI embeddings, semantic retrieval, and centralized AI orchestration workflows. Project
▶️ YouTube- 🌐 Portfolio
- 📧 Email: stevenwickers@gmail.com
Steven Wickers Senior Frontend Engineer
React • TypeScript • Node.js • C# • PostgreSQL • Cloud






