Writing micro-services in Python... Sure!
But which framework

By Emmanuelle Delescolle

Who am I?

• Emma
• Co-founder of LevIT
• Individual Member of the DSF
• Maintainer of DRF-Schema-Adapter
• Maintainer of Ember-cli-crudities

Why this talk?

• Hello To The World in 8 web frameworks by Aaron Basset
• Django is too bloated for microservices

Why micro-services?

• You probably don't need microservices
• But what if you have no choice
  (or do actually need them)

What do I want?
(as developer)

• Good documentation
• Good eco-system (doesn't have to be large)
• Easy switch between environments (dev, prod, etc...)
• Shell access
• Auto-documentation of endpoints
• Browsable API
• Common project architecture

What do I want?
(as sysadmin/dev-op)

• Good documentation
• Common tooling / software
• Managed processes
• Logging
• Easy switch between environment
• Hot reload

What do I want?
(as product owner)

• Widespread framework
• Good documentation
• Common project architecture
• No bikeshedding
• Some performance
• Documented API's (contracts)
• Testing

Testcase

Simple webshop - SQLite DB - OAuth2 - behind Nginx.

• addition (no auth - no db)
• catalog (no auth - db)
• authentication (local auth - db)
• order creation (remote auth - db)

Frameworks

Flask - Nothing included

• "Freeform" (not opinionated)
• No boilerplate
• Wide and somewhat scattered ecosystem
• (started as a joke)
• Preferred SQLAlchemy - OAuth2

Frameworks

Pyramid - Hand-crank included

• "Freeform"
• More structured than flask
• Good documentation
• Wide ecosystem
• Preferred SQLAlchemy - (recently) OAuth2

Frameworks

Django - Batteries included
(requires special charger)

• Opinionated (very)
• Good documentation
• Wide eco-system
• Own ORM
• Own auth (but works with OAuth2)

Frameworks

FastAPI - Solar panel included

• Young
• Opinionated
• Good documentation (so far)
• Async
• Small ecosystem (but that's ok)
• Preferred SQLAlchemy - databses?
• Some Oauth2 over your own code

(My?) Requirements

Documentation / Ecosystem

• Django wins
• Flask is a headache
• Pyramid is Switzerland
• FastAPI is scarce

Shell access

• Ok in Django, Flask, Pyramid
• Missing in FastAPI

Auto-documentation of endpoints /
Browsable API / Contract

• Out of the box in Django and FastAPI
• API NOT browsable in FastAPI
• Easy in Pyramid
• Fastidious in Flask

Testing framework

• All are easily testable
• Only Django "pushes" you to write tests

Common project architecture

• Not much choice in Django
• A bit more choices in Pyramid
• Flask and FastAPI let you go all directions

USE COOKIECUTTER

Common tooling / Software,
Managed processes
& Hot reload

• Django, Flask and Pyramid are WSGI apps (common)
• uWSGI provides process management + hotreload
• FastAPI is ASGI (not common yet)
• Need for supervisor (no hot-reload)

Logging

• Standard python logging
• Some documentation better than others
• Different packages available for most frameworks

Easy switch between environments

• Pyramid wins
• Flask has something
• Django has something else
• FastAPI... not yet

Bikeshedding...

• There will be some... Train your humans
• The more opinionated, the less room for bikeshedding
• Surprisingly lots of room for bikeshedding with FastAPI

Performance... On a pi!

Tested using Locust and htop

Performance... On a pi!

• Between 350-400 RPS
• FastAPI uses about 50% less CPU
• Django uses the less RAM

No DB - No Auth

Performance... On a pi!

DB

• ~125 RPS (not for FastAPI)
• Limited by Sqlite
• Django uses the less RAM
• FastAPI seems very slow (65 RPS) - seemed to fare better on a desktop - databases?

Performance... On a pi!

Auth and more

• <100 RPS
• Limited by network overhead/speed?
• FastAPI fares good with requests
• Django doesn't use more RAM

Conslusions?

More?

Come to the workshop on Sunday!

Questions