 Hello everyone, my name is David Lopez, I'm a software developer at the University of Freiburg and I recently joined the Galaxy community and the Galaxy backend working group. In this learning talk, we are going to summarize some of the benefits of modernizing the current Galaxy API by using the latest features that Python and its SQL system have to offer. If you have used Galaxy before, you probably know what the Galaxy REST API is, or at least you have been using it all the time, maybe even without knowing it. The REST API or application programming interface is an essential part of the Galaxy server. It allows external system to access Galaxy programmatically via the HTTP protocol. In fact, the Galaxy web interface, or frontend, is an example of a client that uses the API to perform all the interactions with the server. So this interface enables multiple kinds of client to communicate with Galaxy. For example, it can be also used to automate and control complex data analysis and workflows in a programmatic way and integrate it with your own system and applications, using other client implementations like Biobend, for example. If you want to know more about how to use the API, I highly recommend checking your real call scripting Galaxy using the API and Biobend, available at the Galaxy training network. Or in case you want a deep dive into the Galaxy code architecture around the API, make sure to check out John Chilton's YouTube channel and the web request video. So why modernizing the API? Well, the codebase was initially developed using Python 2 a really long time ago, especially in terms of programming. It eventually evolved and grew with the technology available at the time and it turned into a custom framework developed to simplify and unify the handling of API requests, data serialization, etc. This of course offers great flexibility, but also like any other codebase that gets off enough, it comes with a maintainability burden. Since the support of Python 2 was recently dropped in Galaxy, we can now look into more modern frameworks and technologies around REST APIs in the Python ecosystem. One of those frameworks that really stands out is Fast API. It is basically a high performance web framework for building APIs with Python 3, based on standard Python type hints. It is built on top of over-grade Python libraries like Starlet and PythonTik, with a focus on simplifying the development of REST APIs. Apart from being fast, robust and production ready, it is also really intuitive and easy to use, in great measure thanks to its excellent documentation. So one of the reasons to move to Fast API is certainly performance. In this regard, it supports asynchronous requests and web sockets, which we will explore a bit more in detail later. Another important reason of course is maintainability. For example, we no longer need to perform manual data validation when handling the request, or the API documentation can always be in sync with the code, and also we don't need to maintain a custom framework anymore. Last but not least, simply by using Fast API, we can directly comply with the Open API standard, which provides some interesting features like automatic client code generation and interactive documentation, among others. Let's explore now a bit more in detail some of these benefits. Fast API is an AESGI or asynchronous server gate interface framework, and supports a sync await operation out of the box. This means that it can usually process more requests per second than traditional AESGI frameworks by leveraging concurrency. Instead of simply waiting for a slow operation to finish, the application can do other tasks like attending other requests until the slow operation is complete. In general, any relatively slow EO bound operation can be done as increasingly like, for example, database operations, network operation, or disk or file access operations. Web sockets provide a full-duplex communication channel between the client and the server. We can also use Web socket subscription to allow the client to receive a notification when a certain task has finished, instead of constantly pull the server for the status. This can be much more efficient by avoiding necessary requests and providing updates in real time. Fast API uses pydantic models and standard Python type hints to define the API schema. A pydantic model is just a class that has its variables annotated with type hints and provides data validation at runtime. They are simple, explicit, and intuitive, which make them plain eyes with code editors and especially with our brain. They also help to maintain the API documentation in sync with the code just by providing some additional metadata. The interactive API documentation is another example of direct benefit from using Fast API, since it supports the open API standard out of the box. Even without providing any additional descriptions or metadata in the pydantic models, the documentation is much more discoverable, intuitive, and easy to use for technical and non-technical users. Also thanks to the open API standard, it is possible to auto-generate client code in many different programming languages, making Galaxy easier to integrate with other applications or systems. Well, we have now briefly covered some of the most interesting benefits of modernizing the current Galaxy API. So thanks for your attention and enjoy the rest of the talks.