❔ Creating a backend in .NET

Hi!

I have absolutely zero knowledge about web development, databases, or making any kinds of web requests. Basically, I'm a complete noob when it comes to literally anything web-related (and I know databases aren't necessarily web, but you get the idea).

I would like to build a backend for a website idea that's already pretty big on paper. I have a lot of ideas, have a lot of thoughts about how things should work, I just can't create it.

I was wondering if there are any very beginner friendly, modern tutorials on this stuff? Preferrably videos, as I have a hard time focussing on reading a lot.

If I should go into any more detail, let me know.

@Ero Break your problem pieces by pieces, as you do with everything. Ignore the database aspect of it. Start with the API project template (the one that has a Weather controller endpoint) and see how you can modify it to understand. Something important for you to understand is the life cycle of an http request. How all the middleware are linked together.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-7.0

i would suggest the all fudamentals in order

What kind of frontend are you making for this? If its a JS based one like React, Vue, Svelte or whatever they are called these days, your backend will likely be a pure web API where all requests and responses are JSON (if any content at all).

This matters because ASP.NET can do a lot of different things, including generating and serving up HTML (MVC, Razor pages), so you'll want to focus your attention on the aspects of it that you need.

yeah so I pointed at the fundamental joined knowledge

regardless of WebApi opr MVC

all the green things are things you want to be familliar for a webserver in .net that being ...webapi / razor / view / blazor server

TS, JS, Vue

(the green list above)

Great, then a bog standard ASP.NET Web API will be your best bet. Do you know how basic HTTP stuff works, with the request/responses etc?

then check api convention

i do not

super simplified version:

Every data exchange begins with the client submitting a request and the server sending a response back. You can only respond once to each request.
Each request has a "method" or verb (GET, POST, PUT, DELETE, PATCH) that partially restricts what it can do but also indicates intent. You can have a webserver.com/hello endpoint respond only to GET, or GET and POST. with ASP.NET its easy to write a method that handles the get, and another method that handles the post.

All requests and responses consist of several parts: the URI (path), the headers (a key value pair list) and the body (a stream, but often just JSON)

when a request contains data, it can be as part of the URI, aka "query string": www.webserver.com/hello?query=floop <-- query is the parameter, floop is the value.
or it can be part of the headers (they are just string-string key value pairs, so you can create them at will)
or it can be the body (for apis, very common to accept a JSON object. ASP.NET has excellent support for this, you can make a record/class and just specify it as an input to your method)

responses have 3 parts: the response code (indicates success or failure, and what kind of failure), headers, and optionally a body

so your "endpoint" (what we call a unique path or route) can respond with 200 OK, or 404 Not Found, or 400 Bad Request, for example.

were these just some examples or is that all of them? i thought i'd seen SET and FETCH too at some point

so, what exactly is a "header"? where does it come from?

i understand it's a key-value pair, but it has to be stored somewhere, no? or like, input somewhere

It's part of the response object. a body contained inside a response object may have headers of its own in addition to the overall response object having some.
Headers usually contain information such as the content-type (text/plain, application/json). These things also dictate what you can expect in return, as
this is a string and "this is a string" are the result of different content-types (text/plain vs application/json) set in the Content-Type header.

There may also be custom headers, some times these are prefixed by x- etc.

Webservices don't usually support every http method for every endpoint, it's usually just a few if at all more than one.

/api/customers/{customerId} indicates a search for a customer by a specific ID (the customerId variable) inside a collection of customers, so this one is a GET.
If you remove the customerId variable it by convention becomes a POST (insert), and you'd be expected to provide the payload inside the body of your request. However that would require the webservice to have a route with a POST (as in, there needs to be an actual explicit endpoint for that path that accepts a POST httpmethod).

It's all the ones you will likely use. There are others thou, such as HEAD, TRACE, OPTIONS, CONNECT

Have not used any of them ever

So yeah headers is just part of the protocol and the http client has some it adds by default, and same for the response ( added by the server)

Here is a sample GET request I just googled

you wont be making these yourself quite as raw as this, as most http clients do most of the job for you

for example, if you are gonna use the fetch api you literally just need the method and the URL most of the time

the three most common methods are GET, POST and PUT.

GET is for querying data. Sending a GET to api/customers would, if supported, return you some kind of list of customers. GET to api/customers?category=3&startsWith=steve would do similar, but filter based on the query string parameters (assuming the backend was implemented as such, but this is convention)

GET to api/customers/5 would get you data about customer number 5

