tc-public-content-api
Minimal .NET 6 API for the public website that serves a hardcoded catalogue of 'inspiration blog' content (destination articles with images) from static C# classes.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | ASP.NET Core 6 |
| Runtimes | .NET 6 |
| Tests / CI | none / CI in place |
| Last commit | 2025-11-26 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Content and destinations (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Ready with guardrailsClose: the deployment path exists, but specific checks are needed first, typically raising tests, auditing serialized data, or respecting a shared schema with expand and contract. Already deploys as a container to AWS, which releases without downtime today. No automated tests: at-will release without a safety net is bravado, not capability.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
Recommended actions
Replatform tc-public-content-api to modern .NET
Runs on .NET 6, out of mainstream support. No pinning dependency blocks it; sequence by fan-in (providers before consumers).
Impact: Reduces the end-of-life runtime count
proposedAssessment notes
tc-public-content-api
Purpose
Content API for the public travelcounsellors.com estate: a single anonymous api/inspiration-blogs endpoint returns a fixed list of destination "inspiration blog" articles (Route 66, Mallorca, Japan, Kenya, etc.), each defined as a static singleton C# class under StaticContent/InspirationBlogs with full article body, images and metadata compiled into the binary.
Tech stack
C# on .NET 6 (global.json pins SDK 6.0, rollForward latestMinor). A single TC.Public.Content.Api web project with two NuGet packages: Swashbuckle 6.2 and TC.Diagnostics.HealthChecks.AspNetCoreExtensions. Minimal Program.cs — controllers, Swagger, TC health checks; no authentication, versioning, mediator or data access of any kind.
Deployment
Included as prod_application with 0 releases — deployment is entirely YAML/AWS. Build pipeline tc-public-content-api from in-repo azure-pipeline.yaml, using the shared InternalOSS/azure-pipelines-templates jobs/ci.yml (SDK 6.0.x): container built after build (containerNamespace: cx-public), deployed to ECS via the aws-public-tc-apps Terraform repo with tfvars deployment, region eu-west-1, functional area public.
Dependencies
Internal: only TC.Diagnostics.HealthChecks.AspNetCoreExtensions (tc-diagnostics-portal). No ConnectionBroker, no service clients, no external services. A code TODO references TC.Public.Reviews.Api as the pattern for a shared ApiResponse base controller, but there is no code dependency.
Data stores
None. All content is hardcoded in source; there is no database, cache, file store or configuration-driven content.
Integration points
Inbound anonymous REST only (Swagger UI enabled unconditionally). No outbound calls to anything.
Code health
No test projects at all, README is untouched Azure DevOps boilerplate, and the controller carries a TODO acknowledging copy-paste divergence from tc-public-reviews-api. Editorial content changes require a code change and redeploy. Last commit 2025-11-26, so still receiving occasional content updates.
Modernisation risks
Medium, driven by the runtime rather than size: .NET 6 went end-of-life in November 2024 and this is an internet-facing container still building against SDK 6.0.x. The upgrade itself is trivial (one small project, two packages). The structural smell is content-as-code — every blog edit is a compile-and-deploy — which arguably belongs in the CMS or an asset store rather than C# singletons.
Data store follow-up (2026-07-28)
Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. No data store packages or configuration found; content is served from upstream sources.