 Hello. I am Alberto. I am the co-founder of a small company that offers development and system integration services. And today I will present you a framework and an application that we built to bring back fun into the development of web applications. So what I mean with web application, usually web application today means many things, but for the purpose of this talk I mean those applications that are usually developed today to replace desktop application that used to access relational databases and show data to the user, let the user filters, query, sort. They usually show many data at once. They usually offer advanced filtering, sorting capabilities and so on. And usually those applications are used for data entry and so they show very complex forms and they show master tables and so on. I think that such applications have a narrower user base than public web page publishing and so on. Usually those applications are called single page applications. Many times they are installed on premise or they are installed on cloud and then used inside an internet or so on. So the framework we developed its goal is to serve these kind of applications. It's not to serve 10,000 web pages to anonymous users. Usually the user of our application is always unknown users, so the first thing he does is to enter his credentials and login to the system. So today how it's built an application using Python tools. Usually we start with developing the database structure and so on and then we pick our favorite server framework like Django, Pyramid, Turbogears, Flask and so on. Maybe we develop an object relational mapper on top of our database, but it's not always needed. And usually we expose those data using rest services or get and post entry points and so on. But then because they are web apps, then we choose, we pick a JavaScript framework and we develop all the application level logic with JavaScript. So all the user interaction, all the flow of the user inside the application and so on is coded in JavaScript. How many of you do that, for example? Is it fun? Is it still fun? So I don't think that it's so fun. And yes, dealing with JavaScript is inevitable because there is nothing else on the browser, but it's stressful because it has many consequences, many things that you maybe learn one time and then you forget. There is something you know about its base types, not a number and so on. And every time you approach the development of a JavaScript web application, usually the scenario of available toolkits is changed because it changes with a very fast piece. And usually the JavaScript community reinvents the wheel every time in a fancier, more quick way and so on. But for us that we want to code in Python, it seems not so good to always learn a new JavaScript framework, maybe the version 2 of the JavaScript that we learned some months ago that changed the language from JavaScript to TypeScript and so on. And many times the libraries of JavaScript libraries compared to those available in Python and to the standard library do have very poor quality. You end up installing tens of megabytes, hundreds of megabytes of JavaScript code just to let your toolkit work and so sometimes you don't understand why you have to install all those things. So many of you can say that ES6 is better because it classes, promises, iterator, generators, many, some of these features come from Python and also it has map and set that are implemented natively. For the first time you can put not just strings into dictionary keys but you can use any kind of object as key and this is surely an advantage. But then, for example, when I learned about a weak map on weak set, I thought that they were comparable to those available into the Python standard library and so I said fantastic, very, very, they were what I was waiting for because then I can keep weak links to objects without worrying to free those links and so it's a very nice feature but then you learn, I discovered that for example weak maps, you cannot know what's inside a weak map. If you know what's inside a weak map is because you have put it there so it's not possible to ask a weak map for its keys. It's not possible to iterate over its keys or its values and so on. It's just possible to check given an object to check if it's a key in that object and it seems incredibly wrong to me but the JavaScript community found that feature instead. So, one of the more prominent JavaScript developers said that it is a security feature, something that you can, that it's really useful because you can have an object that no one can look into. But I think that it is a misunderstanding of what a weak map should do. It should firstly give you a way to use weak links, weak references to other objects and then maybe a being used as security property or security object because you cannot look into it. So, JavaScript, even in JavaScript, is as many things that seems wrong from a Python side. If you read blogs and articles around the internet, some suggest that you should use, for example, TypeScript, which is a very, very good language that has interfaces, types. But, for example, a few days ago I found this example in a Reddit blog actually when they were explaining why they chose TypeScript. And you see that code where a foo is declared as an array that can contain just birds and the next row they add an animal, which is the super class of birds. And the TypeScript interpreter and checker is okay with that. So, while having types may help maintaining the code and so on, the language that has type in its name fails to check a very simple block of code. So, again, I would say what, it seemed very, very strange to me and that's because I know that we have to deal with JavaScript, TypeScript, coffee script, what you want script. But, I will put it in a cage and control it from very, I will like to at least. So, it's enough about talking about JavaScript, so let's get back to Python. And what's the role of Python in modern web applications? Usually, when you have such separation between application logic and data access logic, one, the first developed in JavaScript and the second developed in Python. The Python server that you develop in one of such application servers that I told you before is used like a data hub. And you expose your data in some way and really for me and for us, the fun part of developing application stops when we develop our database structure, we confront with the customer about the domain data and so on. And really, what comes after the database structure, the exposing, the create a rest API, create a get post API, it's boring. We do really need that. So, when do we really need the rest APIs and so on? We think that we need the rest APIs just when your service, as to your application, as to interface with other services by using standardized interfaces, such a rest and so on. Or if you give an API to your user to use and to interact with, for interaction with your application, instead of using the GUI. This is the normal way of how Django, Pyramid, Flask, you name it, do they work more or less. More or less, they all wait for a request and then they will, the request contains all the data, the context data that your application, your controller, your handler needs to understand what it should do. And then it retrieves the data from the database. It builds up a response and stream it back to the client. Maybe it saves some data in a session that usually is used like a poor man dictionary. And then your objects are destroyed and your system is waiting for the next query, next get, post, patch, and so on. How, where the things, oh, are the things, because we, there are still, those toolkits are still used today to do desktop application. Oh, where are things with, always developing an application with desktop toolkits. Those that were, that are now supplemented by web application and so on. Usually developing application with PyQT and PyGTK, the role of the GTK or QT toolkit and Python is, their interaction is much more tighter than with web apps. In web apps we have the application logic completely moved to the client, but instead in normal desktop application we have the application logic is completely driven by Python with the app of classes. And UI widgets that the toolkit provide us. So they are very different from today web application. So we found ourselves at the end of last year in the need of decide if we were maintaining an old application developed with one of those frameworks. It was much, much older indeed, it was developed in Zope. In Zope or we have made the decision instead of replacing it with a new app and we wanted to bring back the fun into web development. So we developed a framework from scratch and the idea was to use an asynchronous system not just to achieve better concurrency but also to ease the maintenance on the server of the state of the application. We thought to have two equal system on the server and the client and to have them freely talk to each other using modern RPC systems that can use HTTP as backend protocol. But that they obstruct you from the notion of having an HTTP and even they work without HTTP at all. So we developed these framework Raccoon with Postgres at the bottom level. All the framework has to be asynchronous so we chose async.pg to drive to the data access to the database and SQL alchemy to construct the queries. Crossbar has been chosen to as the intercommunication backbone between the two pieces on the client and the server. And AEO HTTP is used as an HTTP publisher for the stuff that cannot be transferred for the initialization part and so on. And then we used SQL alchemy but not DRM because the object relational mapper cannot be used with async code. And the RPC, we chose crossbar because it allows your system to interface not just between Python and JavaScript but between many, many different languages. And as both a twisted and async client library and as such nice features like error transfer between the caller and the colleague. If the colleague raises an error, this error is brought back to the caller and so on. It's really nice and has many features. So we designed an API that our API has composed by a tree of nodes object where the initialization is split in two parts because the under init cannot be an asynchronous method. So we have to split the initialization in two parts and node is a mixing class that just deal with the communication part of the problem. The rest of the object is supposed to do, it's your application logic and so on. What the node class gives you is a way to declare callable things and signals and handlers at the class level with the decorators and so on. And it does that in a way that it's possible to construct your object trees with relative references to each other and then attach them to the crossbar connection machinery and have them published on the, have them published. Here you see some nodes and the methods and the signals. Signals are events that the nodes allows you to declare to use. So this is, let's jump to an example of a test and you see that at the line 12 we have the first node, which is just a node that's used for structure. And then we have two other nodes, the second and the third where we customized our, and we added some handlers, some signals, an handler, a signal, a call and so on. The node is automatically instrumented to expose those methods. And you see that, for example, the line code third, a line 17 that calls the third node with a relative path. It depends on where those nodes are mounted into, are bound to. There is a base path, this is test, and then first is bound to base plus first that will become test dot first. And then third is bound to base dot third. And then the first node adds the second as with the name second. And so its node path will become test dot first dot second. So you saw before that the handler on line 25 listened for the signal on first second. And all these are relative addresses that when they are realized when the node is connected to the machinery, which is in line 37 and 38 and so on. And this is a variable also in JavaScript. This is actual JavaScript code and it is in JavaScript code because we use a tool we made to compile Python to JavaScript. And yes, it compiles, we use the same syntax, the same abstraction. And then we compile them to a JavaScript that also a very old browser can run and that has no asynchronous, no promises and so on. This is actually anatomy of our session of our application user session, how it starts. There is a service that is the only thing that is both HTTP and crossbar and connects to crossbar. And then each other side can talk to each other very freely. I have many more slides but I am out of time. So if you are interested, we have developed, the application is nearly complete. I cannot show you it now. But if you are interested, we will, I can show you, we can give you an access and demo us to the application. We will probably publish this framework when it's ready, it's in good shape. We need to completely separate it from the application, but it's going very well. It has more 4,400 commits. If you want or see the code, just ask me or drop me a line. Thank you. Thanks Albert for your presentation. Questions for Albert? No? Thanks again. Thanks Albert.