C
Join ServerC#
help
❔ Creating a backend in .NET
EEro11/23/2022
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.
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.
YYawnder11/24/2022
@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
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-7.0
Ttebeco11/24/2022
i would suggest the all
fudamentals
in orderTtebeco11/24/2022

Ttebeco11/24/2022
PPobiega11/24/2022
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.
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.
Ttebeco11/24/2022
yeah so I pointed at the fundamental joined knowledge
Ttebeco11/24/2022
regardless of WebApi opr MVC
Ttebeco11/24/2022
all the green things are things you want to be familliar for a webserver in .net that being ...webapi / razor / view / blazor server
EEro11/24/2022
TS, JS, Vue
Ttebeco11/24/2022
(the green list above)
PPobiega11/24/2022
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?
Ttebeco11/24/2022
then check api convention
EEro11/24/2022
i do not
PPobiega11/24/2022
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
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)
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)
PPobiega11/24/2022
when a request contains data, it can be as part of the URI, aka "query string":
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
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
PPobiega11/24/2022
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.
EEro11/25/2022
were these just some examples or is that all of them? i thought i'd seen
SET
and FETCH
too at some pointEEro11/25/2022
so, what exactly is a "header"? where does it come from?
EEro11/25/2022
i understand it's a key-value pair, but it has to be stored somewhere, no? or like, input somewhere
FFyren11/25/2022
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 (
There may also be custom headers, some times these are prefixed by
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.FFyren11/25/2022
Webservices don't usually support every http method for every endpoint, it's usually just a few if at all more than one.
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).
/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).
PPobiega11/25/2022
It's all the ones you will likely use. There are others thou, such as HEAD, TRACE, OPTIONS, CONNECT
PPobiega11/25/2022
Have not used any of them ever
PPobiega11/25/2022
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)
PPobiega11/25/2022
Here is a sample GET request I just googled
PPobiega11/25/2022
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
PPobiega11/25/2022
you wont be making these yourself quite as raw as this, as most http clients do most of the job for you
PPobiega11/25/2022
for example, if you are gonna use the
fetch
api you literally just need the method and the URL most of the timePPobiega11/25/2022
the three most common methods are GET, POST and PUT.
GET is for querying data. Sending a GET to
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)PPobiega11/25/2022
GET to
api/customers/5
would get you data about customer number 5PPobiega11/25/2022
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).PPobiega11/25/2022
PUT is "create or replace at the given id", so you could PUT to
api/customers/5
to edit(replace) that customer record.PPobiega11/25/2022
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.
EEro11/25/2022
in this fashion, would
api/customers?id=5
be bad practice?PPobiega11/25/2022
It would not follow convention, but is technically valid
PPobiega11/25/2022
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
etcEEro11/25/2022
yeah, this'll likely be a struggle point for me
EEro11/25/2022
choosing what to put into the url, and what to put into the query
PPobiega11/25/2022
Welcome to the family 🙂
PPobiega11/25/2022
I tend to use url parameters for IDs and "hard" identifiers, and query strings for "filtering" multiple choices
PPobiega11/25/2022
url params are obviously not optional, while query strings usually are
EEro11/25/2022
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
PPobiega11/25/2022
Yup, very much so.
PPobiega11/25/2022
Not to mention that "best pratice" changes every few weeks, 😄
EEro11/25/2022
truuue
PPobiega11/25/2022
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
EEro11/25/2022
i know that you use source gen for your stuff
EEro11/25/2022
and it's like. yes. i want that.
EEro11/25/2022
but i don't understand source generators for shit
PPobiega11/25/2022
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
EEro11/25/2022
i believe a minimal API is all i need as well?
EEro11/25/2022
hm, maybe not
PPobiega11/25/2022
I think with .net 7 you can do almost everything with either approach
EEro11/25/2022
the project is big. like thousands of users with a massive amount of DB data big
PPobiega11/25/2022
minimal has better performance, but its not like controllers are terribly slow or anything
PPobiega11/25/2022
it all comes down to code style preference
EEro11/25/2022
(i already know this, because it's gonna be a competitor to an existing site which basically went to shit under new management)
PPobiega11/25/2022
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) { ... }
}
PPobiega11/25/2022
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)
PPobiega11/25/2022
so you need to add your own abstraction to separate the mapping into different files with logical responsibilities and registration of dependencies
PPobiega11/25/2022
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 effortEEro11/25/2022
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
PPobiega11/25/2022
sure
PPobiega11/25/2022
dont think there is a problem with that then
PPobiega11/25/2022
if you make a boilerplate asp.net app with and without controllers you can compare them
EEro11/25/2022
and also to make it as extensive as possible. like i want a very rich and intuitive api
EEro11/25/2022
the competitor site's api is absolutely abyssmal
EEro11/25/2022
and has zero documentation
PPobiega11/25/2022
hm, so the API is not just for your frontends use?
PPobiega11/25/2022
like, you plan to actually support external users interacting with it directly? Then you will 100% want to read up on API versioning
EEro11/25/2022
yeah, it'll be a public api for fetching heaps of data
EEro11/25/2022
don't know if you remember, but it's that leaderboards project. there will be hundreds and thousands of gaming leaderboards
EEro11/25/2022
there will also be hundreds of "series" (a series contains multiple games (leaderboards))
PPobiega11/25/2022
What we do at work, is we have two separate APIs more or less
PPobiega11/25/2022
one for our own frontend, and one for external users
EEro11/25/2022
and each leaderboard contains hundreds of submissions
EEro11/25/2022
with potentially multiple players
PPobiega11/25/2022
the second is heavily versioned and protected against breaking changes, while the first one we can change as we want
PPobiega11/25/2022
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
EEro11/25/2022
hm. so the entire thing (and i mean the entire thing) is gonna be open source
EEro11/25/2022
is it safe to have the internal API open source?
PPobiega11/25/2022
just make sure you have very good security on it 😛
PPobiega11/25/2022
ie, validate absolutely everything everywhere
PPobiega11/25/2022
open source means that hackers wont have to guess for exploits
EEro11/25/2022
right
PPobiega11/25/2022
but it also means you might get issues/PRs to help fix
PPobiega11/25/2022
free pentesting, so to speak 😄
EEro11/25/2022
i don't know whether the split between public and internal makes sense yet
EEro11/25/2022
like if that's really necessary
EEro11/25/2022
maybe i'll see as it moves on
EEro11/25/2022
would you recommend going for the minimal api approach for now?
PPobiega11/25/2022
Test it out, see how it feels.
PPobiega11/25/2022
this video from nick explains the "abstraction" level I tend to use for minimal apis
PPobiega11/25/2022
PPobiega11/25/2022
I quite like FastEndpoints too thou, if only it would let you instantiate the response model yourself so records would be usable :((((
EEro11/25/2022
You can add an empty ctor to records, no?
PPobiega11/25/2022
Absolutely but then you can't use the short form definition
EEro11/25/2022
mh, right
EEro11/25/2022
so, where should i start?