UX vs. DX in Python Web Servers
In November, Agoda hosted a ThaiPy meetup with Bangkok’s Python community. Our speaker, Mohamad Kamar, a Senior Software Engineer at Agoda, shared a talk on “UX vs DX in Python Web Servers” He provided deep insights into Python’s versatility in web server architecture, ranging from simple synchronous servers to complex asynchronous and framework-based ones. This blog post summarizes the key points discussed during the talk.
What is UX and DX
User Experience (UX) refers to the overall experience of a user interacting with a web application. This includes considerations for speed, usability, accessibility, and overall user satisfaction. On the other hand, Developer Experience (DX) represents the experience of developers in building, maintaining, and scaling web applications. Factors like ease of setup, code maintainability, and debugging capabilities play a significant role here.
When attention is given to improving either DX or UX, it often yields indirect benefits for the other. Speed of feature development, for example, offers a more streamlined experience to the end-user, while simultaneously reducing the probability of bugs cropping up, thus aiding the developers.
Exploring Python Web Servers
Python’s versatility shines in its ability to handle various web server architectures — from simple synchronous servers that handle one request at a time to the more complex asynchronous and framework-based servers, Python offers a wide spectrum of options. Each approach has its unique implications for UX and DX.
Measuring Developer Experience in Web Server Code
Evaluating DX involves exploring several aspects. My analysis, though subjective, aims to provide a clear picture of the DX landscape in Python web server development:
Here’s a breakdown of these specific areas:
- Ease of setup: How effortless is it to get the server up and running? This includes aspects such as documentation quality, the availability of starter templates, the number of dependencies required, and the clarity of error messages during the setup process.
- Code readability: This is the ease with which developers can navigate and understand the codebase. It includes naming conventions, code organization, use of comments, and adherence to Python’s style guidelines (PEP 8), among other factors.
- Maintainability: This component evaluates how straightforward it is to test, scale, update, fix, and enhance the code. Portability (whether the code can be moved or adapted to different environments or frameworks without major refactoring), modularization, and adherence to best practices all affect maintainability.
- Debugging facilities: This involves assessing the tools and features offered by the webserver to aid in identifying and resolving code issues. It includes native debugging tools, logging facilities, error messaging, and the ease of integration with external debugging tools.
Having these as the basis for our analysis of our DX, we can compare how different ways of building a Python webserver fare in comparison to each other.
http.server: As part of the standard Python library, http.server is straightforward to set up, but it only offers basic functionality, impacting maintainability for complex applications. Debugging and testing capabilities largely depend on additional Python libraries you use.
It is worth noting that the documentation page for the http.server module itself recommends that developers refrain from using these libraries to build production applications for lack of security features.
aiohttp: This offers more complexity due to its asynchronous nature, making the setup less straightforward than the http.server. However, using Python’s asyncio can result in more efficient I/O operations, positively impacting maintainability for I/O-heavy applications. aiohttp’s documentation provides clues for debugging, but testing asynchronous code can be a little more challenging, necessitating the use of Python’s asyncio testing tools.
In addition, aiohttp, a very lightweight library that does not have as many features as the others on this list, is often used as a complementary library for creating web servers rather than being the main building block. According to the developer survey done by JetBrains:
“The popularity of most frameworks has remained stable year-over-year. One exception is libraries that provide support for asynchronous programming. The asyncio library reached an all-time high in popularity in 2022 (21%), aiohttp showed a slight increase, and httpx showed up for the first time in the survey, being selected by 9% of the respondents.”
FastAPI: FastAPI has been praised for its quick and easy setup, thanks to the smart use of Python-type hinting. FastAPI fosters maintainable code and includes built-in documentation for debugging and testing support.
Flask: With its minimalist approach, Flask provides setup ease and a flexible environment. It offers developers a range of choices, although it lacks inherent debugging tools, which are available through extensions like Flask-Debug Toolbar.
Django: Known for its “batteries-included” philosophy, where a lot comes set up out of the box, Django could be a bit overwhelming for new users. However, once configured, Django’s highly modular and reusable code could make maintenance more manageable. It comes with a robust ORM and an admin panel, which can assist in debugging, and has a built-in testing framework.
FastAPI, Django, and Flask are currently the most used frameworks in the market, followed by Tornado and some other less known libraries. A small spoiler for the upcoming sections is that none of the top 5 most used Python libraries score in the highest performance ratings.
Developer Preference
Developers’ preferences are shaped by personal experiences and project requirements. With time, they naturally lean towards technologies they know well. This familiarity boosts their comfort and efficiency. For example, a developer skilled in Django might prefer it for web server tasks, familiar with its features, community, and documentation.
Project requirements significantly influence developers’ choices in web servers and frameworks. The project’s nature and scope dictate the best fit. A developer might prefer Flask for creating a lightweight, small-scale application, whereas Django or Pyramid might be chosen for a more feature-heavy, complex project. Factors like server load, real-time updates, and the need for strong documentation and community support can also influence these decisions.
Performance Considerations
Performance is a crucial factor in web server selection. When comparing the performance of web libraries, it’s important to consider WSGI and ASGI standards. Asynchronous libraries like aiohttp and FastAPI are designed for ASGI environments (e.g., uvicorn), whereas Django and Flask default to WSGI setups (like gunicorn) and may need extra effort for other deployments.
Striking a Balance: UX and DX Optimization
Balancing UX and DX is more art than science. It’s about choosing the right tool for the right job. The utility of each framework largely depends on your specific use case. If your project is comparatively small in scale, levering heavy-weight frameworks like Django could result in overkill. Conversely, minimalist alternatives like Flask or FastAPI could provide a better fit.
For larger, more complex projects requiring a broad array of built-in functionalities and where using an opinionated framework isn’t an issue, Django would be a more suitable choice. If you appreciate a minimalist approach and enjoy the process of building everything from the ground up, consider using aiohttp.
Conclusion
Choosing the right Python web server framework requires a balance between UX and DX. Each framework offers unique features suited to different project requirements. Understanding these differences and aligning them with project needs is crucial for optimal web server selection.
References
