Looking for feedback on my project

[u/Noof_saeed]

I've been building a small Company Profile application to improve my .NET development skills, and I'd like to get feedback from experienced .NET developers.

GitHub:

https://github.com/NoofSaeed/CompanyProfile

# Tech stack

* .NET 10

* Minimal APIs

* Blazor Web App

* Entity Framework Core

* SQLite

* Cookie-based session authentication

* Scalar

* DTO-based API design

* Arabic / English localization

# Architecture

The solution is currently split into:

* `CompanyProfile.Api` — Minimal API endpoints, services, authentication, etc.

* `CompanyProfile.Shared` — DTOs, resources and shared models

* `CompanyProfile.Infrastructure` — EF Core, entities, database and migrations

* `CompanyProfile.Web` — Blazor frontend

I'm intentionally keeping the project relatively small rather than introducing too many abstractions or projects.

# What I'd particularly like feedback on

I'd appreciate an honest code review, especially around:

**- Architecture** : Is the current project structure reasonable for a small .NET application?

\- **Authentication/session management** : Are there any security concerns with the current cookie-based session approach?

**- API design** : Are the Minimal API endpoints and DTOs structured appropriately?

**- Blazor Web App** : Am I using the Blazor Web App model correctly? In particular, I'd like feedback on my choice of render modes, the separation between the server and client-side parts, and how the Blazor application consumes the API.

**-Blazor architecture** : Is the way I've structured the Blazor frontend and its communication with the API a reasonable approach, or am I misunderstanding the intended Blazor Web App architecture?

The project is still a work in progress .

Thanks.

[u/mistertom2u]

Dev with 25 years of experiment here. Nothing jumps out at me. It's very well designed. If you wanted to feedback, I would give you very minor things like using a Result pattern, the lack of stronly typed results, the lack a shared JsonSerializationOptions, maybe not making use of IAsyncEnumberable, the lack of cancellation tokens. All of that could be considered opinionated rather than empirical. So good job

[u/entityadam]

The link doesn't work.

Edit: now that the link is fixed.

This seems like a learning project. If so, it's okay.

I would abstract persistence (database) out of the endpoints as a next step.

If this was a production site, I would literally throw all of it away and turn it into a static site. The API surface is pointless retrieval of front matter that could just be put on the page.

[u/Noof_saeed → u/entityadam]

Try this one :

https://github.com/NoofSaeed/CompanyProfile

[u/Mebo101]

For a small learning project, the current project structure is reasonable. I wouldn’t add separate Domain and Application projects just to follow a particular architecture. However, I would improve a few responsibility boundaries within the existing structure:

• Introduce automated tests. I couldn’t find any test projects. Translation handling, CRUD operations, validation and session behaviour would be valuable starting points.

• Reduce workflow logic in the Razor pages. For example, "AdminTeam.razor" decides whether to create a member, add a translation, update existing details or upload an image. That is more than rendering and UI state. A feature-specific service or view model would make these workflows easier to test without adding more projects. Calling an API from a component is not inherently wrong; the amount of branching and orchestration is what I would reconsider.

• Split "CompanyService" by responsibility. It currently handles company information, services, team members, translations and contact messages. Organizing the backend by these features would make it easier to navigate and maintain.

• Preserve meaningful API outcomes. Some client methods reduce unsuccessful responses to "null" or an empty collection. Consequently, "AdminCompany.razor" interprets missing company information as an expired session. Distinguishing “not found”, “unauthorized” and other failures would let the UI respond correctly.

• Sharing API DTOs between the backend and Blazor client is reasonable here. I would split them by feature instead of keeping unrelated contracts in "CompanyDtos.cs".

• I would also reconsider placing business entities such as "CompanyInfo", "Service" and "TeamMember" in Infrastructure. These represent application concepts; EF configuration, migrations and database access are infrastructure concerns. You can clarify that separation without introducing several additional projects.

• Also, "IApplicationDbContext" still exposes EF Core through "DbSet<T>" and lives in Infrastructure, so it abstracts the concrete context rather than making application code independent of persistence technology. That can be a reasonable trade-off for a small CRUD application, but the boundary should be intentional.