https://github.com/danielmackay/dotnet-clean-architecture-graphql
https://github.com/danielmackay/dotnet-clean-architecture-graphql
clean-architecture graphql
Last synced: over 1 year ago
JSON representation
- Host: GitHub
- URL: https://github.com/danielmackay/dotnet-clean-architecture-graphql
- Owner: danielmackay
- License: mit
- Created: 2023-02-13T12:13:09.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2023-12-01T06:06:32.000Z (over 2 years ago)
- Last Synced: 2024-06-10T05:33:40.600Z (almost 2 years ago)
- Topics: clean-architecture, graphql
- Language: C#
- Homepage:
- Size: 374 KB
- Stars: 7
- Watchers: 3
- Forks: 1
- Open Issues: 7
-
Metadata Files:
- Readme: README.md
- License: LICENSE.txt
Awesome Lists containing this project
README
# dotnet-clean-architecture-graphql
## Introduction
This project is an example implementation of Clean Architecture principles using GraphQL. The goal is to demonstrate how Clean Architecture can be used to create a scalable and maintainable application with a flexible and efficient GraphQL API.
## Features
- Queries
- Paging
- Sorting
- Filtering
- Projections
- Mutations
- Create
- Update
- Delete
- Fluent Validation
## Frontend
### Updating the GraphQL Schema
```ps1
dotnet graphql download https://localhost:44339/graphql/
```
## Key Design Decisions
### Create ObjectTypes via Code-First patterns
Use Hot Chocolate 'Code-First' patterns to provide a wrapper around the domain objects and avoid exposing DB objects directly to the consumer. The alternative would be to use 'Annotation-based' patterns, but that would involve decorating our domain objects with GraphQL-related attributes.
### Return Unique Mutation Payloads
All mutations should return a unique payload object. Generally, this will return the object being modified so that the user can decide which fields to return. Using a unique object allows us to add future fields in future and not break the schema.
### Accept Unique Mutation Inputs
All mutations should accept a unique input object. Using a unique object allows us to add future fields in future and not break the schema.