 Hello, everyone. I'm very glad to be here. I'm very glad to be in Bilbao. This is my first Euro Python. And I want to talk about, I think, your stack and ReactJS development on the edge. But let me start with a small intro. I'm a Python and ReactJS developer. And my primary task on my works is designing and developing Becant API. So I'm like Becant API master. But let me show how I will get to that stage. Everything starts in 2002 when I first met Microsoft from Page. That was scary times. But that was then I started learning PHP, HTML4. It was like a standard stack for that time. It was a very, very long time ago. And then I started my own web design studio and make some sites for corporate sites, internet shops for Ukrainian companies. And then sometime in 2007, I decided that PHP is bad and started looking around on what else I should use. And there are two options, Ruby or Python. And I decided to start using Python and Django 095 or 096. So I started using Python. And my life getting better, better, better. I started my outsourcing career with Django. Then I switched to Odesco, professional services. So we made services for Google, Facebook, and other big companies. And then in 2011, I met Flask, the next big Wow Python project. So I primarily switched from Django to Flask. That was a good time. And I used Flask maybe for two, three years in a row. But then in my work, I need to go back to Django. And right now, I'm also working with Django as a framework. So from my point of view, I'm a Python developer for eight years. I'm using Django from ancient times. I'm using Flask from ancient times. But I'm not happy. I'm not happy with all these technologies. This is me when I need to figure out why my Django app working slow or why developers around my team use its dot notation for giving ID for foreign key. So it's like mess, mess, mess. And I'm looking around. So I made a decision. I wanted to switch to JavaScript. And you should be looks like what JavaScript? Come on. It's not an answer. And I agree with you because JavaScript was bad. It's like in first big JavaScript library was, I think, its prototype. And it's big and scary. And then jQuery band on stage. But it's also, first it was small. But then, oh, mess, mess, mess. And my motor was like, let's front end tasks make someone else. Because I really don't want to make front end tasks. Because when you start making JavaScript code in, I don't know, three, four years ago, you're like, why? Why I need to do this? Because Python is very clear, very simple language. If we compare it to JavaScript in that case. The biggest JavaScript problems for me, that was no standard models. You know, this script mess in templates. You're like, someone includes a script here, someone there, someone there, there, there, there. And you don't know where that or else library introduce it to your project. And it's very hard to maintain because you need to copy paste all your code across the projects, across the library, across the directory, so it's a mess. But then Node.js happens and it's good. It's good that it happens because Node.js brings NPM. And NPM starts installing dependencies. And when you have a system for installing dependencies, all code resolution starts being easy and easy. And people around JavaScript world start deciding how to share their code across different projects. So CommonJS happens. And then people decided that we don't need so much script inclusions in HTML pages. So Browserify happens. And then people understand that they need to link their code and then various linters happens. And then even some people decided that, OK, we could use Node.js for making backend applications. But, um, it's serious. OK. OK. How it's a very, very simple example on how it was earlier, yeah, it's like somewhere in template.html you need to include all this code. Yeah, you need to import underscore. Then you should use global underscore. And that was mess. But right now, in some iterations, JavaScript makes it to some better. Yeah, you have one bundle. One bundle for all your functions, everything you need. And in template, in HTML templates, all you need to call your functions. It's like in normal programming languages. So and the old code you see is start looking better, better, better. And right now I want to talk how it's possible, which changed in JavaScript world. And I want to welcome ECMAScript 2015. It's previously known as ES6. But right now, it's changed named for ES2015. So let's see what JavaScript has. First of all, it's modulus. Yeah, it's like normal modulus from Python. Yeah, OK, we can use import. We can use import for libraries, for functions. And as you see, in libraries, we can use export some functions. So we can use this like functional, like library. OK, JavaScript has models. It's a good start, but also better starts that JavaScript no more have var for defining variables. So right now, JavaScript have let and const. Constants for constants is obvious. So if you try to change your constant, you will get an error. And let works properly in blocks. So you don't have all the problems that you have with war outside, inside the blocks, because you can define one let only in one block. So it's fixed var for ES2015. Next, you don't need to use a function, a special word, to execute some very simple tasks. So if we have in episodes var some list of star wars episodes, we can filter them with arrow functions. So you don't need to write function, then eat them, and then return eat them. And arrow functions couldn't have the body and could have a body. Next, JavaScript ES2015 have normal classes. So this is a built-in feature. So we can use normal classes here. Classes can have inheritance. Classes have constructor method. Classes is like normal classes from other languages. So it's a good direction. JavaScript also very bad in the past that JavaScript doesn't have multi-line strings. Right now, they have. You see, it's multi-line string started from third line. It works, and multi-line strings have simple formatting. It's not that good like in Python because you need to define the variables to use in templates before the template, but it's something. Next, this feature, one of the best features I used in JavaScript is destructing something. Python also have first type of destruction here. We can destruct a list or a tuple by the variables, but JavaScript also have an object destruction. And when you start using object destruction in JavaScript, all you need is object destruction in Python because it's very powerful and very good thing. Next, JavaScript introduce new types for the standard library. It's map and set. It's very, very funny that in this 2015, and map and set only included in JavaScript when we have in Python as times ago, but slowpox everywhere. But right now, we have map and set in JavaScript. And more. It's not all features of, yes, 2015. There are more features, and I will post my slides so you can check all the features of ES 2015. They have also iterators, generators, and improved Unicode, and proxy symbols, promises, and more and more. And the most brightest part of all of this that JavaScript, ECMAScript, has changed how it uses the standard. So there are no big... Okay, in next year, there would be ES 2016, then ES 2017, and then. And new, new, new features would be shipped to standard language. So in ES 2016, maybe there would be comprehension class properties function being to assign functions like we have in Python 3.5. And then, so JavaScript not staying on the place, and corporations and companies around the world are willing to develop better JavaScript. So not bad, not bad. And maybe if you are asking how to use it, you need only one. You need to use Babel for all good things. So Babel supports your bundle management system, like Browserify or Webpack, and with Babel, there emerges one and only lint tool. So you have three tools for all you need. Babel for transpiling ES 2015 to old ES 5, and Browserify or Webpack to make bundles from all your code and ES lint to make sure that all your code is conform your coding style, guys. So everything is starting easier and easier in JS world, so there are more and more better projects start developing around JS world, and there is how I found ReactJS, because when I started learning about ES 2015, I checked that many, many people are looking on how to use these all cool features, and they decided to use these all cool features with ReactJS. What is ReactJS? ReactJS is a painless UI framework. It's only UI. It's only framework for making user interface, so it's no even handling like in Backbone, so it's no like some data binding like in Angular. It's like only framework for rendering your components to web page. And it uses virtual DOM as like standard browser DOM is very, very heavy. ReactJS introduces to the world virtual DOM concepts that are used right now by many other JavaScript frameworks, and that concept is willing you to use light-wise components and change it and do everything faster, faster, and faster. And the main feature of the ReactJS is one-way reactive data flow. It means that you can send all the components only one way from the top to the bottom. I see this in the slides. And ReactJS has a very strong community around, so there are a lot of already built-in components, so your start is very easy, because there are a lot of tutorials, a lot of docs, a lot of everything. So this is the most easy and most simplest ReactJS component you see is a simple class which you need to define render method. This React component will render hello Python to the React container element on the page. Okay, this is an example with the state. When the state changed, you see a state definition on the second line, and then using states after the render method, when state changed, render method would be re-relating. So you change the state, and component will re-render. So this is the main idea of React. When the state changed, everything re-renders. And you see, yeah, when we click on the button, state changed, and our body will be re-rendered. Next, using components, sorry for not fitting the screen, using components, React make possible to introduce some components and using them in HTML text. You see the line with if preview, and we're using the new, not HTML text, but new component which named markdown. So like fetching data, it's next, next. We use a new fetch API for fetching data, so we don't need jQuery or other libraries for fetching data from the server. So we're using fetch, and then promises to fetching data. And you see, when we have good data, we're setting it to the components, and when data is bad, we're setting it with false status. And then in render method, when component first will be mounted, it will have no status. So then we show loading to the user. Then due to status and data we show, or server error or empty data or valid data to the user. It's very easy to use and very easy to write. And then I will show you what means one-way data-binding. It's like, if we have on the page comments component and comment, we introduce comments, do some fetching data, and then mapping all comments to simple comment components. What it means, it means that comment component doesn't change the state, because comment components have properties, have props. When data changes in a higher component, it would be a render inner comment component. So in React terms, the comments is a higher-order component, and comment is dump component. What it means for us developers is that we need to develop only higher-order components on our project, and all reusable dump components should be shareable between our projects. So it's easy-fi to develop these phrases. And that's not all React features. In 0.4.14, React even splits base React layer and React DOM to different packages. It means that right now you can use React not only with DOM model. You can use React Native, which is used in iPhones, and React Canvas is which is used in Canvas text. So you don't need the document of object model to use the React. And React have a magnificent routing system, so you can develop single-page applications with ease. React have many, many, many reusable components, and React even have many, many, many technologies to fetch data from the server, like Flux or GraphQL. And when you start using React, you're like, wow, it's really cool. It's really cool because it's easy to develop, easy to maintain, easy to introduce your components to other people in your team. And here is the question. And what about backend side? What about Python side? I don't want to use anything in Node.js to make in backend. I don't want to use any Isomorphic or Universal or how it's spelled JavaScript for making backends. So what about Python? And here comes the most intriguing and most new Python, not Python library, but Python stack is I think your stack. I think we all know what means I think your stack. It's like the standard asynchronous input-output, even loop, coroutine and tasks. It's very easy. It's included in Python 3.4 and available in Python 3.3. And I hope that everyone knows what I think you're about, but I think you're a very low-level stack, so you need to introduce libraries for using databases for making web applications. And then how your HTTP makes sense because IOSTP is HTTP client server for I think here. It's very easy. I hope you understand what's going on here. It's IOSTP client and this is IOSTP server. So this is a simple hello world in IOSTP web. All you need to make your view function a coroutine and then returning a response. So everything is easy. And this IOPG is also very easy. All you need is coroutine and then create pool. It's like all our previous sync code but made with yield from. And I think you're ready and many, many, many tools. So when I start looking around the Python, I will look on the Django, Django REST framework, Flask, Flask REST less, Flask if, and many, many, many solutions. But all the solutions doesn't feel like better solutions for me because I want to step up. I want to use something new and here is where IOSTP and I think your stack is fit in my needs. And you see many libraries already developed for I think here. It's like connecting with MySQL, Mongo, CouchDB, Elastic Search and many, many other technologies. And even some web frameworks already available which built on top of IOSTP web, named Muffin Induction and Spanner. It's like Flask on IOSTP web. So if you're interested, you may see here. But I want to introduce IOSTP web to you and this is briefly an introduction with all features that have that framework. It's very easy to understand and very easy to use. And it uses also one way, not like in React, one way that the flow, one way that the binding flow, but also one way flow with request object passing to the view function. You also can enjoy this in your project. Okay, this is a very simple hello world. Yeah, this is how you made your applications. It's very similar to the Flasker. I think it's a very Flask way to making applications. And this is how you are serving your IOSTP applications. I recommend to use Gunicorn, but if Gunicorn not fits your needs, you can use, I think, your event loop or other solutions. And Gunicorn have magic reload flag, so you don't need some reload solutions which built into Django Dev Server or Flasker server. Or you have code reloads in Gunicorn too. Okay, and this is how IOSTP web handling getPostData. You see it's handling getData. You have getMultidict, like in Django, like in Flask, like everywhere. And then you have reading from the post data. So as you need to read this, so you need to yield from, not to block EO, to read data from the request. And then, okay, next hand, like you are adding new roads to your application, it's very, very similar to every other solution we have in Python world. Even we have variable roads. It's something like this. It's not very good architectural decision from my point of view, because if we compare this to Django or Flask, in Django and Flask we have project ID, like positional argument to the view function, but here we read it from matching for dict. It's not very good solution for me, but I think Andrey Svetlov is the author and maintainer of this library, and he will have a big class about using IOSTP web on Wednesday, so you can ask him why he decided to do this. And then, then, yeah, you can use name at roads, you can use everything roads, so you can use everything, yeah, you can as one of the greatest abilities of IOSTP web, that application is inherited from the dict, so you can just modify dict like in it. Here you just put settings to the app dict, so every app in your... When you get up, you have your settings, so you don't need to import your settings anymore. So, and next, that app is appended to your request object, so you see you don't need to do from import, Django for the info settings, so from something info settings, you can just use your application with settings in the view, directly in the view. And then how to customize IOSTP web, you should use middlewares, there are a lot of middlewares for user sessions for everything, and this is an example of material middleware and how to use it with your web application. And this is a real code for using the book toolbar middleware factory or session middleware, so you could have your toolbar or session middleware in your IOSTP web application, so it's very, very, very easy and very, very similar to other solutions in Python. And middleware is like handling exceptions, you need to catch an exception and then rendering an error view. So, user sessions once more, once again, so it's like using session, you first introduce middleware, then you reading from the session, not working IOS, and then right to the session. So, everything is clear and everything is easy to use. Even IOSTP web could be used for rendering templates. I'm not sure that we need to use IOSTP web for rendering templates because it's not that solution, but it could be used. So, first you need to set up Jinja2, the Jinja2 example, and then just render to play it. This decorator is obviously coroutine, so you don't need to decorate your view function with coroutine again. Or if you need to do some more, you could use a render template function. So, everything is easy and everything like everywhere. And here you can use, you can send static files, so it is easy file development, so everything is okay on your development server, so everything like everywhere in Python. And next is how you can use your static files in templates. Okay, and more, there are briefly introduction, so it's not every feature that IOSTP web has. It also has web sockets, except header, custom conditions for rows, like a class-based handler, so you can use not view functions, but class-based solutions for handling, for handling the routing. And I say it again, IOSTP web has web sockets built in, so you don't need to look around on how to implement web sockets in my web application. So, just use IOSTP web and you have your web sockets server and client. So, mi me gusta. And real-world usage. I use IOSTP web for back-end API. It's obvious for project, which named Money Tracker, and that project is looking for my task around different issue trackers like JIRA, like Pivotal, like other, and it may possible to track time, which I spent for fixing some issues. And this is a simple structure of my project. You see it's nothing new. I have application Pi. When I have my application, I have use-Pi when I have my some, some my global views. I have layer storage-Pi layer for working with database and have API and IOS, I don't know, sub-ups for API. It's for providing me API and also providing authentication for that project. And there are several additional, several additional functions I use in my projects. It's like adding rows for the application, simplifying adding rows for the application. It's in the table settings. We use mapping type proxy from Python 3.3, so our settings are in the table. We can use debug mode in the application. So, right now, iOS is very raw. It's only on the beginning, so it's many, many features not introduced or not developed, but there are many that we need to develop. But I think in several next months, the ecosystem around the IOS TPP app would be, would be larger, larger, larger. So we could use it like, like we use Flask Django without any pain. And then the most interesting thing that I discovered when I using IOS TPP for my API back end is that I should use JSON schema for scamming my data. Like, I could use this same schema for validating data on back end and on front end. And here, with a little help of my project, which is called ROWROW, I'm using a schema for adding the project. You see, we have this kind of schema that the project can have name, slack, and description, and the project would respond with its ID. And then how to use it. We should validate requests on the server, and then we should validate response on the client with one similar schema. It's very, very good, but also very ROWROW solution for validating for you, for ensuring that we have proper data in the IOS TPP web application and in React.js application. And then there is a question. Why might need I think your stack? So there are a lot of already developed solutions in Django, in Flask, so why you need to switch on? Come on, because it's cool and trendy. Just switch on, because you just need to check it out, to check where Python world is heading. But honestly, you need it when your database API is... when you begin the API is the database. When you have a lot of requests to the external APIs, so you could use all the power of our sync here, all the power of asynchronous input-output. When you need your code to be executed in a sync style, and that code that needs to be executed in predictable styles, so you don't need any magic which provides seventh-let, or javent, or other solutions. In that cases, you should consider to use I think your stack on the backend. And the summary. I think the future is here. I suggest to use Python 3.4 for all good things, because if you're still using Python 2.0 like me on the work, it's so-so. Python 3.4 is stable. It's a very good version of the Python. You should use it in... in the work, for your pet projects or something, because IOS GP Web is easy to start, easy to use, so you could have a proper I think your Web... Web framework. IOPG have C-scale alchemy, so you should forget about the OREM. You don't need to object relationship management. You should just use IOPG skill alchemy. And if you miss something, just support it to your stack. It's not that easy. It's not that hard, so just don't forget to pay back to open source software. And from other parts of my slides, JavaScript also makes a very great step in the right direction. Many tools around JavaScript is maturing, so right now you should... you could use... you could write your... use the interface code without the pain. Building a bundling is easy. Webpack. LinkedIn is easy. ASLint. Making UI is easy. React. So it's how I see the evolution of making user interfaces around the Python. We should start using more, I think, your stack on the backend and using proper tools like React on the front-end. And this... this relation makes happen... this relation makes able to build very simple, very easy web applications. And this is true story. Okay, so this... I'll answer the questions. Thank you, Igor. We, unfortunately, are out of time for questions, but if you have something to ask, don't hesitate to reach out to Igor in the hallways and ask him. The next session here, we're starting in five minutes. It's... And I have small bonus. It's how it looks in Python 3.5.