Flask view functions und Messaging als Programmierparadigma 2

Berlin, Tue, 04 Feb 2020 17:29:24 +0100 last edited: Tue, 04 Feb 2020 21:58:20 +0100

Flask view functions und Messaging als Programmierparadigma 2

Es handelt sich hier um den Zweiten Post zum Thema. Der Erste Post ist
hier
zu finden.

Kurze Zusammenfassung

Ich habe begonnen ein Ã¼bliches Codebeispiel fÃ¼r flask_login einem Refactoring zu
unterziehen. An dem UrsprÃ¼nglichen Beispiel konnte man gut das Problem der hÃ¤ufig
zu findenden Implementierungen von Flask View-Functions sehen.
In dem Beispiel wurden wie bei vielen in freier wildbahn auch produktiv zu
findenden Codes folgende Prinzipien nicht beachtet:

Nach meiner Erfahrung haben die Beispiele, die keine clean-code Prinzipien
verfolgen einen negativen Einfluss auf die Entwicklung von Software.
Die beispiele werden meistens fÃ¼r den eigenen Code angepasst oder im besten Fall
wird sich nur an ihnen orientiert. doch selbst dann kann man sich dem negativen
Einfluss eigentlich nur durch komplettes neudenken in form eines Refactorings
entziehen.

Mein Ziel ist es fÃ¼r mich und interessierte positive Beispiele zu schaffen.

Orientierung fÃ¼r mein Refactoring geben mir:

das ebook von Ralf Westphal
Messaging as a Programming Model
und zwei Blog Artikel von Steve Bate "messaging as a programming model"
Part 1
part 2

Ein Router muss her

Ich habe als mein Hauptproblem identifiziert, dass die View-Function, die den
POST /login behandelt zwei verschiedene Antworten zurÃ¼ckliefert und es definitiv
an einer Stelle einer verzweigung bedarf.
Da in der View-Function allerdings andere Funktionen integriert werden, sollte
dies dem IOSP folgend nicht in der View-function selbst sein.

Ich bin bereits auf das Pipes und Filter Pattern
aufmerksam geworden. Das ermÃ¶glicht mir aber nicht eine verzweigung zu bauen.
Eine Kleine modifikation eines Filters aber schon.
Der Router

Hier noch einmal kurz der letzte Stand des Beispielcodes:

 @app.route("/login", methods=["POST"])
 def login():
     username = request.form['username']
     password = request.form['password']
     if password == username + "_secret":
         id = username.split('user')[1]
         user = User(id)
         login_user(user)
         return redirect(request.args.get("next"))
     else:
         return abort(401)
  
 @app.route("/login", methods=["GET"])
 def get_login_form
     return Response('''
     <form action="" method="post">
         <p><input type=text name=username>
         <p><input type=password name=password>
         <p><input type=submit value=Login>
     </form>
     ''')

Da ich von der Idee befangen war mir direkt eine Message-Pipeline zu bauen habe
ich mir zunÃ¤chst eine Login-Message gebaut:

 class LoginMessage(object):
  
     def __init__(self, username, password):
         self.username = username
         self.password = password
         self.authenticated = False

Als Idee dahinter stand folgende Pipeline:

--login_message--> authenticate --login_message--> create_response --response->

Die Funktions authenticatesollte von einem Authenticator Object bereitgestellt
werden. Damit der Authenticator aber nichts von anderen Klassen wissen muss,
auÃŸer wie er mit die Login-Message liest muss diesem ein handler fÃ¼r einen
erfolgreichen login und ein handler fÃ¼r den Fehlerfall Ã¼bergeben werdne kÃ¶nnen.

Ich habe das so implementiert:

 class Authenticator(object):
  
     def __init__(self, on_auth, on_no_auth):
         self.on_auth =on_auth
         self.on_no_auth = on_no_auth
  
     def authenticate(self, login_message):
         if login_message.password == login_message.username + "_secret":
             return self.on_auth(login_message)
         return self.on_no_auth(login_message)

Damit ist es die Authentifizierungslokgic gekapselt und kann von der View-Function
integriert werden.

 authenticator = Authenticator(
         on_auth=lambda msg: do_user_login(msg),
         on_no_auth=lambda msg: abort_user_login(msg)
     )

Lambda in python sind einfach anonyme funktionen. Sie werden hier benÃ¶tigt damit
der Aufruf von do_user_login(msg)erst erfolgt wenn die Authentifizierung
erfolgreich war und nicht bereits wenn das Authenticator Object erzeugt wird.

Mehr zum Thema python lambda gibt es auf Real Python.

Dabei wird schnell klar, das wir die information ob der Benutzer angemeldet ist
eigentlich gar nicht in unserer Login-Message brauchen.
Und wenn es sich bei LoginMessage um einen dummen Datenspeicher handelt
wozu sollte man dann in Python gleich eine ganze Klasse schreiben.

