Alexander CS Hendorf

An exchange of views on fastAPI in practice. FastAPI is great, it helps many developers create REST APIs based on the OpenAPI standard and run them asynchronously. It has a thriving community and educational documentation. FastAPI does a great job of getting people started with APIs quickly. This talk will point out some obstacles and dark spots that I wish we had known about before. In this talk we want to highlight solutions.

An exchange of views on fastAPI in practice. FastAPI is great, it helps many developers create REST APIs based on the OpenAPI standard and run them asynchronously. It has a thriving community and educational documentation. FastAPI does a great job of getting people started with APIs quickly. This talk will point out some obstacles and dark spots that I wish we had known about before. In this talk we want to highlight solutions. This talk will include the following: ### fastAPI is built on the shoulders of giants I: [pydantic](https://docs.pydantic.dev/) FastAPI makes extensive use of [pydantic](https://docs.pydantic.dev/). [pydantic](https://docs.pydantic.dev/) parses data, can validate (and transform) data, and has built-in interfaces to export OpenAPI definitions among many other features. ### fastAPI is built on the shoulders of giants I: [starlette](https://www.starlette.io) Routes and middleware are managed by [starlette](https://www.starlette.io). In this section we will explore how to create custom middleware and what we learned along the way. ### fastAPI has tutorials, but is this documentation? The fastAPI page provides a good introduction. The more we worked with fastAPI, the harder it was to find accurate documentation. Looking at the source code, we really missed DocStrings! Introspection to the rescue - will probably include a rant about missing DocStrings! ### DRY ("Don't repeat yourself") with pydantic For our use case, we decided to use strict models to validate our data structures, as we work in a highly regulated industry where no mistakes are allowed to happen. Setting up the REST API was much easier than developing consistent models that generalise well. We follow the "single source of truth" paradigm, entering redundant definitions is an absolute no-go. In this section we show how to create highly reusable pydantic model pools with inheritance for use in fastAPI. For testing, we also created models from metadata! ### "The road not taken": pydantic Depends()! API routes often consist of a request model and a response model. But what about cases where the models alone don't work and a model and e.g. query parameters need to be mixed? Apart from flake8 complaining about having callables in the signature, this can be quite a difficult use case. Strategies for resolving model/parameter conflicts. Bonus - if time: ### Integrating fastAPI with Sphinx. Demonstrate how to integrate OpenAPI with your Sphinx documentation. The talk will show how fastAPI is built and how well introspection can help you understand what is going on under the hood and which library is actually doing the heavy lifting where.

In this talk, I'll give an overview of software quality and why it's important - especially for scientists. Provide best practices and libraries to dive deeper into, hypes to ignore, and simple guidelines to follow to write code that your peers will love. After the talk, the audience will have a guide on how to develop better code and be aware of potential blind spots.

In this talk I will provide an overview of best practices for software quality. Practices and libraries to look deeper into included, hypes to be ignored providing simple guidelines to follow for writing code your peers will love. Jupyter notebooks are often messy, scripted applications like to contain redundant code and like to fail just before the result - wasting precious time. The code works for one-time use, but is difficult to maintain, reuse, or read by colleagues. In this talk I will present best practices to make code: - more readable - better to maintain - re-usable Flag potentially bad practices as: - closures - using too many third libraries Practices how to best design applications including: - refactoring - versioning - DRY - when to write tests - documentation Provide an overview of the habitats production-ready code likes to live in like CI/CD pipelines. After the talk the audience will have a guideline on how to develop better code, and be aware of potential blind spots. Software quality is important - especially for research! This talk provides an overview of best practices and libraries to dive deeper into, hypes to ignore, and simple guidelines to follow to write code that your peers will love.