Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 0 additions & 30 deletions .dockerignore

This file was deleted.

28 changes: 28 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
name: CI

on:
push:
branches: [master]
pull_request:
branches: [master]

jobs:
build-and-test:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v4

- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: '10.0.x'

- name: Restore
run: dotnet restore src/Sample.GraphQL.API.sln

- name: Build
run: dotnet build src/Sample.GraphQL.API.sln --no-restore --configuration Release

- name: Test
run: dotnet test src/Sample.GraphQL.API.sln --no-build --configuration Release --verbosity normal
1 change: 1 addition & 0 deletions .kiro/specs/dotnet10-upgrade-and-docs/.config.kiro
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
{"specId": "255e8395-edde-441d-8a1b-2e86273392d4", "workflowType": "requirements-first", "specType": "feature"}
163 changes: 163 additions & 0 deletions .kiro/specs/dotnet10-upgrade-and-docs/design.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,163 @@
# Design Document

## Overview

This design covers two coordinated changes to the Sample GraphQL API project:

1. **Framework upgrade**: Migrate from .NET 9.0 to .NET 10 across all four projects, update all NuGet dependencies to their latest stable versions, and update the Dockerfile base images.
2. **README rewrite**: Replace the current README.md with a comprehensive, well-structured document that explains GraphQL concepts, the Hot Chocolate integration, the DDD architecture, query examples (select, filtering, pagination), and getting started instructions.

Both changes are low-risk: the upgrade targets an in-memory demo project with no production traffic, and the README is a documentation-only change. The upgrade should be validated with `dotnet build`; the README is validated by visual review.

## Architecture

No architectural changes are introduced. The existing four-layer DDD structure remains intact:

```
API → Application → Domain
API → DataModel → Domain
```

The upgrade is a horizontal change across all layers (target framework + package versions). The README rewrite is external to the codebase.

### Upgrade Strategy

The upgrade follows a bottom-up dependency order to avoid transient build failures:

```mermaid
graph TD
A[1. Domain - no dependencies] --> B[2. DataModel - depends on Domain]
A --> C[3. Application - depends on Domain, DataModel]
B --> D[4. API - depends on Application, DataModel]
C --> D
D --> E[5. Dockerfile - base images]
```

Each project's `.csproj` is updated in sequence: target framework first, then NuGet packages. A single `dotnet build` at the solution level validates the entire upgrade.

### README Strategy

The README is rewritten as a single Markdown file at the repository root. It reuses existing screenshot assets in the `assets/` folder. The structure follows a logical reading order: what is this → what technologies → how it's built → how to run it → how to query it.

## Components and Interfaces

### Component 1: Project Files (`.csproj`)

Four project files require updates:

| Project | File | Changes |
|---------|------|---------|
| Domain | `Sample.GraphQL.Domain.csproj` | TFM `net9.0` → `net10.0`, update `Bogus`, `Microsoft.Extensions.DependencyInjection.Abstractions` |
| DataModel | `Sample.GraphQL.Persistence.csproj` | TFM `net9.0` → `net10.0`, update `HotChocolate.Data.EntityFramework`, all `Microsoft.EntityFrameworkCore.*` packages, remove or update `Microsoft.AspNetCore.Http.Abstractions` |
| Application | `Sample.GraphQL.Application.csproj` | TFM `net9.0` → `net10.0`, update `HotChocolate.AspNetCore`, remove `Microsoft.AspNetCore.OpenApi` |
| API | `Sample.GraphQL.API.csproj` | TFM `net9.0` → `net10.0`, remove `Swashbuckle.AspNetCore`, remove `Microsoft.AspNetCore.OpenApi`, update container tools |

### Component 2: Dockerfile

The Dockerfile at `src/Sample.GraphQL.API/Dockerfile` currently references .NET 8.0 base images (already behind the codebase). Both the SDK and runtime images are updated to 10.0.

### Component 3: README.md

The README at the repository root is fully rewritten with the following sections:

1. **Title and badges** — project name
2. **Project overview** — what the API does, key technologies
3. **GraphQL concepts** — what GraphQL is, why Hot Chocolate
4. **Architecture** — DDD layers, dependency direction, conventions
5. **Getting started** — prerequisites, build, run, access playground
6. **Query examples** — basic select, filtering, pagination (with screenshots)
7. **Project structure** — folder layout reference

## Data Models

No data model changes. The domain entities (`MovieEntity`, `ShowtimeEntity`, `ShowtimeSeatEntity`, `Seat`) and the EF Core `CinemaDbContext` remain unchanged.