Im Grunde kann unsere View Function mit dem neuen Wissen doch ganz
knackig aussehen:

 @app.route("/login", methods=["POST"])
 def login():
      login_message = dict(
          username=request.form['username'],
          password=request.form['password']
      )
      authenticator = Authenticator(
          on_auth=do_user_login,
          on_no_auth=lambda msg: abort(401)
      )
      return authenticator.authenticate(login_message)

In Python kann man auch referenzen auf Funktionen Ã¼bergeben. Damit braucht es
fÃ¼r do_user_login kein lambda, sofern diese Funktion ein Argument fÃ¼r die
Login-Message akzeptiert. Ddas Lambda fÃ¼r abort(401) muss bleiben, denn
hier wird die Login-Messga gewissermaÃŸen ins leere Laufen gelassen.

Ich halte es fÃ¼r eine Ã¤uÃŸerst praktische idee in Python fÃ¼r die Ã¼bertragung von
Nachrichten ein Dictionary kompatibles Objekt zu verwenden.
Wenn man aus irgendwelchen GrÃ¼nden mehr als ein reines Dictionary braucht kann
mann ja die entsprechenden "magischen" Methoden implementieren.
FÃ¼r meine zwecke reicht mir aber ein Dictionary.

Dann mÃ¼ssen aber die Nachrichten Filter oder mein Authenticator Router auch
mit Dictionaries arbeiten kÃ¶nnen.
Das gute daran ist, dass die Nachricht damit sehr leicht erweiterbar ist ohne
das irgendwo eine andere Klasse als Konsumenten oder Produzenten des betreffenden
Keys angepasst werden muss.

Der Neue Authenticator schaut dann so aus:

 class Authenticator(object):
  
     def __init__(self, on_auth, on_no_auth):
         self.on_auth =on_auth
         self.on_no_auth = on_no_auth
  
     def authenticate(self, login_message):
         if login_message['password'] == login_message['username'] + "_secret":
             return self.on_auth(login_message)
         return self.on_no_auth(login_message)

Es Fehlt nur noch die do_user_login Funktion. Diese ist ebenfalls eine reine
Integration der User Klasse, der login_user Funktion von flask_login und
von redirect.

 def do_user_login(login_message):
     id = login_message['username'].split('user')[1]
     user = User(id)
     login_user(user)
     return redirect(request.args.get("next"))

Auch schÃ¶n, es ist dem do_user_login egal wie oder ob der Benutzert
autentifiziert wurde. Es besteht auch keine abhÃ¤ngigkeit zur eigentlichen
Anfrage. Diese Funktion kÃ¼mmert sich darum eine Antwort fÃ¼r flask_login
und den Seitenaufrufer zu erzeugen.

Das vollstÃ¤ndige Codebeispiel ist als Gitlab Snippet
zum ausprobieren verfÃ¼gbar.

EDIT
Mir ist aufgefallen dass ich vergessen hatte dass man in Python auch Problemlos
referenzen auf Funktionen Ã¼bergeben kann. Lambdas bleiben sinnvoll z.B. wenn
eine einfache konvertierung des Argumentes erfolgen soll oder die auf zu rufende
Funktion kein (oder kein Login-Message) Argument unterstÃ¼tzt / erhalten soll.

Techlevel-Dev Python Develpment Software-Architektur Messaging als Programmierparadigma

Flask view functions und Messaging als Programmierparadigma

Sebastian Lobinger Tech-Blog

Berlin, Tue, 04 Feb 2020 11:11:05 +0100 last edited: Wed, 23 Mar 2022 13:30:32 +0100

Zum Behandeln von HTTP Anfragen muss man fÃ¼r Flask jeweils Eine Funktion
schreiben die eine Anfrage auf eine konkrete Ressource behandelt.
Diese Funktionen werden oft View-Functions genannt.
Ich finde den begriff treffend und werde ihn daher auch benutzen.

Eine View-Function sollte m.E. immer eine Art von Abfrage behandeln.
Negativbeispiel sind hier die viel zu findenden Beispiele zum Handhaben von
Formularen.

 @app.route("/login", methods=["GET", "POST"])
 def login():
     if request.method == 'POST':
         username = request.form['username']
         password = request.form['password']
         if password == username + "_secret":
             id = username.split('user')[1]
             user = User(id)
             login_user(user)
             return redirect(request.args.get("next"))
         else:
             return abort(401)
     else:
         return Response('''
         <form action="" method="post">
             <p><input type=text name=username>
             <p><input type=password name=password>
             <p><input type=submit value=Login>
         </form>
         ''')

Die erfahrung zeigt, dass mangels anderer Beispiele diese Beispiele schon aus
pragmatischen ErwÃ¤gungen (get things done) Ã¼bernommen werden. Dadurch wird
weiter ausufernden Verzweigungen innerhalb einer View-Function vorschub
geleistet. Es entsteht schnell schwer lesbarer, und noch unÃ¼bersichtlicher und
damit schwerer testbarer Code. Resultat, Ã¤nderungen werden irgendwann schon
allein deshalb vermieden, weil man fast immer etwas kaputt macht.

