Repo Overview

This living doc serves as an overview of the backend repo. Bear in mind that the foundations of the main project are based heavily on ASP.NET Core and EF Core's docs. Us here at the backend team (for now) don't have too much .NET experience (though we do have backend dev experience), so we've stuck to the docs as much as we can, and we're trying to evolve existing code as we go along, where we can.

Our Stack

Our backend's ASP.NET Core that talks to Postgres via NPGSQL and Entity Framework Core.

Code Structure (As of Now)

Our solution consists of three projects:

• The main project (LeaderboardBackend);
• The test project (LeaderboardBackend.Test); and
• The jobs project (LeaderboardBackend.Jobs)

In case you're unfamiliar with how .NET projects work (like me), what this means is; while every project is its own unit, they are also able (depending on configs) to see and instantiate classes from one another.

The main project should be self-explanatory. It houses our API; the backend proper.

The test project houses all of our tests, and contains public contract testing on our API (as mentioned in our Style Guide). What this means is:

• We don't have any test code in our main project, period;
• We don't have any unit tests;
• We only test against API calls

The jobs project builds and runs an interactive CLI tool that allows for easy generation of entities, so you'll have data for local testing. You can refer to this comment in its first PR to see how it looks like as of this writing.

How We Configure

Configuration's done in three places:

• .env for framework-agnostic and database environment variables (example.env in the remote);
• .editorconfig for framework-agnostic and .NET-specific code style and formatting rules; and
• LeaderboardBackend/appSettings.*.json for environment-based settings, specifically for the main project

As of this writing, we only have a single .env file. We aim to have Staging and Production environments set up eventually, which will have their own versions, like .env.stg and .env.prd

What I said earlier about our backend talking to Postgres is a (half-)lie. You can set the main and test projects to use an in-memory database by setting USE_IN_MEMORY_DB=truein .env. This speeds up local development, but of course, it will mean data isn't persisted. The jobs project doesn't allow this though. Kinda defeats its whole point.

---

We hope this gives you a good understanding of our code's foundations. Thanks a ton for considering contributing to LB.GG's development 😌