Pure functional HTTP APIs in Scala - Ein Überblick

Ein Überblick mit Herausforderungen und Auswirkungen purer funktionaler Programmierung im Bereich HTTP-APIs bzw. Services.

Das Buch ist bei leanpub zu finden: https://leanpub.com/pfhais

Transcript

1. Pure functional HTTP APIs in Scala Jens Grassel 14.11.2019 Wegtam GmbH
2. Pure funktionale Programmierung?
3. Ja, pure funktionale Programmierung! • Nutzung von Cats-Effect (”IO-Monad”) • Nutzung lediglich ”purer” Bibiliotheken Was bringt uns das? Anstatt st¨ andig Bits zu schieben, bauen wir erstmal nur abstrakte Syntaxb¨ aume (ASTs). 1
4. Und warum ASTs? Weil wir diese nur bei Bedarf auch ausf¨ uhren (auswerten)! • Nachteil ⇒ man braucht etwas mehr Arbeitsspeicher • Vorteil ⇒ man spart unn¨ otige Arbeit • noch ein Vorteil ⇒ man kann ASTs kombinieren und optimieren 2
5. Herausforderungen
6. Andere Denkweise Die ”pure” funktionale Programmierung ist nochmal eine etwas andere Denkweise als die ”einfache”. • Ein komplett ”pures” Programm ist sinnlos (weder Ein- noch Ausgabe)! • Wir brauchen aber Ein- und Ausgaben! • Also was tun? Die L¨ osung Wir ”dr¨ ucken” die Seiteneffekte an die R¨ ander unseres Systems (Programms). 3
7. Und wieder ASTs • abstraktere Beschreibungen unserer Logiken • polymorphe Parametrisierung • Verarbeitung erfolgt durch gew¨ ahlte Frameworks (z.B. http4s). 4
8. Noch eine Schippe drauf! • Geht da nicht noch mehr? • Ja! :-) • statisch typisierte Beschreibung unseres Webservice • gibt verschiedene Bibiliotheken • nochmal abstrakter • ggf. Eigenheiten der verwendeten Bibiliothek zu beachten 5
9. Gibt es auch Vorteile?
10. Aber warum zum Henker? Wenn wir unsere API abstrakt in Typen beschreiben, dann • kann der Compiler sie verstehen, das heißt: • erkennen, wenn wir einen Endpunkt nicht korrekt implementieren • diverse n¨ utzliche Dinge f¨ ur uns automatisch tun • Routing f¨ ur unser bevorzugtes Framework erstellen (Server) • einen Client f¨ ur unsere API erstellen (Ja, automatisch!) • Dokumentation generieren (Swagger) 6
11. Leichteres Testen Wer mag das nicht, wenn Tests einfach sind? :-) • kein umst¨ andliches ”Mocking” fehlender Abh¨ angigkeiten mehr • M¨ oglichkeit von ”Test-Interpretern” f¨ ur Logiken • starke statische Typisierung verringert Notwendigkeit f¨ ur einige Tests (”Der Compiler macht das f¨ ur uns.”) 7
12. Die Gretchenfrage... Nun sag, wie hast du’s mit der Performance? • Benchmarks aus dem Buch sind recht eindeutig. • ”pure” liegt bei ”teuren” Operationen (POST, PUT) weit vorn (etwas 6-7 mal schneller) • bei GET Operationen etwas ausgeglichener, aber immer noch 6-7 Prozent Vorteil f¨ ur den ”puren” Ansatz 8
13. Was lernen wir daraus?
14. Sauberes Arbeiten lohnt sich! H¨ ort nicht auf Leute, die das als ”akademischen Unsinn” bezeichnen. • auch nicht auf Leute, die behaupten das sei zu langsam Stattdessen arbeitet sauber und ”pur” und freut euch ¨ uber: • besser verst¨ andlichen Code • besser testbaren Code • schnelleren Code (Yeah!) • jede Menge automatisch abgeleitete ”Boilerplate” 9
15. Was habe ich vergessen? Es gibt noch einiges mehr, das es sich zu lernen lohnt. • erh¨ ohte Sicherheit durch ”refined types” • leichteres Arbeiten mit tief verschachtelten Strukturen durch Optics 10
16. Ende... Vielen Dank! Das Buch gibt es hier: https://leanpub.com/pfhais 11