Hi Omar! I understand your point of view. Django is a full framework, which means it tends to hide details about how the underlying request/response cycle works but it's also there in plain sight in a way.
Basically a HTTP request comes in, goes through a parser (let's ignore it :D), then a bunch of middlewares which are basically classes and functions that take the request and some variables and return a modified request (authentication for example) or an error, it then lands on the URLs modules which we can interpret as a giant dictionary/hash which associates URLs with functions (Django's views), then once the response is ready it goes back to the middlewares so that you can optionally modify the response (gzipping for example) and then finally to the web server and the user's browser.
Most web frameworks work this way: read the request, do stuff, send a response. The how is how one differs from another.
Let me know if any of this makes sense or if it's not clear
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Julia Evans has a great e-zine explaining HTTP, but it’s a paid resource, but the article about it links to her tweets about the same info. jvns.ca/blog/2019/09/12/new-zine-o...
Hi Omar! I understand your point of view. Django is a full framework, which means it tends to hide details about how the underlying request/response cycle works but it's also there in plain sight in a way.
Basically a HTTP request comes in, goes through a parser (let's ignore it :D), then a bunch of middlewares which are basically classes and functions that take the request and some variables and return a modified request (authentication for example) or an error, it then lands on the URLs modules which we can interpret as a giant dictionary/hash which associates URLs with functions (Django's views), then once the response is ready it goes back to the middlewares so that you can optionally modify the response (gzipping for example) and then finally to the web server and the user's browser.
Most web frameworks work this way: read the request, do stuff, send a response. The how is how one differs from another.
Let me know if any of this makes sense or if it's not clear
thanks you make it clear , there is a full blog or book to read more bc I like to deep dive into it more 👍👍.
I mean theory in general behind web.
Hi! @citizen428 suggested How the Web works on MDN.
Julia Evans has a great e-zine explaining HTTP, but it’s a paid resource, but the article about it links to her tweets about the same info. jvns.ca/blog/2019/09/12/new-zine-o...
Also, my co-worker @citizen428 suggested to check out MDN’s How the Web Works.
Just found out we have a podcast episode called "HTTP with Julia Evans":
You can also find the transcript at the source: softwareengineeringdaily.com/2019/...
Hope all of these help!
BTW Julia Evans is really good at explaning things ;-)
big thanks guys , I will check them <3
There's a talk about HTTP this year in Codeland: "You and Me Learn All About HTTP" by @captainsafia :D
codelandconf.com/#talks
Thanks I book a ticket ,
Also I will buy the book mentioned above.
Thanks for help guys <3