POST adds to collections or submits general data. POST to api/customers would register a new customer based on the body data, and return either the whole customer or just the ID (as it was assigned by the backend).

PUT is "create or replace at the given id", so you could PUT to api/customers/5 to edit(replace) that customer record.

PATCH is for making smaller edits than a full on replace, but its tricky to implement right. A fairly common thing to use is "jsonpatch" which has a way to indicate what to replace with what, but dont think System.Text.Json supports it just yet.

in this fashion, would api/customers?id=5 be bad practice?

It would not follow convention, but is technically valid

The nice thing about using it as part of the URL is that you can keep going. Let's say that customers have users, you could show them at api/customers/5/users/63 etc

yeah, this'll likely be a struggle point for me

choosing what to put into the url, and what to put into the query

Welcome to the family 🙂

I tend to use url parameters for IDs and "hard" identifiers, and query strings for "filtering" multiple choices

url params are obviously not optional, while query strings usually are

i'll start setting everything up later today. i'm excited, but i'm scared i won't get far. i have a hard time learning through reading, and finding complete, modern, best practice examples is obviously impossible, because a lot of it is too personal

Yup, very much so.

Not to mention that "best pratice" changes every few weeks, 😄

truuue

So now that we've got most of the theory out of the way, ASP is actually really nice to work with. It handles most of the stuff for you

i know that you use source gen for your stuff

and it's like. yes. i want that.

but i don't understand source generators for shit

It has two modes thou, old-school controllers and the more modern (and highly divisive) minimal apis where endpoints are literally a single method, usually a lambda

i believe a minimal API is all i need as well?

hm, maybe not

I think with .net 7 you can do almost everything with either approach

the project is big. like thousands of users with a massive amount of DB data big

minimal has better performance, but its not like controllers are terribly slow or anything

it all comes down to code style preference

(i already know this, because it's gonna be a competitor to an existing site which basically went to shit under new management)

with controllers, you tend to make stuff like...

[Route("api/customers")]
public class CustomersController : ControllerBase
{
    [HttpGet]
    // no route, so it matches the "root" route of the controller
    public List<Customer> GetAll() { ... }

    [HttpPost]
    // no route, so it matches the "root" route of the controller
    public CustomerDto AddCustomer(CreateCustomerDto customer) { ... }
}

I actually kind of like minimal apis, but its a little bit more work getting it set up in a nice way. Just throwing api methods together in program.cs gets messy real fast (once you have hundreds of endpoints for example)

so you need to add your own abstraction to separate the mapping into different files with logical responsibilities and registration of dependencies

There are ofc packages that do this already, such as FastEndpoints (which I almost love, but it demands that your models are where T : new() which rules out records), and writing your own is like... 10 minutes of effort

i mean, i don't mind that. what i just care about is doing it "properly". in such a way that makes it easy to use and especially to maintain and expand

sure

dont think there is a problem with that then

if you make a boilerplate asp.net app with and without controllers you can compare them

and also to make it as extensive as possible. like i want a very rich and intuitive api

the competitor site's api is absolutely abyssmal

and has zero documentation

hm, so the API is not just for your frontends use?

like, you plan to actually support external users interacting with it directly? Then you will 100% want to read up on API versioning

yeah, it'll be a public api for fetching heaps of data

don't know if you remember, but it's that leaderboards project. there will be hundreds and thousands of gaming leaderboards

there will also be hundreds of "series" (a series contains multiple games (leaderboards))

What we do at work, is we have two separate APIs more or less

one for our own frontend, and one for external users

and each leaderboard contains hundreds of submissions

with potentially multiple players

the second is heavily versioned and protected against breaking changes, while the first one we can change as we want

since we use command pattern internally, most of the external stuff uses the same commands as the internal one, just with a different layer of very strict DTO mappings applied

hm. so the entire thing (and i mean the entire thing) is gonna be open source

is it safe to have the internal API open source?

just make sure you have very good security on it 😛

ie, validate absolutely everything everywhere

open source means that hackers wont have to guess for exploits

right

but it also means you might get issues/PRs to help fix

free pentesting, so to speak 😄

i don't know whether the split between public and internal makes sense yet

like if that's really necessary

maybe i'll see as it moves on

would you recommend going for the minimal api approach for now?

Test it out, see how it feels.

this video from nick explains the "abstraction" level I tend to use for minimal apis

I quite like FastEndpoints too thou, if only it would let you instantiate the response model yourself so records would be usable :((((

You can add an empty ctor to records, no?

Absolutely but then you can't use the short form definition

mh, right

so, where should i start?