 Good afternoon ladies and gentlemen. Hello everybody, thanks for attending this talk. I am going to speak about Python and Angular 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, we will, 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 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 wouldn't, if you want to do it the same way we did it. And in the 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's not native and so on, but I think and at least on Android it should be possible because it's a kind of a Linux system. So why is this so? This is, yeah, this is, 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 they're 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's 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, yeah. This is what we expect, we would expect from modern GUI framework. So it's 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 set up. And in the model that's the business logic of course. Now let's kind of wind up. Have you ever heard of Kiwi? So Kiwi 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 standardised 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 roll out project very well designed it's hard to do it in Kiwi. And of course this is one of the main legs. It's not common up to know. So there's no specialist on the market available. 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 it's 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 notice 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 WebSockets. The calls which we are doing from one side to another are asynchronous in the sense. There is no direct return value. I mean asynchronous we have heard a lot on this conference. It's all about Async.io. And if you really want to do something asynchronous 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 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. With some limitation it works also for a web client. If you have services ready in your network. This is simply because WebSockets 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. One has to put more work on it to make it secure but I think there is 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 is some HTML framework works as a front end and your Python web server acts as a back end. E.g. Flask with REST API whatsoever. The problem here is especially for our case use case. There is no need for HTTP server. So why put something up which is totally oversized. No need. On the other hand 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 is 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 more or less 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 have heard some opinions about this. This is awful. But 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 Type script. 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 a typical action flow in our GUI, back end 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 back end. The back end 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 back end can act on also totally by itself. It can send messages and events to the front end. How do we do this? With a web socket connection. So this is not really new but it works here. We are redirecting events from a web socket to a Python function. We set the web socket server on 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 then arguments. 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 function 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. So 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 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... 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 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, nothing special. We have just some imports of the local server of this junction 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, 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 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 backend side, exporting the functionalities that you want to expose in the backend side via the REST API and to issue some Ajax calls from the front-end to the backend 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 the 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. 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, 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? Then 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. 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 want to 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.