# DevArchitecture, a layered .NET backend with five admin clients against one API > DevArchitecture/DevArchitecture is an open source .NET 10 framework whose idea is a single /api/v1 contract with several admin front ends built on top of it, Vue, Angular, React and two Blazor flavours, all talking to the same backend. The repository also makes a point of failing fast when the JWT signing key is missing or too short. **DevArchitecture/DevArchitecture** — DevArchitecture Backend Project - Repository: https://github.com/DevArchitecture/DevArchitecture - Website: https://devarchitecture.netlify.app/ - Stars: 769 · Forks: 141 - Language: C# - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/devarchitecture-devarchitecture ## The idea: one API contract, many admin front ends DevArchitecture is an open source framework for rapid application development using a layered .NET architecture and a shared WebAPI contract. The repository contains a .NET 10 backend, an /api/v1 REST surface, and multiple admin clients built in Vue, Angular, React and Blazor, with legacy Angular and Flutter samples kept under UiPreparation. That multiplicity is the design statement. The framework is not trying to pick one front end technology for you. It defines the contract once and then lets you build whichever admin interface suits the team, which is a sensible response to a common argument about full stack frameworks, where the choice of front end is imposed by the scaffold. The layered structure is visible in the repository top level. There are Business/, Core/, DataAccess/ and Entities/ directories, plus shared/ and WebAPI/, with DevArchitecture.sln at the root, Directory.Build.props and Directory.Packages.props for shared build and package settings, and global.json pinning the SDK. Tests/ sits alongside, and there is an e2e/ directory plus a scripts/ directory. The documentation is at devarchitecture.net with a mirror at devarchitecture.netlify.app, and there is a Turkish translation of the README, which tells you the project has an international community around it. There are Visual Studio Marketplace extensions for DevArchitecture, and the repository carries issue templates for bug, feature, docs and question reports. The release history has one entry, v2.0.0 on 2026-06-25, and the last push was on 2026-10-05. ## Prerequisites and the first run of the backend The prerequisites table names the .NET SDK at 10.x with the TargetFramework of net10.0, Node.js LTS for most clients, npm which ships with Node, and the Flutter SDK for the UiPreparation/FlutterUi sample. For local HTTPS the README asks you to trust the development certificate once: ```bash dotnet dev-certs https --trust ``` The backend build is a plain dotnet build: ```bash dotnet build ``` and for development the README uses the watch mode: ```bash dotnet watch run --project ./WebAPI/WebAPI.csproj ``` The project version lives in WebAPI/WebAPI.csproj at 1.0.0 with TargetFramework net10.0, and NuGet versions are centralised in Directory.Packages.props rather than pinned per project, which is the modern central package management layout and means one file to change when upgrading a dependency. The development ports are given precisely. Swagger is at https://localhost:5101/swagger, HTTP is 5100 and HTTPS is 5101, from the Dev_Development profile in WebAPI/Properties/launchSettings.json, and the default API base address is https://localhost:5101/api/v1. That last value is the one every client repeats, which is worth noting: the clients all point at the same base URL, so the contract is genuinely shared rather than each admin UI inventing its own endpoints. ## The JWT signing key handling is the sharpest part of the design The security section of the README is the most specific part of the document, and it deals with a problem the framework once had, referenced as issue 123, a publicly hard-coded JWT key. The arrangement now is that the base WebAPI/appsettings.json ships without a signing key, with TokenOptions:SecurityKey empty. At startup, Core/Utilities/Security/Jwt/TokenOptionsValidator.cs fails fast with an InvalidOperationException when the key is missing or shorter than 32 bytes, 256 bits, so the API cannot start with an insecure configuration. That is the correct behaviour for a secret, since failing at startup is far better than serving tokens signed with a key that is in a public repository. The key is supplied through environment configuration, and the README gives the generation command: ```bash export TokenOptions__SecurityKey="$(openssl rand -base64 32)" dotnet watch run --project ./WebAPI/WebAPI.csproj ``` The doubled separator is the standard .NET convention for a nested configuration key through environment variables, so TokenOptions__SecurityKey maps onto TokenOptions:SecurityKey. The Docker equivalent shows the same idea: ```bash docker run -e ASPNETCORE_ENVIRONMENT=Production \ -e TokenOptions__SecurityKey="" ... ``` Two further protections are documented. Known sample keys that used to ship in the repository are rejected automatically when the environment is Production or Staging, so an old key cannot quietly keep working. And beyond the normal exp validation, the JWT bearer handler rejects tokens whose expiration is more than AccessTokenExpiration minutes in the future, with one minute of clock tolerance, so a forged long-lived token is refused. There are public sample keys in appsettings.Development.json for local work and in appsettings.Docker.json for a CI health check, both clearly marked as never to be used in a real deployment. The README also states that if a deployment ever used a key published in the repository, it should be treated as compromised and rotated. The regression tests are named: TokenOptionsValidatorTests.cs and ForgedTokenLifetimeTests.cs. ## The five clients and how they compare The clients directory holds five admin front ends, and the README gives each one an install command, a dev command and a typical URL. The Vue client uses PrimeVue with the Aura theme, installed with npm install and run with npm run dev on port 5174 through Vite. Its dependency set is Vue 3.5, PrimeVue 4.5, vue-router 5, axios 1.15, jwt-decode 4 and Vite 8, and the API base is set in src/config/modules.ts. The Angular client uses PrimeNG and is marked in the README as the recommended option for new Angular admin work. It runs on port 4200 with ng serve, using Angular 19.2, PrimeNG 19.1, rxjs 7.8 and TypeScript 5.7, with the API base in src/environments/environment.ts. The React client uses PrimeReact with the Lara green light and dark theme, runs on port 5173 with Vite, and adds an npm run lint script that the other two do not mention. It is on React 19.2 with react-router-dom 7.14 and Vite 8. The two Blazor clients are the .NET side of the story. The Blazor WebAssembly one uses Radzen components against the WebAPI and needs no npm install at all, since it is restored with dotnet restore. The Blazor server-hosted variant runs from clients/blazor-admin-server and typically listens on port 7003. The root package.json ties the JavaScript clients together as npm workspaces, with scripts such as dev:react and dev:vue that run the right command in the right workspace. The practical point is that the contract is what is shared. A team can start with one client, or run two side by side to compare admin approaches, without the backend changing. ## The .NET 10 migration and what to check before adopting The README links a dedicated breaking changes document for the .NET 10 migration, in English and in Turkish, which is the right way to handle a framework version jump. Its existence tells you the project tracks the current .NET release closely rather than sitting on an older LTS. That closeness is the main risk as well as the main benefit. A framework on .NET 10 with Angular 19 and Vite 8 in its clients is on the leading edge of several ecosystems at once, and the pinned versions in the README are current-generation rather than conservative. When a dependency moves, this project moves, and there is no long support window to sit in. The other thing to weigh is that this is a project rather than a product. The licence field on the repository says it is not one GitHub can classify, so you need to read the licence files in the repository before shipping anything based on it, particularly for the client code you might copy into a commercial admin UI. What you get for the effort is a working reference for how to structure a .NET 10 backend with a clean separation between business logic, data access and entities, an API versioned in the path so it can evolve, and front ends that are deliberately interchangeable. That reference value is real even if you copy the architecture rather than the code. If you do adopt it, the order of work is what the README implies. Get the backend running with a generated key and Swagger open, confirm the validator accepts your configuration, then bring up one client and point it at the base URL, and only then start building features. ## Conclusion Adopt DevArchitecture if you want a .NET 10 backend with a clean layered structure and several admin front end options talking to one API contract, and you can afford to own the code rather than depend on a supported product. Skip it if you need a vendor with contractual support or a fully settled architecture, since this is a v2.0.0 project with a .NET 10 migration still in progress. Verify first by generating a signing key with openssl rand -base64 32, exporting it as TokenOptions__SecurityKey, and starting the API to confirm the startup validator accepts your configuration before you build any client against it. ## FAQ ### What is DevArchitecture and what does the repository contain? It is an open source framework for rapid application development with a layered .NET architecture and a shared WebAPI contract. The repository holds a .NET 10 backend, an /api/v1 REST surface, admin clients in Vue, Angular, React and two Blazor flavours, plus legacy Angular and Flutter samples under UiPreparation. ### How do I build and run the DevArchitecture backend? Install the .NET 10 SDK, trust the local HTTPS certificate with dotnet dev-certs https --trust, then run dotnet build and dotnet watch run --project ./WebAPI/WebAPI.csproj. Swagger is served at https://localhost:5101/swagger in development. ### How is the JWT signing key supplied to DevArchitecture? Through environment configuration rather than a committed file. The README shows exporting TokenOptions__SecurityKey with a value from openssl rand -base64 32, and in Docker passing it as the TokenOptions__SecurityKey environment variable. The base appsettings.json ships with an empty key and the API refuses to start without one of at least 32 bytes. ### Which admin clients does DevArchitecture ship with? Five: a Vue client with PrimeVue on port 5174, an Angular client with PrimeNG on port 4200 which the README recommends for new Angular work, a React client with PrimeReact on port 5173, and two Blazor clients, one WebAssembly using Radzen and one server-hosted. The JavaScript ones are npm workspaces under the root package.json. ### What are the .NET 10 breaking changes in DevArchitecture? The README links a dedicated breaking changes document at docs/BREAKING-CHANGES-NET10.md with a Turkish translation, and also a Visual Studio Marketplace extension and the documentation site at devarchitecture.net. ## Sources - [DevArchitecture/DevArchitecture on GitHub](https://github.com/DevArchitecture/DevArchitecture) - [Issues](https://github.com/DevArchitecture/DevArchitecture/issues) - [Project website](https://devarchitecture.netlify.app/) - [README](https://github.com/DevArchitecture/DevArchitecture/blob/master/README.md) - [Releases](https://github.com/DevArchitecture/DevArchitecture/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/devarchitecture-devarchitecture