### NuGet Package Version Mapping

Current → target versions based on research:

| Package | Current | Target | Project(s) |
|---------|---------|--------|------------|
| `Bogus` | 35.6.2 | 35.6.5 | Domain |
| `Microsoft.Extensions.DependencyInjection.Abstractions` | 9.0.2 | 10.0.0 | Domain |
| `HotChocolate.Data.EntityFramework` | 15.0.3 | 15.1.12 | DataModel |
| `Microsoft.EntityFrameworkCore` | 9.0.2 | 10.0.0 | DataModel |
| `Microsoft.EntityFrameworkCore.InMemory` | 9.0.2 | 10.0.0 | DataModel |
| `Microsoft.EntityFrameworkCore.SqlServer` | 9.0.2 | 10.0.0 | DataModel |
| `Microsoft.AspNetCore.Http.Abstractions` | 2.3.0 | Remove (included in shared framework) | DataModel |
| `HotChocolate.AspNetCore` | 15.0.3 | 15.1.12 | Application |
| `Microsoft.AspNetCore.OpenApi` | 9.0.2 | Remove (not needed — only web UI is GraphQL playground) | Application, API |
| `Swashbuckle.AspNetCore` | 7.2.0 | Remove (not needed — only web UI is GraphQL playground) | API |
| `Microsoft.VisualStudio.Azure.Containers.Tools.Targets` | 1.21.2 | latest stable | API |

**Key decisions:**

- **Remove Swashbuckle and OpenAPI entirely**: The only web interface needed is the Hot Chocolate GraphQL playground at `/graphql/`. Swashbuckle, `Microsoft.AspNetCore.OpenApi`, and all Swagger middleware are removed from the project. No replacement (Scalar or otherwise) is added.
- **Hot Chocolate stays on v15**: The latest stable release is 15.1.x. Version 16 is in release candidate and not yet stable. Staying on 15.1.x avoids breaking changes while picking up bug fixes.
- **Remove `Microsoft.AspNetCore.Http.Abstractions`**: This package is included in the ASP.NET Core shared framework since .NET 6. The explicit reference is unnecessary and can be removed.

### Dockerfile Image Mapping

| Stage | Current | Target |
|-------|---------|--------|
| Runtime base | `mcr.microsoft.com/dotnet/aspnet:8.0` | `mcr.microsoft.com/dotnet/aspnet:10.0` |
| Build SDK | `mcr.microsoft.com/dotnet/sdk:8.0` | `mcr.microsoft.com/dotnet/sdk:10.0` |

### Program.cs Changes — Remove Swagger

All Swagger/OpenAPI middleware is removed from `Program.cs`. The only web UI is the Hot Chocolate GraphQL playground, already mapped via `app.MapGraphQL()`.

**Before:**
```csharp
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
// ...
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
```

**After:**
```csharp
// Swagger/OpenAPI lines removed entirely.
// The GraphQL playground at /graphql/ is the only web UI.
```

## Error Handling

No new error handling is introduced. The upgrade is a version bump; error handling patterns in the existing code remain unchanged.

**Build validation**: If the upgrade introduces compilation errors (e.g., breaking API changes in EF Core 10 or Hot Chocolate 15.1), they will surface during `dotnet build` and must be resolved before the upgrade is considered complete.

**Dockerfile validation**: The Dockerfile should be validated with `docker build` to confirm the .NET 10 base images resolve correctly and the application compiles inside the container.

## Testing Strategy

**PBT applicability assessment**: Property-based testing is **not applicable** to this feature. The changes consist of:
- Configuration file edits (`.csproj` target frameworks and package versions) — these are declarative, not functional code
- Dockerfile base image updates — infrastructure configuration
- README documentation rewrite — prose content
- A small `Program.cs` cleanup removing Swagger middleware

None of these involve pure functions with varying inputs or universal properties. There is no meaningful "for all inputs X, property P(X) holds" statement to write.

**Recommended testing approach:**

### Build Verification
- Run `dotnet build src/Sample.GraphQL.API.sln` after all `.csproj` changes — must produce zero errors
- Run `dotnet build src/Sample.GraphQL.API.sln --warnaserror` to catch any new warnings introduced by the upgrade

### Runtime Smoke Test
- Start the application with `dotnet run --project src/Sample.GraphQL.API`
- Verify the GraphQL playground loads at `http://localhost:5055/graphql/`
- Execute a basic `all` query and a `showTimes` query with filtering to confirm Hot Chocolate still works

