 Hello, everyone. We're going to talk about, as the title said, Django, Django REST framework, and something else that is more Java or Java-esque. There's a catch because the title you have on the plan is not exactly the one that will be following, because you'll find out. I don't want to spoil everything. There's enough of that about Game of Thrones already. So let's start with a fast, who am I? I'm a software developer. I'm a Python developer. I love TACIP. I love Django REST framework. I'm more GIS developer, and I work with a team in Bologna with who does basically full stack in many different stacks, even the ones with the wrong P. I think this is very important because it's one of the elements that brings me here today. And it's the interaction with the customer and the designers and the end product that we are required to develop. In fact, being for developers and one designer means that the designer is the one that interacts with the customer usually and the interacts with the client that wants that specific shade of red or that specific form for that specific element on the platform, on the front end, on the front page, on the mobile application. And it's important because as coders we want to write new stuff, we hate the routine, and as coders we would love to have the designers changing their graphical stuff and be happy with that and have the clients and the customers be happy with that without us being bothered to change the CSS because that's not our work, honestly. And it's not being so shamanistic. We hate that, honestly. And usually what we find ourselves doing is this. And it's good because we usually find ourselves writing a Django application and we can put the templates into the Django application and we're kind of happy with that and it's good. But the real issue with that is that we are unable to really use this flexibility that Django offers us. So with the issue we had as a Spanish poet says, a wise man's question contains half the answer. What does the issue we want to say we've seen before? We don't want to repeat ourselves. We don't want to do the same work all over again every time. How does that impact the the world we want to define and we want to express? Well, we don't want to explain the APIs we write. I mean, the customer already has exactly understood what we are going to describe of this world. We know we would love these APIs to be self-documenting. And what is more self-documenting than a beautiful piece of code? Except it is not and we know that very well, but it's difficult to make that understand and it's difficult to really have it explained to a designer and to a software and to the end customer of the application. So what we found out as a team is that we need simple standard rules. Standard rules means standard APIs. That's the basis of restfulness. And that's good because standard APIs means standard libraries. And standard libraries mean more time and more possibilities to create the famous tool for our designer to basically design and draw his own interfaces without our help. And that is an enormous win because that creates a lot of time to be used for this. And it's all a matter of how we want to describe the world. In a talk in the previous session about the status of rest frameworks, I think one of the aspects that was not really dealt with is the meta-level description that these tools, that these libraries that Python has can offer. In fact, with considering that we're using Django, we could use many different ways to design our API or describe the world we want to define as APIs. In fact, there are endless ways. We could use Django class-based views and personalize them to do the hard work of responding to our options, call to our get posts, and all the interactions that we consider useful. We could describe a swagger file and sadly, it's not that easy to do that in an automated manner with Django and with, for example, a Django rest framework. So what could we, so we would need to describe our API in a completely different JSON file and then expose that JSON file through some way that has to be kept aligned with the real code of our application? We could use Wizzle 2. Good. We could use Rammel. We could use any kind of standard, and we could any kind of standard based on a markup language, any kind of standard based on JSON variant. We could use UML with our, with graphs and designs and any kind of descriptive element, or we could use any kind of transformation. And as always, this is the rule. Once we have 15 standards and somebody thinks up a way to standardize them all in a universal standard, we end up with one more standard to mess with. Do we really want that? Honestly, no. Because it's already a mess and we don't want entropy to kill us all sooner than needed. There's Donald Trump for that. So considering that we're starting with the Django framework as the basis for our, for our platform, the options that remain are basically two, and it's Django class-based views or Django REST framework. Let's go back to the basics. So what are the two ways that we could use to to work with? We could use, again, class-based views are very loose. We can really define many kinds of interactions with them, and they're cool, but it means defining an adapter for from Django to the outside world that shows us the meta information that our model represents. On the other hand, we have Django REST framework, which is quite strict because it implements a real, very precise RESTful model. And it is very descriptive on what kind of action we can do with the elements, but it lacks on the description of data structures, at least based on Python 2. The code-hinting features of Python 3 have not been yet very explored by the framework, and we're trying to work on that on the through the description of the metadata. One more thing that Django REST framework offers is the options method. It's an amazing tool. How many of you use it to work on Django REST framework? How many of you use Django REST framework? That's okay. Okay, I'm not in the wrong room. It's not obvious. How many of you use the options, the metadata element of Django REST framework? It's possibly the most amazing element that can be used, because it really describes you. I happen to have been working on a form generator based on just that, and it's amazing how much we can achieve with that. And maybe sometimes it's a little bit under descriptive, but with just a few adjustments, it becomes an incredible it tells you really the story of the back end and how it works, how it interacts with stuff, and how it represents things. Whoa, what happened? Where have you gone? Okay. As said, it's an amazing tool. So what we have now, we have chosen Django REST framework. So we suddenly have a back end based on Django and Django REST framework that keeps us on the database. We have all the features of Django, all the expressions of the REST framework given by Django REST framework. We have the API exposed through Django REST framework, and we have the metadata exposed to the options element. So cool, but we have added two layers on our app, and that's not cool. It's not maintainable. It's a mess, because we have the model, we have the serializer, we have the view sets, and sometimes we don't have just one serializer for one model, that would be a perfect world, and sometimes we have two, three, four serializer for one specific model, because we have one for creation, one for details, one for listings, one for other specific views, or nested views, or whatever. So it becomes, it risks, the risk is making it becoming really messy. Unless we have, we get something cool from that. Unless we can find a nice tool or library that helps us doing cool things on the front end. And here comes the famous catch. Because Angular 2 could be a nice tool, and Angular 4 considering it changes number every six months. Angular, whatever the number, the highest bidder wins. It could be a nice tool, but it has an amazing side effect. It's a really cool element and has a really amazing ability to describe and to enable really the structuring of metal level descriptions of the world. It does not work well with automated designers, drag and drop designers. We have a library where we have developed a library to enable us to really ease the work with Angular, and it's a nice library. It helps a lot. It shortens development time a lot, but it doesn't help us help our designer. So what's the alternative? The alternative is to go for something pure JavaScript-driven. How many of you have happened to know Grape's JS? Good. Grape's JS is an amazing tool. It's extensible, flexible, and really a beautiful drag and drop web page designer. It was built for newsletter designing in a very word-pressy fashion, in order to help designers recreate their newsletter in a fashion, in a simple way to keep all the elements under control. But it's a really amazing tool as a platform, because it's easy to use for the designer, fun to work with. The only side effect is that it's pure JavaScript, and there is no way to integrate JavaScript into the Grape's JS element. So that means that we have to create something magic-ish to connect the worlds. What if we could take the DRF metadata and generate Grape's JS components from the standardized metadata? What do we mean by that? Suppose you have the elements, suppose we have the elements we can work with, described as exactly as the Django REST framework does. We have all the methods we know of, we know that we can have the get on the list, we know that we can have the get on the detail, the post, the put, and the options, and the delete. And as such, we can easily define how these elements have to be connected to each other. And from that, we can easily generate new components for the Grape's JS platform. As such, it becomes quite easy to define a simple way for the designer to take our metadata, describing the API we have, transporting it to everything into Grape's JS, looking at the sidebar where the components live, dropping them into the interface, and saving the resulting elements as pure HTML, JavaScript, and CSS. Basically, a zip file can be generated directly from Grape's JS. It's not easily versionable, I know, and I totally agree, but it requires just to learn a bit of git, and the designer can do that. And his code is perfectly versioned, and it can be tracked. And the result in this is that the developers can live in their own space, defining their own data structures and their own data models, these data models are then made visible through the metadata to the designer, who doesn't need to read documents or analyze papers and results of discussions. He just looks at the code and starts designing their interface. Just looks at the components and starts designing their details, and starts defining what color the specific element has, what pattern it has to take from whatever other source, and from whatever decision the customer makes on what kind of elements he wants to see. It's not a pure Angular way, but it goes very far as a data structure. So what are the contributions? What are the elements we have published and we will publish in the next few days? Because these are the elements that we're really trying to publish and transform into, let's say, betterments for the community. And the Django REST framework metadata transformer, a tool that enables us to transform the Django REST framework metadata into a JavaScript that can be used on Graves.js. In fact, on different situations, one of them is Graves.js. On the other hand, we have the Graves.js data attribute animator, which is not strictly bound to Graves.js, but it basically helps us to transform the data from the data attributes in Graves.js from VAR concepts saying that this data set should go and take data from that specific backend and use this or that login data, login information to get the information from the backend and should expose that through this or that template and should wrap all these information into one simple action that goes directly to the backend, pulls the data, shows them on the front end and solves everything with a simple, as a simple task, with a simple repetitive task. On the other hand, as said, we're trying to standardize the work on Angular 2 as well, Angular whatever as well. We didn't discuss this, but it was the main reason for this talk, in fact, because we were hoping a certain amount of changes in the Angular 2 infrastructure would happen by now. It didn't happen. But it's an amazing framework anyway, and all the work we have done is right now will be published in the next few days as model notes, backend management service, which is a generic backend management platform for Angular 2 services, enabling interaction with any kind of flavored backends or specific backends if you write your own flavor. All in all, this is the result of the work. Finally, we can stay in our corner and hide behind our screens and be happy that we don't have to interact with customers, except for the beginning, where we have to easily discuss this, but we're discussing the possibility to have the designer doing also the data modeling, if possible. And the designer talks to the customer and is happy and Rich Ricardo keeps interacting with his friends, the customers, and we are all, and everybody is happy, basically. That was our main goal, and we think that with this structure, we're able to go for that. I think we don't have the time for a full demo, so I'll say with the next, ah, okay, well, anyway, I would say it's better to maybe ask, get some questions and have some answers. Give you some answers. Anyway, these are the mediums, Twitter, GitHub, for me and the team. Thanks. Thank you for the back. Oh, questions. Thank you for the talk. So what happens when the thing you're doing on the back end goes away from the standard model view sets and standard generic APS? Because this is, for me, this is for getting people hyped about the REST framework. Model view sets are great, but not really useful in real projects because there are requirements that move you away from there. So what happens then? You have just an API view. There are two aspects on that answer. The first one is that if there is an aspect that moves away from the classic model view set, then we try to understand why it moves away from the model view set. And at least in the last two, three projects that we worked on, it was just a matter of describing the world. For example, if you put a like on, if you like something, then it's, I like this post and it's put as a verb. On the other hand, if you think of it as a physical action, you want to have an interaction with your database and you want to put something on the database, you need to track something, then you need to physically represent it as something different. Then it's more a matter of defining the interactions, the actions on the data as real physical things that become at a certain point models. There are, I agree, some aspects that cannot be redirected to this. For example, if you suppose you have different kinds of visualizations, of the same element where we have, we might have different detail representation of the same model. In that case, it's part of the extended metadata that we've been working on extending the metadata generator to expose these kinds of information as well, because it's the only way to go into that direction. Again, personally, I think, I feel that more comfortable keeping the rest structure rigid and strict, because it keeps the, I mean, standardizing helps not getting the call from the designer. Let's speak cynically. We don't want to be called by the designer. How do I get to that information? We would love the designer to be able to do that by himself and say, okay, this is a data structure that I need. Where do I get that? Let's see the metadata. Or maybe let's see from the components if there is a component that gives me that information. If that's missing, then that's a good thing. That's the kind of work we love, because that means that we need to explore a new way to expose the information. So, hi, and thanks for that great talk. I've been working with Vue.js, which is basically the best bits from Angular and React. If I understood correctly, the Grape.js looks pretty nice. How far is it the breach thing, or is it, is there a way, or is it like something like, if you will, ORM for JavaScript, for example, for Django to get a JavaScript and kind of a thing, just like a library thing for JavaScript, and that would work like a ORM in the back end. Are we like, is this moving forward, or is this implementing this kind of a thing? Your question is if there is something like an ORM for the JavaScript part. Yeah, like the Grape.js is obviously one step higher, but if, is the medium bit you talked about, is it something like a ORM for the JavaScript, or is there a project like that? Grape.js is just a front-end designer, and that's exactly the limit of the project. We've been experimenting with Realm, for both, for basically a lot of things, and any platform right now, because they enabled Realm on web development, on web pages as well. So there is this possibility, and it's quite interesting, because it's a very interesting world to explore. Right now, it's quite difficult to integrate the various parts, because it's JavaScript, and it's, as the people from Typescript said, hey, stable is the new alpha. And so you don't get really to a standpoint where you say, okay, this is stable stuff, let's put that together and see what happens. There is this beautiful lake where every ship is slightly moving, and you don't exactly know in which direction, and we're working on trying to have these elements interacting. As I said, the most interesting project in that direction at the moment is possibly Realm, to work with an ORM. But there are also smaller projects that try to just rely on SQLite on the browser side to have almost a deep connection with the database. Any way can be interesting and any way can be explored. Again, the most advanced project on that is Realm. Thank you once again for the great talk, and remember to write the talks on the app. Thank you, Marco. Thank you very much. Thank you.