Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pure functional HTTP APIs in Scala - Ein Überblick

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

16ad3ff954790c142086a2dfde2aea48?s=128

Jens Grassel

November 14, 2019
Tweet

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