### Dockerfile Validation
- Run `docker build -t sample-graphql-api .` from the `src/` directory
- Verify the image builds without errors

### README Review
- Visual review of the rendered Markdown for formatting, link validity, and image references
- Verify all `assets/*.png` references resolve correctly
129 changes: 129 additions & 0 deletions .kiro/specs/dotnet10-upgrade-and-docs/requirements.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,129 @@
# Requirements Document

## Introduction

This feature covers two goals for the Sample GraphQL API project:

1. **Upgrade to .NET 10**: Migrate the entire solution from .NET 9.0 to .NET 10 and update all NuGet package dependencies to their latest compatible versions, including Hot Chocolate, Entity Framework Core, Bogus, and supporting packages. Swagger/Swashbuckle and OpenAPI packages will be removed entirely since the only web interface needed is the Hot Chocolate GraphQL playground. The Dockerfile should also be updated to use .NET 10 base images.

2. **Improve README documentation**: Rewrite the README.md to make the project more understandable, incorporating content from the author's Medium article about ASP.NET Core GraphQL with Hot Chocolate. The documentation should explain GraphQL concepts, the Hot Chocolate integration, the DDD architecture, and provide clear query examples for selecting, filtering, and pagination.

## Glossary

- **Solution**: The .NET solution file (`Sample.GraphQL.API.sln`) and all four projects it contains.
- **Project_File**: A `.csproj` file that defines a project's target framework and NuGet dependencies.
- **Target_Framework_Moniker**: The `<TargetFramework>` value in a Project_File (e.g., `net9.0`, `net10.0`).
- **NuGet_Package**: A third-party or Microsoft library referenced via `<PackageReference>` in a Project_File.
- **Dockerfile**: The container build definition at `src/Sample.GraphQL.API/Dockerfile`.
- **README**: The `README.md` file at the repository root.
- **GraphQL_Playground**: The Hot Chocolate built-in UI available at `http://localhost:5055/graphql/` for testing queries.
- **Build_System**: The `dotnet build` toolchain used to compile the Solution.
- **Query_Example**: A GraphQL query snippet demonstrating how to use the API.

## Requirements

### Requirement 1: Update Target Framework to .NET 10

**User Story:** As a developer, I want the solution to target .NET 10, so that the project benefits from the latest runtime features, performance improvements, and long-term support.

#### Acceptance Criteria

1. THE Build_System SHALL compile the Solution successfully after all Project_File Target_Framework_Moniker values are changed from `net9.0` to `net10.0`.
2. WHEN the Solution is built with `dotnet build`, THE Build_System SHALL produce zero errors and zero warnings related to the framework upgrade.
3. THE Solution SHALL contain no Project_File with a Target_Framework_Moniker value of `net9.0` after the upgrade is complete.

### Requirement 2: Update All NuGet Dependencies to Latest Versions

**User Story:** As a developer, I want all NuGet package dependencies updated to their latest stable versions compatible with .NET 10, so that the project uses the most current and secure libraries.

#### Acceptance Criteria

1. WHEN the upgrade is performed, THE Project_File for each project SHALL reference the latest stable version of every NuGet_Package currently listed.
2. THE Build_System SHALL compile the Solution successfully after all NuGet_Package versions are updated.
3. WHEN a NuGet_Package has a major version update available (e.g., Hot Chocolate, Entity Framework Core), THE Project_File SHALL reference the latest stable major version compatible with .NET 10.
4. IF a NuGet_Package is deprecated or replaced in .NET 10, THEN THE Project_File SHALL replace the deprecated package with its recommended successor.

### Requirement 3: Update Dockerfile for .NET 10

**User Story:** As a developer, I want the Dockerfile updated to use .NET 10 base images, so that the containerized application runs on the correct runtime.

#### Acceptance Criteria

1. THE Dockerfile SHALL use the `mcr.microsoft.com/dotnet/aspnet:10.0` base image for the runtime stage.
2. THE Dockerfile SHALL use the `mcr.microsoft.com/dotnet/sdk:10.0` base image for the build stage.
3. WHEN the Dockerfile is built with `docker build`, THE Build_System SHALL produce a valid container image without errors.

### Requirement 4: Add Project Overview Section to README

**User Story:** As a new developer exploring the repository, I want the README to contain a clear project overview explaining what the API does and what technologies it uses, so that I can quickly understand the project's purpose.

#### Acceptance Criteria

