Python and Angular, a perfect match?
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Braun, Oliver
Python and Angular, a perfect match? Python on mobile devices is still negligible mostly because of the GUI problems which arise. But Python on android devices is considered to be a solved problem since the module Python for Android is available. We have nowadays at least the possibility to develop for mobile devices with the GUI engine Kivy which is maybe the first choice for rapid prototyping on that platform. But as it comes to design work and mobile device look alike Kivy is still far behind the web development tools HTML/CSS. In our talk we present a conceptual work where we used Ionic - this is an mobile development framework based on Angular - to build the GUI part of an app and connected that to a Python back end. In our point of view our proposal is very general and will give Python a boost towards modern UX development and makes HTML/CSS/JavaScript a real option especially in combination with Angular. The main part of our solution that we show is the interoperation between JavaScript and Python such that asynchronous calls in both direction are possible. The advantage is to develop UX and back end code only once and use it literally on every platform where a Python interpreter and a browser runs
 Good afternoon, ladies and gentlemen. Hello everybody, thanks for attending this talk. I am going to speak about Pison and Angler and raise the question if this would be a perfect match. My name is Oliver Braun and I am a co-founder of a small company located in Stuttgart, Germany and our main focus is to connect machines in the context of industry 4.0. Okay, so let's start. This is the outline. First, I will show you kind of preliminary arguments. So what are our thoughts to end up what we have built here? I will show you how we did it and I will go into some details. Of course, it is not, we have not reinvented the wheel, but I will show you some details so that you will like have a better start-up if you want to do it the same way we did it. And at the end, I will show you an example and if time, maybe also a live example. Okay, so introduction, GUI is still a hard decision. Why is Python lacking on mobile devices so much? So of course, there are many, many reasons. Of course, it is not native and so on. But I think at least on Android, it should be possible because it is kind of a Linux system. So why is this so? This is a thesis which is kind of general, but I have to stress it. For us, it would be better to write software in Python when it fits, so even on client side, we would like to do this really a lot. And on server, of course, it is well-established. For Python, there is still missing a standardized GUI framework on mobile devices. So at least this, in our point of view, at least this is one of the main reasons why it is not so much widespread. For example, there is no easy concept for incorporating PyQt5, which is quite common on desktop for mobile devices. I mean, at least I haven't seen any practical project doing this. Maybe there is and I would be lucky to get to know this. This is what we would expect from modern GUI framework. So it is really, I think, well-known. So you have these three parts, the view and the view model, which are connected by some data binding. So every time you change the view model, the view should be changed. And every time the view is somehow sending an event, the view model has to be noticed about this. And the model on the right-hand side is kind of loosely coupled to this setup. And in the model, that's the business logic, of course. Now, let's kind of wind up. Have you ever heard of Kivi? So Kivi is more or less the only way to implement at the moment GUI on the mobile devices, connecting a Python kind of back end. Yeah, that's the only choice. So sorry for missing this point. But it's still missing some standardize elements. And it's hard to do your own graphics on it, because, I mean, it's kind of lacking documentation. So maybe it has made progress in the last year, which I haven't followed very well. But at least at that time, I have used it. It was not so well documented. I mean, the standard. So if you, for example, do rapid prototyping, it's really doing a good job. But if you want to deliver a rollout project very well designed, it's hard to do it in Kivi. And of course, this is one of the main legs. It's not common up to now. So there is no specialist on the market available. And so it's really also a business kind of decision that you do not use this kind of thing if you are not the graphics designer by yourself. So what is the thing with the HTML frameworks? Of course, these engines are the most advanced GUI engines also on the mobile devices. I mean, there are lots of reasons why this is so. I think it's because of the backbone of the Internet. So the GUI engines are really well designed. They are fluent and so on. So they are really good. There are specialists available on the market. So it's very well known, very nicely structured with respect to graphics definitions. So you know this maybe very well, graphics you do mostly in CSS or something related. And it's kind of separated. So you really have a separated branch with graphics. But JavaScript by construction is not open for interacting natively and directly with other languages. Of course, this is because of security issues. I mean, you do not want to do this. But in our point of view, it's very sad because the opportunities or the really nice engines are sitting there just speaking JavaScript. And we would like to implement our Python back end on this. Okay. I will show you the general concept. We combine Angular in a general way with Python via Web sockets. The calls which we are doing from one side to another are asynchronous in the sense. There's no direct return value. I mean, asynchronous, we have heard a lot on this conference. It's all about async I.O. And if you really want to do something async I.O., you have to set up your Python back end in a special way. But we think of it right now as there are calls in both directions with no direct return value. Our concept works for all of the clients. Also mobile, which used to have GUI on end, back end on their own. So what is the use case? Think of local data analysis concepts or cryptography or these things you would like to perform locally on your mobile phone or on your desktop even. You would like to have a real well-designed back end working directly with the front end. Yeah. And with some limitation, it works also for a web client if you have services ready in your network. This is simply because Web sockets is so general that you can connect to somewhere else, not only local host. We have not taken care about security at the moment because we are using it at the moment just on local host. You have to or one has to put more work on it to make it secure. But I think there's no real problem with this. This is kind of a different approach that then we have heard lots of times on this conference. I mean on the right-hand side, you see this is the typical set up which is proposed a lot. There's some HTML framework works as a front end and your Python web server acts as a back end. E.g. flask with REST API or whatsoever. The problem here is especially for our case, use case, there's no need for HTTP server. So, why put something up which is totally oversized? No need. And on the other hand, the HTTP server cannot act on its own towards the client. So think about something happens in the back end or the back end is performing a new event coming from somewhere else. There's no possibility to signal to the front end except with maybe this kind of IAJAX but you really do not want to do this because I mean it's well known, it's established, but it's overhead. So what is Angular? Angular is a web-based framework for view and view model binding. It was redesigned recently. It has a new clear concept for injection services and components. And injections is kind of your services which provides in a general way the data. So the injections and services are on the view model side. So in the middle, the components are on the left-hand side. So the components are your view components. And it's anybody has maybe, somebody has maybe experienced with Angular 1 or AngularJS. What was the name? And yeah, I've heard some opinions about this. This is awful. I have gone through also AngularJS. It was not so awful but Angular in fact is really clear in design. So it has happened something here. It's based on TypeScript. So it's a strongly typed version of JavaScript. And so yeah, it overcomes some lackings of Java itself. What do I mean here with asynchronous calls? I have told you. And how do we perform these? So typical action flow in our backend GUI pattern is a text input happens on an input field or whatsoever. An event is triggered as a message. And a message is sent to the backend. The backend is doing fancy stuff and creates a message for Angular. And last but not least, Angular is doing the view update automatically. So it's a closed loop here. But of course, the price and backend can act also totally by itself. It can send messages and events to the front end. How do we do this? There's a WebSocket connection. So this is not really new but it works here. We are redirecting events from a WebSocket to a Python function. We set the WebSocket server on the Python side here just to see how, just some details. I mean, it's interesting, I think, to see this if you have not experienced it before, if you know it, okay, it's not really new. You can actually get the methods out of class also by get attribute. So here. So let's go a little bit through this. Every time a payload comes in, it's kind of triggering this function. This function is interpreting the JSON payload. And if it is a JSON payload, it looks up for the name and the arguments therein. So this. And tries to invoke a method which is part of this class. And yeah, just puts the arguments which were given to this method. And nice thing here is, so there are some drawbacks. We have no security, so here we assume that there is a name and an argument. But nice thing is we get full trace back if it fails. So for example, the function is not written here or in this class, it fails. And you can, for example, push the trace back to the front end back. The connected Python module must inherit from this junction which is doing this magic behind. The web socket message should be constructed like the following. And this is what you need to know and what you need to obey here. So you have your message. And this is JavaScript or TypeScript code. You have your message and it is constructed in a JSON-like way. You have a name, you have arguments, and on top, if you want also action where you can kind of decide, make some decisions in the back end. But we have not needed up to know. It's just a placeholder. And here we see the message service sends this message to the back end. Client on Angular side. So let's see. We have a web socket client which is used as a service in Angular. It's a message and a message service on top which can handle incoming messages on registry.components. And this is also JavaScript or TypeScript code. So we see here that we can subscribe to this service in the following way that we have, that we can tell JavaScript what to do when this message comes in. And here we have the manage message method which kind of is doing something. So it's not so elegant as on the Python side, but of course it's JavaScript. The events in Angular are handled in this way that we have Rxjs observables which is a concept which is implemented or which is interconnected to Angular somehow. So it's not Angular itself, but it's interconnected. You have or you access control of a data stream within every part of the app with this concept. So for example, here we have an update service and it's a class and it's also an injectable. This means it's a singular, it can act as a singular service in Angular. And so the code here is not so, it's really a standard. So you say, okay, this is a subject here. And you can make subscriptions to it and you can push something to it. And here's the subscribe logic. So the subject injectable can be used wherever it is put into the module setup. So module setup is really important for Angular and it must be made local in the constructors. That way if you want to use the service somewhere in your Angular code, you have to load it in the constructor this way. And in the module setup, there's also the same service. It says, okay, if this constructor wants the service, it's the same as everywhere. So it's not a new instance of the service, but it's the same. And so you have very good overview of what happens in your Angular code. So it's really nicely structured. Chat program is a typical example. But it's actually the chat program we made maybe a year ago. And the thing is that the chat program works very well with this concept. But we have also some different kind of projects also based on this concept, which make really progress because of our setup. So we have made good experience with it. So let's see. How can we use it? So this is a sort of, we used here Yonic. And in this setup I used, in fact, the older version of Yonic, which is based on Angular 1. But there's no difference. In fact, there's also new Yonic. With Yonic, you can make use of Angular. And also nowadays of the new Angular, all HTML elements are mobile ready. So they are really nicely, they have a really good concept of these HTML elements so that they fit really nice together. You can also start this on a desktop. So it's really the same on all devices. It's fluent and so on. And for, yeah, the only problem you have to solve here is that you need a bootstrapping. So you have to put it somehow on your mobile device. And usually you would do this also with Kiwi, with the help of Kiwi, which is closely interconnected to Python for Android. We are not as far as this, but we would like to have kind of a module made out of this so that the structure is somehow close together. It should look like this. It's nothing special. We have just some imports of the local server, of the Stunction thing. And so we just need to define a class which defines your backend tasks. Next we have to raise this class or instantiate it, instantiate the server, so which is a non-blocking server somehow, and make a connection between the server and your backend tasks, and then start the GUI, which is just open the browser. You can do it with the help of some Python commands. And this browser just takes your HTML, and everything behind the scene is working well. So let's wrap this up. Angular for us is the missing part of productive GUI development with Python. Angular does the heavy lifting concerning JavaScript and HTML connection. We think Python and Angular is a perfect match. So the graphics looks like this. In our point of view, this is our preferred architecture. And it works for at the moment for a medium-sized project very well. We make good progress in this. Angular is on the side of the view and the view model. And Python, of course, is on the side of the model. And contains all business logic and data. Thanks for your attention and question, please. Are there any questions? Hello. Thank you for the talk. I'm wondering why wasn't it possible to maybe come up with another kind of implementation like keeping Angular in the front-end side and Python in the back-end side, exposing the functionalities that you want to expose in the back-end side via REST API, and to issue some Ajax calls from the front-end to the back-end through Angular. It's totally possible. You have to ask yourself how much work you have to put into this. And how much easier is this? So of course, if you have understood you correctly, you raised a question about the Ajax calls. Yeah, it's possible. I know. It's fine if you want to totally kind of separate these things. Yes. But, of course, you need to put much more work in it. Or at least I think. So maybe if you are Ajax expert, it's like nothing for you. But if you are new to this kind of subject, you would kind of avoid this. Okay. Thank you. Some more questions. We have enough time. Thanks for the speech. You mentioned bloated HTTP servers. Could you please elaborate a little bit more on WebSockets versus HTTP servers in this case? Can you please repeat? You mentioned bloated HTTP servers and then told us about WebSockets. Could you please tell us a little bit more about your perspective on comparison between HTTP servers and WebSocket solutions? So the thing is the WebSocket is cheap. It's kind of really almost no overhead. I personally think, but I have not measured it. It's much faster. It is, the setup is much easier as I have mentioned earlier. And yeah, I think it's what you need. So you should focus on what you need. And this is what we needed. It's faster, I think. I have to measure this. Some more questions? None? Give a big hand for, okay. Last question. I would like to know if it's possible to connect Angular to the backend through the router of Angular, for example. And if you use, for example, Angular 4, you have a router available for a single page application and you can connect to the backend of Python through the REST API. I think that you told that at the beginning of your talk. And I don't understand why this solution is less effective than your solution through WebSockets. I know that there's a router and we are using it in our project also. But yeah, if you have set up, if you once have set up this solution, you would not, at least me, I'm kind of strict. Yeah. I would not like to have a second web server. Why? There's no reason for this. I mean, you can do it. It's actually really no problem. You can do it. But in my opinion, why do you want to have two HTTP servers? No. Okay. Yeah. Then give a big hand now for Oliver. Thanks.
 Good afternoon, ladies and gentlemen.  Hello everybody, thanks for attending this talk.  I am going to speak about Pison and Angler and raise the question if this would be a  perfect match.  My name is Oliver Braun and I am a co-founder of a small company located in Stuttgart, Germany  and our main focus is to connect machines in the context of industry 4.0.  Okay, so let's start.  This is the outline.  First, I will show you kind of preliminary arguments.  So what are our thoughts to end up what we have built here?  I will show you how we did it and I will go into some details.  Of course, it is not, we have not reinvented the wheel, but I will show you some details  so that you will like have a better start-up if you want to do it the same way we did it.  And at the end, I will show you an example and if time, maybe also a live example.  Okay, so introduction, GUI is still a hard decision.  Why is Python lacking on mobile devices so much?  So of course, there are many, many reasons.  Of course, it is not native and so on.  But I think at least on Android, it should be possible because it is kind of a Linux  system.  So why is this so?  This is a thesis which is kind of general, but I have to stress it.  For us, it would be better to write software in Python when it fits, so even on client  side, we would like to do this really a lot.  And on server, of course, it is well-established.  For Python, there is still missing a standardized GUI framework on mobile devices.  So at least this, in our point of view, at least this is one of the main reasons why  it is not so much widespread.  For example, there is no easy concept for incorporating PyQt5, which is quite common  on desktop for mobile devices.  I mean, at least I haven't seen any practical project doing this.  Maybe there is and I would be lucky to get to know this.  This is what we would expect from modern GUI framework.  So it is really, I think, well-known.  So you have these three parts, the view and the view model, which are connected by some  data binding.  So every time you change the view model, the view should be changed.  And every time the view is somehow sending an event, the view model has to be noticed  about this.  And the model on the right-hand side is kind of loosely coupled to this setup.  And in the model, that's the business logic, of course.  Now, let's kind of wind up.  Have you ever heard of Kivi?  So Kivi is more or less the only way to implement at the moment GUI on the mobile devices, connecting  a Python kind of back end.  Yeah, that's the only choice.  So sorry for missing this point.  But it's still missing some standardize elements.  And it's hard to do your own graphics on it, because, I mean, it's kind of lacking documentation.  So maybe it has made progress in the last year, which I haven't followed very well.  But at least at that time, I have used it.  It was not so well documented.  I mean, the standard.  So if you, for example, do rapid prototyping, it's really doing a good job.  But if you want to deliver a rollout project very well designed, it's hard to do it in  Kivi.  And of course, this is one of the main legs.  It's not common up to now.  So there is no specialist on the market available.  And so it's really also a business kind of decision that you do not use this kind of  thing if you are not the graphics designer by yourself.  So what is the thing with the HTML frameworks?  Of course, these engines are the most advanced GUI engines also on the mobile devices.  I mean, there are lots of reasons why this is so.  I think it's because of the backbone of the Internet.  So the GUI engines are really well designed.  They are fluent and so on.  So they are really good.  There are specialists available on the market.  So it's very well known, very nicely structured with respect to graphics definitions.  So you know this maybe very well, graphics you do mostly in CSS or something related.  And it's kind of separated.  So you really have a separated branch with graphics.  But JavaScript by construction is not open for interacting natively and directly with  other languages.  Of course, this is because of security issues.  I mean, you do not want to do this.  But in our point of view, it's very sad because the opportunities or the really nice engines  are sitting there just speaking JavaScript.  And we would like to implement our Python back end on this.  Okay.  I will show you the general concept.  We combine Angular in a general way with Python via Web sockets.  The calls which we are doing from one side to another are asynchronous in the sense.  There's no direct return value.  I mean, asynchronous, we have heard a lot on this conference.  It's all about async I.O.  And if you really want to do something async I.O., you have to set up your Python back  end in a special way.  But we think of it right now as there are calls in both directions with no direct return  value.  Our concept works for all of the clients.  Also mobile, which used to have GUI on end, back end on their own.  So what is the use case?  Think of local data analysis concepts or cryptography or these things you would like to perform  locally on your mobile phone or on your desktop even.  You would like to have a real well-designed back end working directly with the front end.  Yeah.  And with some limitation, it works also for a web client if you have services ready in  your network.  This is simply because Web sockets is so general that you can connect to somewhere else, not  only local host.  We have not taken care about security at the moment because we are using it at the moment  just on local host.  You have to or one has to put more work on it to make it secure.  But I think there's no real problem with this.  This is kind of a different approach that then we have heard lots of times on this conference.  I mean on the right-hand side, you see this is the typical set up which is proposed a  lot.  There's some HTML framework works as a front end and your Python web server acts as a back  end.  E.g. flask with REST API or whatsoever.  The problem here is especially for our case, use case, there's no need for HTTP server.  So, why put something up which is totally oversized?  No need.  And on the other hand, the HTTP server cannot act on its own towards the client.  So think about something happens in the back end or the back end is performing a new event  coming from somewhere else.  There's no possibility to signal to the front end except with maybe this kind of IAJAX but  you really do not want to do this because I mean it's well known, it's established,  but it's overhead.  So what is Angular?  Angular is a web-based framework for view and view model binding.  It was redesigned recently.  It has a new clear concept for injection services and components.  And injections is kind of your services which provides in a general way the data.  So the injections and services are on the view model side.  So in the middle, the components are on the left-hand side.  So the components are your view components.  And it's anybody has maybe, somebody has maybe experienced with Angular 1 or AngularJS.  What was the name?  And yeah, I've heard some opinions about this.  This is awful.  I have gone through also AngularJS.  It was not so awful but Angular in fact is really clear in design.  So it has happened something here.  It's based on TypeScript.  So it's a strongly typed version of JavaScript.  And so yeah, it overcomes some lackings of Java itself.  What do I mean here with asynchronous calls?  I have told you.  And how do we perform these?  So typical action flow in our backend GUI pattern is a text input happens on an input field  or whatsoever.  An event is triggered as a message.  And a message is sent to the backend.  The backend is doing fancy stuff and creates a message for Angular.  And last but not least, Angular is doing the view update automatically.  So it's a closed loop here.  But of course, the price and backend can act also totally by itself.  It can send messages and events to the front end.  How do we do this?  There's a WebSocket connection.  So this is not really new but it works here.  We are redirecting events from a WebSocket to a Python function.  We set the WebSocket server on the Python side here just to see how, just some details.  I mean, it's interesting, I think, to see this if you have not experienced it before,  if you know it, okay, it's not really new.  You can actually get the methods out of class also by get attribute.  So here.  So let's go a little bit through this.  Every time a payload comes in, it's kind of triggering this function.  This function is interpreting the JSON payload.  And if it is a JSON payload, it looks up for the name and the arguments therein.  So this.  And tries to invoke a method which is part of this class.  And yeah, just puts the arguments which were given to this method.  And nice thing here is, so there are some drawbacks.  We have no security, so here we assume that there is a name and an argument.  But nice thing is we get full trace back if it fails.  So for example, the function is not written here or in this class, it fails.  And you can, for example, push the trace back to the front end back.  The connected Python module must inherit from this junction which is doing this magic behind.  The web socket message should be constructed like the following.  And this is what you need to know and what you need to obey here.  So you have your message.  And this is JavaScript or TypeScript code.  You have your message and it is constructed in a JSON-like way.  You have a name, you have arguments, and on top, if you want also action where you can  kind of decide, make some decisions in the back end.  But we have not needed up to know.  It's just a placeholder.  And here we see the message service sends this message to the back end.  Client on Angular side.  So let's see.  We have a web socket client which is used as a service in Angular.  It's a message and a message service on top which can handle incoming messages on registry.components.  And this is also JavaScript or TypeScript code.  So we see here that we can subscribe to this service in the following way that we have,  that we can tell JavaScript what to do when this message comes in.  And here we have the manage message method which kind of is doing something.  So it's not so elegant as on the Python side, but of course it's JavaScript.  The events in Angular are handled in this way that we have Rxjs observables which is  a concept which is implemented or which is interconnected to Angular somehow.  So it's not Angular itself, but it's interconnected.  You have or you access control of a data stream within every part of the app with this concept.  So for example, here we have an update service and it's a class and it's also an injectable.  This means it's a singular, it can act as a singular service in Angular.  And so the code here is not so, it's really a standard.  So you say, okay, this is a subject here.  And you can make subscriptions to it and you can push something to it.  And here's the subscribe logic.  So the subject injectable can be used wherever it is put into the module setup.  So module setup is really important for Angular and it must be made local in the constructors.  That way if you want to use the service somewhere in your Angular code, you have to load it  in the constructor this way.  And in the module setup, there's also the same service.  It says, okay, if this constructor wants the service, it's the same as everywhere.  So it's not a new instance of the service, but it's the same.  And so you have very good overview of what happens in your Angular code.  So it's really nicely structured.  Chat program is a typical example.  But it's actually the chat program we made maybe a year ago.  And the thing is that the chat program works very well with this concept.  But we have also some different kind of projects also based on this concept, which make really  progress because of our setup.  So we have made good experience with it.  So let's see.  How can we use it?  So this is a sort of, we used here Yonic.  And in this setup I used, in fact, the older version of Yonic, which is based on Angular  1.  But there's no difference.  In fact, there's also new Yonic.  With Yonic, you can make use of Angular.  And also nowadays of the new Angular, all HTML elements are mobile ready.  So they are really nicely, they have a really good concept of these HTML elements so that  they fit really nice together.  You can also start this on a desktop.  So it's really the same on all devices.  It's fluent and so on.  And for, yeah, the only problem you have to solve here is that you need a bootstrapping.  So you have to put it somehow on your mobile device.  And usually you would do this also with Kiwi, with the help of Kiwi, which is closely interconnected  to Python for Android.  We are not as far as this, but we would like to have kind of a module made out of this  so that the structure is somehow close together.  It should look like this.  It's nothing special.  We have just some imports of the local server, of the Stunction thing.  And so we just need to define a class which defines your backend tasks.  Next we have to raise this class or instantiate it, instantiate the server, so which is a  non-blocking server somehow, and make a connection between the server and your backend tasks,  and then start the GUI, which is just open the browser.  You can do it with the help of some Python commands.  And this browser just takes your HTML, and everything behind the scene is working well.  So let's wrap this up.  Angular for us is the missing part of productive GUI development with Python.  Angular does the heavy lifting concerning JavaScript and HTML connection.  We think Python and Angular is a perfect match.  So the graphics looks like this.  In our point of view, this is our preferred architecture.  And it works for at the moment for a medium-sized project very well.  We make good progress in this.  Angular is on the side of the view and the view model.  And Python, of course, is on the side of the model.  And contains all business logic and data.  Thanks for your attention and question, please.  Are there any questions?  Hello.  Thank you for the talk.  I'm wondering why wasn't it possible to maybe come up with another kind of implementation  like keeping Angular in the front-end side and Python in the back-end side, exposing  the functionalities that you want to expose in the back-end side via REST API, and to  issue some Ajax calls from the front-end to the back-end through Angular.  It's totally possible.  You have to ask yourself how much work you have to put into this.  And how much easier is this?  So of course, if you have understood you correctly, you raised a question about the Ajax calls.  Yeah, it's possible.  I know.  It's fine if you want to totally kind of separate these things.  Yes.  But, of course, you need to put much more work in it.  Or at least I think.  So maybe if you are Ajax expert, it's like nothing for you.  But if you are new to this kind of subject, you would kind of avoid this.  Okay.  Thank you.  Some more questions.  We have enough time.  Thanks for the speech.  You mentioned bloated HTTP servers.  Could you please elaborate a little bit more on WebSockets versus HTTP servers in this  case?  Can you please repeat?  You mentioned bloated HTTP servers and then told us about WebSockets.  Could you please tell us a little bit more about your perspective on comparison between  HTTP servers and WebSocket solutions?  So the thing is the WebSocket is cheap.  It's kind of really almost no overhead.  I personally think, but I have not measured it.  It's much faster.  It is, the setup is much easier as I have mentioned earlier.  And yeah, I think it's what you need.  So you should focus on what you need.  And this is what we needed.  It's faster, I think.  I have to measure this.  Some more questions?  None?  Give a big hand for, okay.  Last question.  I would like to know if it's possible to connect Angular to the backend through the router  of Angular, for example.  And if you use, for example, Angular 4, you have a router available for a single page  application and you can connect to the backend of Python through the REST API.  I think that you told that at the beginning of your talk.  And I don't understand why this solution is less effective than your solution through  WebSockets.  I know that there's a router and we are using it in our project also.  But yeah, if you have set up, if you once have set up this solution, you would not,  at least me, I'm kind of strict.  Yeah.  I would not like to have a second web server.  Why?  There's no reason for this.  I mean, you can do it.  It's actually really no problem.  You can do it.  But in my opinion, why do you want to have two HTTP servers?  No.  Okay.  Yeah.  Then give a big hand now for Oliver.  Thanks.
Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_0_5963.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_5964_6503.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_6504_17531.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_17532_33395.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_33396_33803.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_33804_33899.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_33900_33947.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_33948_34031.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_34032_34079.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_34080_34691.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_34692_34739.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_34740_34835.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_34836_35939.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_35940_36107.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_36108_36155.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_36156_36203.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_36204_36263.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_36264_36875.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_36876_36995.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_36996_37043.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_37044_37091.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_37092_38183.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_38184_38351.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_38352_39503.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_39504_39551.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_39552_39611.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_39612_40595.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_40596_40643.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_40644_40691.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_40692_40739.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_40740_40787.png Oliver_Braun_-_Python_and_Angular__a_perfect_match__dVmFKXm3b0c_40788_40896.png