 Dzień dobry wszystkim. Nazywam się Serafą Nowicki i teraz pracuję na STX Next. Tutaj jestem... Bo to jest software house. Teraz pracuję dla klientów, który jest jedynym z największych marketing agency i tutaj zrobimy platformy assets management dla nich, sporo na mikroserwisach. Więc to jest agenda. Zacznę z krótkiej instytucji. Zobaczmy, że najważniejsza część prezentacji jest o trzy frejmury. Następnie... Zobaczmy, że następnie trzy frejmury każdego frejmury będzie prezentować te feature, ten krótki egzemplarz i ten rezydent. Zacznę z sumami i pytania i wypowiedzi. W każdym razie, kiedy znałem mikroserwis i znalazłem nowe produkty, zawsze widzę te same wypowiedzi. Który jest najlepszy dla naszych potrzeb? Będzie najlepszy dla produktów? I wypowiedzi często same, które używaliśmy ostatnio. Więc najlepsze solucje są, które już wiemy, które są już znalazłe. I jeżeli potrzebujące biznes i potrzebujące biznes tak szybko, to znalazłem i wracamy do solucji, które już wiemy. I chciałbym zrozumieć frejmu, które sprawdziłem, aby zrobić coś innego. Więc może możesz odpowiedzieć za tę kolejną kwestię, która jest najlepsza frejmu, i zacznę z frejmu Django DRF jest jednym z pierwszym, który znalazłem. Frejmu jest zazwyczajem dla Django. To jest świetna integracja z Django. Dokumentacja jest też naprawdę kompleksalna. Więc też zmienia się z kompleksalną dokumentacją. I to jest... co znacznie? I inny poszuki jest rozwój API. Więc DRF pozwala ci sprawdzić twojej śwary, więc nie postman, or any other tool to check the request. This is the simple view set. So in DRF you could provide, create the endpoints by two ways. One of them is using API views and another one is to use the view sets. And the view set is like managing the API views. So here, this is an example of user view set. We have two methods, which simply say what has been returned on list methods. It will be the result of the list endpoint. And what's returned in retrieve will be returned in this case user details. So you simply return the response and put the data that you want to have, that you want to your client read. And in this case is the iteration through the user. So in list view you get the user names list. And in retrieve you get the username, email and full name keys of the values for a particular user. Method mapping for view sets. You already know the list and retrieve. There is also create for post request. So list is for get request on collection. Retrieve is a get request on item. Update and partial update is put and patch mapping. And this throw is just the delete. By default you get here the pk. But you can simply change it through the attribute in your view set. So this is the model based view set. This is why I'm using the DRF for one of the projects. If you have the project where there is a lot of models that you want to overlap with the crew, then by simple declaring the second class, the first class is serializer, second class is just a whole unit to wrap the model to your API. By default you get full crude. Create, read, update and delete. And how to set up the URLs. When you're using the view sets you can use the routers. And this is like your register new view set. But you can also do this with the known from Django way. Because the view set is also the view class, so you can use the sView and put the URL that you really need. And this is a more detailed example. So we have two nodes. One for user, one for groups. And by registering the user and group routers, you will get the pattern like users. I this is based from the first regular expression from the first argument. Or in case when you need detailed action, you get the pk by default, but if you change it you can get whatever you want. And here you also have the name, so you can use it all around your Django app, or even in the other APIs. So if you already use Django and you need crude, as I mentioned, for models, the DRF will do for it, and it's the obvious choice. Another one, Flask RESTful. So this is the library created for Flask, surprise. Compared to Django REST framework, it contains the minimum. Actually, the RM is not included as on Flask. You can decide what to use. It's great for building lightweight APIs and better way to organize your resources. To be honest, this is the biggest value for using it. So I will go through a few examples, but actually it's one example, so you can treat those like one page. So start from the top. To don't just keep track on the users, which is currently the variable in this file. So we have the user's dictionary structure and I will save the users by the key identifier and the details in value. What is really nice and well-known, Flask RESTful use the request parser. It works really similar to arc parser. So here you can set the arguments that will be used. And you can say what type of it is or is it required or not. So let's go to the resources. And here we have the methods called get and post. So this will be the list, the collection resource. And here in get request, we will return the list of the users, which is only the attributes from the previous flight. And on post, we will get the username and save it to the already existing dictionary. Here you can see that the serialization is behind. So you don't need to remember about the serialization on your site. So the dict will be just converted to the JSON. This is the user resource. So this is for an item. And here you also have known get, delete and put. It's more clear than viewsets for the RF. But anyway, here you have forget, you rise, actually use the abort. This is the method from Flask RESTful, which throws 404 and the particular message. Then on delete, we remove the user by the key from the dict. For put, we find, we just override the value for this one. And this is the place where we do all the setup. So the first and last line is Flask. This is all you need is just create new API instance on this Flask app and add the resources. You have full control of namespace on it. So no one will do that for you. And so far, if you have Flask, it makes sense to replace your API written in Flask to Flask RESTful to have things organized. But if it's still not what really needs, let's go to the next one. Flakeon. Flakeon is working on CPython. Actually, it was on Python, but the author recommends to use it on it because of the performance. So the Flakeon is a minimalistic web framework and it's reliable and high performance. So there are a bunch of benchmarks on the Flakeon page. So the author really did great work with optimizing this one. So the reason for this is just focus on one single case, this HTTP APIs. We'll go quite similar example. Then we go through the RESTful APIs. Flask RESTful. So starting from the top, we have the same user structure. And let's go to the users. You can see that I only imported the Flakeon and JSON libraries. So the name convention for the methods, it's quite similar, but you need to add on prefix. So on get, you set the body. This is quite different than in Flask RESTful. This is because you get as a rescue and REST the reference to the objects. So we don't return anything instead of none. So it's enough to just set the body attribute with the values. And here there is no serialization. So you need to do JSON dump on this. And on post methods, this code make more complicated, but it may look more complicated, but it still do the same. So we extract the body from the stream, then serialize the body, and then do the same. Get, actually pop the user name and show the proper message if the user exists and set up the value if it doesn't. So here you can see that there is the return. This is because the way of assigning that attributes the request and the responses. So if I would forget about this, then if the user won't exist, the code will try set the user anyway. This is the user resource and here we have quite similar situation. So when the user doesn't exist, so you get the 404 and the message on delete, we remove the user from the dict and on put we update the user. And this is the same code is actually repeating here. So the point of serialization, so every time you need to read from a stream, loads it, the JSON, and then do what you want. So here you get a few additional steps. This is the way of setting up the URLs. Here you also have the full control of namespace. So the best practice is to keep it in one place or just share the way of share your pattern with your ecologist. So this is great if everything that you do is the API and you really focus on the performance. So there are a few more libraries that I've tried and I guess I don't have enough time to go through to every of this. That's why it's together. So this is the so-called framework for human beings. So the general idea is to easily build and deploy customizable APIs. A lot of things are set up in just JSON structure, or just the DIG structure in Python. This have the native support for MongoDB, but as extensions it can be used for SQL, Elasticsearch, and other backends. Another one that takes the pie. This is a few years ago. I used it for one of the Django projects and it worked very well. Unfortunately, it's not developed anymore. So the version freeze on 0.13. It do simply things like the DRF. I mean it really did a lot for you, but you had serializer and view in one class. And AP Star, this is not a framework for building customizable application. It's just a framework for building any APIs, but I think it's worth mentioning and maybe you would be interested in more details on it. So the outer is the same for the DRF and AP Star is framework designed for Python 3 Lite and in general helps building the APIs. So if you want to follow the restful pattern then you need to take care of it on your own. And summary. So the number of restful framework is still limited. And this is a good thing and also the bad thing. So the bad because we may expect any other libraries or frameworks that we could use, but from the other hand we have great combine which is Django Reds framework for Django apps and there is currently no competition for this. The Flacon is still best choice for microservices. I didn't find any other focused on the performance. And things worth mentioning is that libraries just support you with writing restful APIs, but big frameworks create APIs for you. And this is the difference between the frameworks and libraries. And currently I can say that the framework is only the DRF from those list. So thank you. So if you have any questions or just you want to share the libraries that you know and I missed, feel free. If you have a question please raise your hand. We have time for a couple of them. Thank you for your talk. Just a quick question. I was wondering why you haven't considered Pyramid or Pyramid framework in your presentation. Maybe there is a good reason for it, but it was just... As far as I know the Pyramid, I think that there is... So it's more the web framework rather than the framework or the library focused on building the restful APIs. So that's why I skip it. But yeah, so does it satisfy you? There is one more great framework. It's called Flask Rest Plus. It's written on top of Flask Restful. The most tasty feature of it is model specification and swagger documentation generation. Janga Rest Framework has Janga Rest Swagger, but it doesn't handle model generation in swagger specification. Flask Rest Plus does it. And I consider using it in real project. And it's really great. Okay, thanks. So one more framework that we use that is not that restful one, but we use a lot of cherry pie because it's, I think, the most lightweight web framework that's available. And it works pretty fine with the rest APIs. But that was what I wanted to mention. And I have a question because those frameworks, they have pretty useful tools like ORM or routing or other stuff. But I think that the really important thing when designing restful APIs is the restfulness of them. So the question is, do you use swagger or any other tools for keeping the restful API being the restful? Or what's your experience on that? Yeah, so for microservices we use the swagger, as you said. But for example, in the way more monolithic service based on Django, the Rosable API were fine for us. So, yeah. But in general, that's it. And what's the name of this framework that you started with? Cherpie. Cherpie. Okay.