PyCon 2014

Analizando en detalle el ciclo petición-respuesta de Django

Dan Langer  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

actually like it actual i was even waving frantically wing and nervous and i'll be standing next to alright but hopefully if 2500 yeah we should have a couple of minutes for talk f 5 17 is all good that's right at that time it's hard to please

everyone I guess all the different ways people want to use collection of dongles for every possible situation I'm betting they still don't have mine down here thank God is it is it eh hdmi like now let's display board all right it's about time

to get started the first talk in this session is by Dan Langer he's gonna give his a scenic drive through the Django request response cycle give him a hand thank you now seymour hoffman's I me my name is Dan Langer I'm a developer and manager wave

in Toronto or a small or a startup that helps small businesses be successful with their online tools and I'm gonna talk about the generous with request and response cycle because that's where I spend the majority of my time when I'm working with

Django now I've been doing Django for about pull over two years and Jago does have a lot of moving parts that something I've come to accept enjoy deal with but when you're starting out it's not at all obvious how they all fit together it's

recently going working with some guys on my team who are experienced to us but rails devs and just coming to django they went and we're struggling with notions like I have this variable how do I get it into a template which appeared obvious to me but apparently

isn't if you're coming from background that doesn't have so many different layers of moving parts so I'm going to talk about that and in particular how request turns into response which i think is one of the most fundamental not the most fundamental

operations Django now speaking with up all those moving parts and without giving away the ending this is somewhat how it all works and it's great out for a reason because we'll talk about it as we go through it but you can see there's a lot going

on here this a number words repeated there's sort of a u-shaped thing going on there's the word middleware in a bunch of places so let's talk about what this actually means and if we're gonna do that we should start with the request because

it all begins there so in a log a long long time ago in a console far away the galaxy called Toronto someone typed this into their command prompt they said I want to curl out to Daniel anger calm / hello / MTO and they pressed enter and then they got this

and this is Carl saying what it's actually going to do and that's what it's doing it's sending her up a HTTP 1.1 get request to / hello / MTL saying i want a response from the host Daniel Agger calm and I'm going to accept just about anything

that comes back and from there it went across the internet and I'm not going to talk about how the internet works because that is a talk in and of itself but trust me when that person being me in this case pressed enter the request did go out across the

internet and ended up at something that looks like this in a data center what we're going to call the web server now in practice this web server was probably engine ax or Apache but that's just use popular nowadays bottom line is it's a web server

and the web server fundamentally takes a request and gives back out a response depending on how it does that changes on what kind of request we're talking about it's a static request if it's something simple a file it's just on the machine

the web server will probably just handle it itself stream the response back out and get on with itself but if it's more complex if sitting something that's powered by a web application like Django let's say gets a little more complicated is that

it we have to ask the question well how does the web server itself which may be written in C or something how does that communicate with the Python process that's rounding Django and this has changed in the past ten years or so back in the day of the early

2000s there wasn't a simple way to do it different web servers did it in different ways different frameworks to it in different ways some web server support mod Python some frameworks port a fast CGI and it meant that you assert your choice of web server

and web framework was heavily coupled together which both slowed innovation in a pissed-off web server people up saints deal with framework people and pissed off framework people excited to care about web surfers and nobody like that so what we ended up with

was pep 333 called whiskey the web server gateway interface and it's the answer to the question of how to python frameworks and web servers in your act in a common and simple way and by web applications i'm talking about things like django the big

value of whiskey and pep 33 when it came out was simplicity in these diplomat because the guys who wrote it knew that if it wasn't simple and if it wasn't easy to switch no one would actually do anything it would be left where we were so they went

and they made it simple and they made one real entry point between your whiskey layer and your web server that the web server guys develop and your web application and this is about your minimal possible whiskey compatible application you can see the whiskey

protocol which is a call and I'm saying callable deliberately and not function a callable that takes two arguments which have particular formats of the standard talks about does some stuff to it and then returns an iterable of strings now whiskey is careful

not to talk about how the web server actually deals with this it just specifies that given this it can run in a particular way and it will get back something that handles a web response the other thing to highlight there is that there's nothing stateful

in it every request has its own Enver on has its own start response there's nothing in there that lets by definition the whiskey keep track of one response to another so any type of persistence any type of session management has to happen down in the web

application layer now probably thinking if I've said the whiskey is the way that web servers communicate will have applications and if Django is web application that runs does it speak whiskey the answer of course is yes so in general and your whiskey

[ ... ]

Nota: se han omitido las otras 3.224 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.