1. THE README SHALL contain an introduction section that describes the project as a cinema showtime management API built with ASP.NET Core and Hot Chocolate.
2. THE README SHALL list the key technologies used: .NET 10, Hot Chocolate, Entity Framework Core with InMemory provider, and Bogus for data generation.
3. THE README SHALL explain that the project follows a Domain-Driven Design (DDD) layered architecture with four projects: API, Application, Domain, and DataModel.

### Requirement 5: Add GraphQL Concepts Section to README

**User Story:** As a developer unfamiliar with GraphQL, I want the README to explain what GraphQL is and why Hot Chocolate is used, so that I can understand the technology choices.

#### Acceptance Criteria

1. THE README SHALL contain a section explaining that GraphQL is a query language that allows clients to declaratively specify the exact data they need.
2. THE README SHALL explain that Hot Chocolate is an open-source GraphQL server for .NET that adheres to the latest GraphQL specifications.
3. THE README SHALL explain that Hot Chocolate integrates with Entity Framework Core through IQueryable, enabling filtering and pagination at the database level.

### Requirement 6: Add Getting Started Section to README

**User Story:** As a developer cloning the repository, I want clear instructions on how to build and run the project, so that I can start exploring the API immediately.

#### Acceptance Criteria

1. THE README SHALL list the prerequisites needed to run the project, including the .NET 10 SDK.
2. THE README SHALL provide the command to build the solution: `dotnet build src/Sample.GraphQL.API.sln`.
3. THE README SHALL provide the command to run the API: `dotnet run --project src/Sample.GraphQL.API`.
4. THE README SHALL state that the GraphQL_Playground is available at `http://localhost:5055/graphql/` after starting the application.
5. THE README SHALL state that the only web interface is the GraphQL_Playground at `http://localhost:5055/graphql/`; no Swagger or OpenAPI UI is provided.

### Requirement 7: Document GraphQL Query Examples for Basic Selection

**User Story:** As a developer using the API, I want the README to show how to write a basic GraphQL query to select showtime data, so that I can learn how to retrieve data from the API.

#### Acceptance Criteria

1. THE README SHALL contain a Query_Example demonstrating a basic `all` query that retrieves showtime properties including `id`, `movieId`, and nested `movie.title`.
2. THE README SHALL explain that the `all` endpoint corresponds to the `GetAll` method in `ShowtimesQuery` and returns all showtimes without filtering.
3. THE README SHALL include a screenshot or reference to the existing `assets/SampleResult1.png` image showing a sample result.

### Requirement 8: Document GraphQL Filtering Examples

**User Story:** As a developer using the API, I want the README to show how to use GraphQL filtering with the `where` clause, so that I can query specific subsets of data.

#### Acceptance Criteria

1. THE README SHALL contain a Query_Example demonstrating filtering on the `showTimes` endpoint using a `where` clause with nested entity filtering (e.g., filtering by `movie.title`).
2. THE README SHALL explain that filtering is enabled by the `[UseFiltering]` attribute on the `GetShowTimes` method in `ShowtimesQuery`.
3. THE README SHALL include a reference to the existing `assets/Filters.png` image showing a filtering result.
4. THE README SHALL provide a link to the official Hot Chocolate filtering documentation.

### Requirement 9: Document GraphQL Pagination Examples

**User Story:** As a developer using the API, I want the README to show how cursor-based pagination works, so that I can navigate through large result sets.

#### Acceptance Criteria

1. THE README SHALL contain a Query_Example demonstrating cursor-based pagination on the `showTimes` endpoint using `first`, `after`, `totalCount`, `pageInfo`, `edges`, `nodes`, and `cursor` fields.
2. THE README SHALL show two Query_Example instances: one for the first page and one for navigating to the next page using the `after` cursor parameter.
3. THE README SHALL explain that pagination is enabled by the `[UsePaging]` attribute on the `GetShowTimes` method in `ShowtimesQuery`.
4. THE README SHALL include references to the existing `assets/Pagination_Page1.png` and `assets/Pagination_Page2.png` images.
5. THE README SHALL provide a link to the official GraphQL pagination documentation.

### Requirement 10: Document Project Architecture in README

**User Story:** As a developer contributing to the project, I want the README to describe the layered architecture and project structure, so that I know where to find and place code.

#### Acceptance Criteria

1. THE README SHALL contain a section describing the four-project layered architecture: API, Application, Domain, and DataModel.
2. THE README SHALL explain the dependency direction: API references Application and DataModel; Application and DataModel reference Domain; Domain has no project references.
3. THE README SHALL describe the key conventions: domain entities use private constructors with static `Create()` factory methods, repository interfaces live in Domain, and implementations live in DataModel.
Loading
Loading