 All right, first of all, thanks everyone for coming taking the time Yeah, my name is Nicholas This is a picture of a town called Freiburg is in South Germany. It is my current home and my workplace But of course, I'm not there right now because I'm here at the Euro Python And it's actually quite funny Euro Python. You think if you think of it, it's a compound word Python is a programming language and Europe is a continent which is a geographical concept. So you would think maybe the conference is I know 5050 split between Python and Geography, but I have found that that's actually not the case and to rectify this a bit. I'm Donating one slide of my presentation to geography. So if you're not interested, please bear with me Let's go Central Europe the red dot is actually indicating the position of Freiburg where I'm coming from it's wetched wedged in between France Switzerland and Yeah, I've actually come here by train which was really nice So the trains here in Italy were all on time air conditioned and very fast now I'm I had to cross all of Switzerland for this and of course, there's a problem because there's a There are large mountains there in Switzerland namely the Alps and Until last year you actually had to go over the mountains, but last year the Gotthard base tunnel opened up and we can just smoothly go through the mountains and Yeah, it's a really nice tunnel. It is just over 57 kilometers long and it's the longest train tunnel in the world It's actually the longest traffic tunnel of any kind in the world. So, yeah There's your geography fun fact if you if you will but of course, I'm not here to to talk about Geography or tunnels although I would like to but I'm here to talk about web development now I'm a web developer at a company called MPS Which is an abbreviation for a bunch of long German words. I won't bother you with now And yeah, just you have to know we we make medical software And the title of my presentation might be some some of you might have thought it's a bit provocative And I would like to say of course, I know Python is amazing for web developers. We have all the cool of Frameworks like Django we have flask and we have pyramids And of course, there's nothing wrong with them Of course, I'm I'm sure there's something wrong with all of them But you know, they're just amazing and please do use them if you look on Wikipedia You will find that there's actually a whole list of Python-based web frameworks that I don't even all know Some of them are considered dormant, which I'm sure it's just a nice way to say dead, but you know Um Right So these are all cool cool Frameworks that do very much very much work for you But I do suggest that sometimes it can be useful to you know, not have such a huge framework But use less use like very little to get the job done and I would like to present to you three reasons why we might want to do that. The first is You want to learn stuff, right? For example, if you wanted to learn how an internal combustion engine works You wouldn't look at the whole formula one car, but you would instead just take the engine out and see how it works And the same can be said for web development If you run into I mean if you're in web development and you have maybe a Django app or whatever You will eventually run into issues You have to debug them and you might have to understand how the Whiskey communication between your app and the server so the web server Application works you have to understand HTTP headers weird cookie configuration and all that stuff. So if you want to look at These things and try to understand them. It can be a good idea to play around with just a small very minimalized stack and familiarize yourself with them second Motivation for using less could be to avoid over engineering Over engineering is a bad idea in most I would say in most situations Right it was your time it was the resources It generates a lot of dependencies which makes it kind of make can make it hard to update stuff So, I don't know if you just want to Make a website for your parents to have their favorite cookie recipes or something then I don't know Maybe you don't need to to use Django for that and of course It's always a security risk to use more stuff because more stuff means more surface and more surface means more attack vectors just for a Fun little example if you're in the national rail operator in a country you might not want to use full-brown windows machines and which are network enabled to display your timetables because you might get hacked and the third reason and This is actually a reason why I got into Vaxxorg Yes, you might want to do something something so specific that the general the general purpose frameworks Bring with with them stuff that you just don't need And make assumptions that are just not relevant to your case so And this brings me to The product of my company Which is called chemo compile We build it together with the University Hospital in Freiburg. It is a program to plan manage and document chemotherapy treatment now chemotherapy treatment of course Can be very risky for example if you make just the tiniest error in dosage calculations You might actually harm patients if you make Make an error in maybe a date So you send out an order for chemotherapy to be prepared a day early. You might have to throw away Medication worth 15,000 euros. That's not a made-up number Right chemo compile is this is a marketing sentence, isn't it? It's built with modern web technology Whatever that means It's now used in hospitals in three European countries and if you will enumerate the Most the biggest German can't speaking countries then you might not be far off Let's go quickly over the application Architecture it's a web application as I said so somewhere in the customers Internet there's a server where our software is running and then every computer laptop Tablet that has access to the server can just use Software this is actually quite un from uncommon for professional Products they are often Client base and you have to install everything on each workstation for yourself So our customers are very happy to have a web web based Application a front-end is built with AngularJS It's a single page page application and in the back end. We are of course using Python I'm not going to tell you which version because that might be a bit embarrassing actually It's not to six though And then for the communication we have a rest API which just sends back-and-forth Jason data So this immediately Eliminates the need for any kind of HTML rendering in the back end which frameworks like Django and so forth Bring with them But there's more going on. It's not just a web application. We have to do some Actually a lot of communication behind the scenes where we have to talk to a database. That's not all that uncommon But we are also tightly integrated in the infrastructure that's already there in the hospitals So we have to talk to a hospital information center to retrieve patient data. This is done with a Protocol called health level seven has anybody ever used it or really couple So you would maybe agree that it's kind of ancient and a bit clunky at times So, yeah, for example, there's no you cannot just request patient data You have to sit there subscribe to a message queue and wait for the data to come by and Store it like in your database for later use which is can be a bit complicated. We also have to talk to lab Equipment so or lab lab servers to yeah to read basically retrieve Data about blood samples and so on Which is also done with h7 We have to talk to printers believe it or not most of these hospitals have a sort of like a printer based workflow where doctors Plan a therapy and it gets automatically printed out and at certain times in certain compute in certain printers and then people Yeah, automatically start to work on them So we have to yeah, we have to talk to printers. We have to make basically you have to make a LPR call and Finally, we have to talk to pharmacy systems Because as I told you all these chemotherapy medications, they are Well, they're highly individualized. So each Order is prepared and mixed basically for for the patient for the day Specifically so this is not a pharmacy like your corner shop pharmacy This is a pharmacy within the hospitals or basically it's more of a chemical lab basically and there is Expert softwares that handle these kinds of processes and we have to implement then Interfaces to all of these systems so yeah so this all of course happens within the intranet and for each installation there's only like maybe 20 clients maximum operating Concurrently so this really takes away a lot of Scaling things that you have in Problems that you have in regular web application because we just we just don't have to do it Yeah, so we Prototyped our application actually with Django, which was of course very easy and nice, but then we just found out at Django's It's okay. I'm not saying we couldn't have done it with Django, but we instead Decided to basically roll our own On our own stack and we did that on top of a cool tool called verge. So now Back to gives a bit of a weird word It has a lot of consonants It's very long and hard to pronounce and you of course know what's going on It's German and it's actually a German tool at a German word for tool very generic And it's actually a very generic tool as well so it kind of fits Um Right Vaxxx is developed by the Poco team if you were here on Monday I'm in Ronaha is a famous member of that team Other products include flask Sphinx, ginger to the templating engine and more It's called well the documentation calls it a whiskey utility, so it's specifically not called a framework and Yeah, because it's just intentionally left very lightweight. It's basically yeah, it's a toolbox. It's a toolbox for replication And not more it leaves you very very much freedom to use Whatever things you want to plug on top of it or leave them out right it has no or M no templating engine none of these things that most frameworks would bring with them and It's yeah, it's the basic of flask the basis of flask if you've ever worked with flask You have actually also worked with back toic and the Wikipedia page says it says it's also the base for others But I don't know what these other things are Okay, let's go quickly over the features of back toic Yeah, it's the most important thing it's it's for making whiskey applications whiskey is for those of you who don't know But it's a web server a gateway interface. So it's the protocol that python applications who generate dynamic Websites used to talk to the web server the web server being an engine X or Apache One of those programs. It's whiskey 1.0 compatible. It has a lot of helpers to To facilitate the communication between with the web server for example The most important concepts in a whiskey or in any web application really are of course requests and responses. So The client requests something Responses generated by your program and sent back. So these are actually wrapped in back toic with Objects that let you introspect them work with them create them and so There's a couple of HTTP utilities this sort of touches on on the Learning how stuff works thing that I said earlier There are nice nice tools to introspect headers to yeah, basically look at headers parts form data handle cookies write cookies parse cookies validate cookies I guess It has unique could support of course It has an URL routing system Which is optional. So you don't actually have to use it But it's of course something that most replication would use in any In any form. So there's a nice routing system, which is also very lightweight. We look at it in a second And for developers, it's actually this is my favorite part about works. It's very friendly towards developers You have a nice test client and not environment builder which lets you Which lets you build environments to test your application in different kind of Circumstances and there's a nice interactive debugger. I think that's also part of flask so you can Interactively debug your application in the browser Yeah, let's look at how a basic works like application looks This is it you just have one function and the function takes two arguments in viral and start response and these two arguments actually Given by the whiskey protocol. So in viral is basically holds the environment information Which is the request and configuration data and start response is information needed to then send the Response back How it works like you can then use the request Constructor to get in at the actual request out of the environment You can then access for example in the arguments so the action get get arguments in the URL with that object and you can use a response construct have to put to basically Construct the response and send it back And then you have yeah, I have a nice test runner run simple which just runs your server for development purposes This gets even easier With the request application Decorator which takes away or sort of hides the parsing of the request because this is something that you would most like They want to do all of the time and you can just return a response object So this is the easiest application that you could build notice that there is no no URL Mapping routing of any kind going on So every request no matter the path would just go to this one function But if you would want to do URL routing you can use the nice built-in Map functionality you would just build your URL map and you would have it You would pass it a bunch of rules and these rules basically consist of a URL template and an endpoint and the endpoint can be anything So it's very simple. Also in this Regard most of the time, of course the endpoint would be some kind of view function here I just have some strings and in your yeah in your URL templates you can use placeholders For example, you can request an integer you can request any Yeah, any of a couple of values or just a default which is the last Example which is then just passed as a string and Yeah, this is how you would use it. I'm a bit I'm a bit behind so I'm just gonna skip over this Another nice concept in vector got a middlewares Middlewares are just a cool concept to compartmentalize your application So you would have logically Separated parts of your application as single waxer applications and you can combine them as needed For example, you would have a part of the application that needs database access You would have a part of the application that maybe don't it doesn't and you would also serve static files You can then connect them in work site with You could connect them in work site in this fashion and all of these objects are middlewares, so In the end a request would come would come through and would be passed to the first middleware which would take care of user authentication and Then if it's if the request is for static file would go to the static file middleware and The response would be sent back up and then there's a special dispatch of middleware which can dispatch between different whiskey apps and For the database part We also use a db connection middleware which we can plug on top of it and Yeah, any of the middlewares can manipulate the requests or the response Can decide to send it to different parts or can decide to Just send the response back up This is how you would look in the code So this build application function would just take an app and put shells of middlewares just around it How this is basically the example of from the previous slide and you would wrap your my database app In a db connector middleware and you would then plug that in Into a dispatcher middleware which takes the non The my regular app which is the part without the db app access under one URL root and the now db connected part under another URL and then we can wrap around the shared data middleware to serve static files and this is of course something you would only do in In the development environment because in your production environment you would most likely do that with your web server So this is very nice if you yeah, you can with these middlewares you can have different setups for different Yeah use cases very easily for example the last thing that we wrap around is the authentication middleware Which we would maybe not want to use in our development stack because we Or in our test stack because we don't want to deal with authentication all of the time The HTTP utilities I'm just gonna gloss over There's apparently HTTP has a bit of weird Date formats and also different dates formats and we're so it has Utilities to parse and write all of these Yeah, you can as I already said read and write cookies easily you can for example parse form data This is what it would look like You would you just simulate simulate a request with form data and in the end we can access it with a dictionary Now the fun part is always the testing right Works it has this really nice concept of the test client and I'm not a hundred percent sure but I think it's basically the same in flask and Yeah, you can just parse the client your your application and then you can call on this client All of the your favorite HTTP methods get post delete put will have you Give them the URL you want to access and if you have data or want to Pass special HTTP headers. You can also give it to them to to the client and And you just get the response back and you have now are just simulated the whole Replication which is very nice and then you can run assertions like I want to have like a success status and The data should look like this Very nice to use very nice to use as a pie test fixture for example just This is of course very eat very simple, but in in a fixture you could also do the Plugging together of the middlewares and everything Then you yeah, you just define this once and just use the fixture Everywhere or you could have different kinds of clients for example as I said, maybe you don't want to have the authentication in most of your tests so you have a client that doesn't use the It doesn't use the authentication and you have a special off client which just Wraps around the authentication middleware and when you want to test the authentication you use this fixture to for example check that If you're not logged in you get a 401 Now I'm not brave enough to do a live demo. So you will have to live with the screenshot of the live debugger Here I have just put together a simple application if you look at the URL bar. I requested 18 for something and I got a key error. So I can Just go into the browser open up an interactive terminal where I get thrown into the scope and I can introspect all All the things in the scope and I find out I have actually requested the I've actually requested the location of Europe Python 2018 which is as far as I know not defined yet and this is the problem with my application This debugger is also implemented as a middleware So if I want to use it, I just wrap the debugger middleware around My application and any exception that bubbles up will just get caught and presented in this nice way Yeah, so those are the things I wanted to mention these are of course only the things that I use mostly with Wackzeug Please take a look at the great documentation If you if you want to see what what other things there are Yeah, and if you have a Wackzeug application, you can use you can just do anything on top of it Right, you can connect to a database we for example your sequel alchemy, but you can use your favorite or M You could use ginger to to render documents which we do for example to render PDF documents Use salary to schedule tasks Asynchronous asynchronously or any other task runner that you like Talk to third-party applications with requests for example to to call other APIs Makes this calls and I don't know go wild Remote control a robot to wash your dishes or whatever That's pretty much it. Thank you for listening if you would like to talk to me about Yeah, tunnels train tunnels or Wackzeug talk come talk to me or find me on Twitter. Thank you All right, we've got five minutes for Q&A any questions Just one question. I'm curious about why What did you prefer of that? So I go there are other choices like web app or I don't know other webop Which is the foundation of pypyramid and pylons and it's nearly the same so Well, I'm fully disclosure. I was actually not around when we made that decision. So I don't know. I don't also don't know The tool you were talking about I guess it's just a matter of taste In the end we wanted to be very much in control of the stuff. So we wanted to have Yeah, lightweight libraries and write most of the stuff ourselves, but you could you could have used most other tools as well Over here. Thank you for your talk. It was really nice Out of curiosity, which parts of Django were too bloated for you? Yeah, well as I said it's it's just for these For these these special applications as I said Template rendering for example, we didn't want to use that. We also didn't want to use the Django ORM Which is I guess just a matter of taste And at the time. Yeah, we were just not all of us were not too familiar with Django. So then the difference So yeah, we had to make a decision basically to learn Django in like an expert level Which we didn't really know if it would benefit us enough. So or the other alternative was to roll our own stuff Any more questions? Okay, I have a question for you. Um When would you choose Vexoic versus Flask and why? I don't know. It really depends on As I said, I'm not I'm not just suggesting that you can't do all these things with other things I think Django REST is also in existence. I maybe have to look at this Yeah, Flask brings with it On top of this routing systems, I think the ORM is also optional. It's like a plug-in. I don't know I think yeah, it depends on the on the on the use case It's I think it's a really nice tool to to learn stuff if you want to dig into how how HGP-Whiskey work use work talk Yeah, or yeah, if you want to do something special Oh What is this start response function in the whiskey function? Yeah Besides of the environment I Would have to say I don't really know. All I know is that it's somehow it's a callable It's somehow used to Generate the request. You're not do you know more about this? It's part of the whiskey spec I think yeah, it's a callable which I don't know if you look at the whiskey spec, which is in a pep somewhere explains it Yeah, all right Think we're done. Thank you very much. Thank you