Das obige Beispiel lÃ¤sst sich recht leicht umbauen:

 @app.route("/login", methods=["POST"])
 def login():
     username = request.form['username']
     password = request.form['password']
     if password == username + "_secret":
         id = username.split('user')[1]
         user = User(id)
         login_user(user)
         return redirect(request.args.get("next"))
     else:
         return abort(401)
  
 @app.route("/login", methods=["GET"])
 def get_login_form
     return Response('''
     <form action="" method="post">
         <p><input type=text name=username>
         <p><input type=password name=password>
         <p><input type=submit value=Login>
     </form>
     ''')

Das schaut schon besser aus ist fÃ¼r mich aber noch nicht wirklich befriedigend.
Es verleibt ein
if .. else
Block in der login Funktion die
request
und
redirect
integriert. Das ist eine Verletzung vom
IOSP.

Ralf Westphal hat hierzu ein sehr schÃ¶nes ebook verfasst:
Messaging as a Programming Model.
Nach meinem VerstÃ¤ndis befindet sich eine Flask View-Function am Stamm des von
Ralf Westphal in diesem Buch skizzierten Baums der Funktionsaufrufe.
Oder wenn man sich das in Schichten vom Aufruf des Programms bis zu den ganz unten liegenden Operationen vorstellt stellt die View-Function einen Teil der
OberflÃ¤che dar.
Wichtig bei den unten liegenden Operationen ist, dass sie dem IOSP oder noch
besser dem
Prinzip der gegenseitigen Nichtbeachtung (PoMO) folgen.

Aber ich interessiere mich gerade nicht fÃ¼r die BlÃ¤tter, wie Herr Westphal die
Operationen in seinem Buch nennt, sondern fÃ¼r die Integrationsteile.

Kleine Abschweifung zum Thema bessere Ausbildung von FachkrÃ¤ften: spoiler

Hier liefert mir das Buch von Herrn Westphal einen guten Ansatz, der mir aber
so noch nicht ausreicht. SchÃ¶n zum Entwerfen auf Papier, alles klar, aber leider
etwas zu Abstrakt.
Aber er bezieht sich auf Steve Bate mit dem der zu dem Thema auch eine
Korrespondenz gefÃ¼hrt hat.
Steve Bate hat zu Messaging as a programming model
einen sehr langen und guten Blog Artikel geschrieben, zu dem es auch einen
zweiten Teil gibt.

Hier bekomme ich LÃ¶sungsansÃ¤tze fÃ¼r das Problem.

Ich vermute man kann in der View-Function sehr gut eine Pipeline nach dem
Pattern Pipes and Filters
integrieren. Wir geben aber zwei unterschiedliche Flask-Respnse Objekte zurÃ¼ck.
Entweder, wenn der Login erfolgreich ist einen Redirect oder einen Abort.
Ich sehe zwei Herangehensweisen fÃ¼r das Problem.

Es muss einen Filter geben, der aus dem egebnis der Login PrÃ¼fung einen der
beiden Responses erzeugt. Damit muss dieser dann aber wieder wisse Ã¼ber die Kontrolllogik fÃ¼r die empfangende Nachricht und das Response Object haben.
Damit wÃ¤re mein Problem nicht gelÃ¶st sondern nur in eine Tiefere Ebene
Verschoben.

Es muss einen Filter geben der die Login Nachricht bei Fehlschlag an
einen Filter weiter leitet der den Response fÃ¼r einen Abort und bei
Erfolg an einen Filter weiter leitet der den Response fÃ¼r einen Redirect
erzeugt.

Ansatz 1 ist vor allem besonders Unbefriedigend, da er auch noch gegen
"Simple is better than complex." aus
"The Zen of Python" verstÃ¶ÃŸt.

Das mÃ¼ssen wir bei LÃ¶sung zwei zar auch hinnehmen. Aber der Ansatz 1 ist nicht
einfach nur komplexer, denn er lÃ¶st das Problem nicht in unserem Sinne.
Er verkompliziert die Dinge auch. Damit ist
"Complex is better than complicated." aus
"The Zen of Python" ebenfalls
verletzt.

Die gestiegene KomplexitÃ¤t fÃ¼r ansatz 2 wÃ¤re ein notwendiges Ãœbel.
Ich wÃ¼rde sogar behaupten, dass es den Ansatz
"Flat is better than nested." aus "The Zen of Python" unterstÃ¼tzt.

Ich kann damit nÃ¤mlich definitiv stark verschachtelte (tiefe) Verzweigungen
leichter vermeiden.

Steve Bate bezieht sich in seinem blog Ã¼brigens auf das Buch
"Enterprise Integration Patterns: Designing, Building, and Deploying
Messaging Solutions" von Gregor Hohpe und Bobby Woolf
(Link zum buch auf smile.amazon.de).

Auch Sehr Informativ in diesem Kontext dÃ¼rfte "Patterns fÃ¼r Enterprise
Application-Architekturen" von Martin Fowler
(Link zum Buch auf smile.amazon.de) sein.

Techlevel-Dev Development Software-Architektur Python Messaging als Programmierparadigma