slides.pdfpc 3.6 KB

  1. [file]
  2. slides.pdf
  3. [font_size]
  4. 10897
  5. [notes]
  6. ### 1
  7. 13### 2
  8. Let's talk about servant, which is several things:
  9. API description DSL, we'll speak about how this DSL works
  10. and why it's at the type level
  11. Interpretations of the types resulting from that DSL, for example in
  12. web servers or API clients
  13. Servant is commonly used or implementing services with APIs, or for accessing
  14. other APIs with a simple, typed client
  15. ### 3
  16. Why type-level DSLs?
  17. Type-level DSL: express *something*, e.g. endpoints of API, on type level by combining types. Types can be uninhabited
  18. Phil Wadler's: expression problem: things should be extensible both in the cases of a type, and in the functions operating on the type
  19. Normal data types: can't add new constructors easily
  20. Servant lifts thisup to simply allow the declaration of new types that can be included in the DSL, and new interpretations that can be attached to the types through typeclasses
  21. APIs become first-class citizens, can pass them around, combine them etc, they are separate from interpretations such as server implementations. In contrast, in most webframeworks, API declaration is implicit
  22. (Mention previous attemps at type-safe web, Yesod / web-routes + boomerang etc)
  23. ### 4
  24. Three extensions are necessary:
  25. TypeOperators lets us use infix operators on the type level as constructors
  26. DataKinds promotes new type declarations to the kind level, makes type-level literals (strings and natural numbers) available, lets us use type-level lists and pairs in combination with typeoperators
  27. TypeFamilies: Type-level functions, map one set of types to another, come in two forms (type families, non-injective; data families, injective), more powerful than associated types
  28. ### 5
  29. Here you can see servant's general syntax, we define an API type as a simple alias of some other type combinations
  30. strings are type-level strings, not actually values, represent path elements
  31. endpoints are separated by :<|>, all endpoints end in a method with content types and return types
  32. Capture captures path segments, but there are other combinators, for example for headers
  33. Everything that is used from the request is expressed in types, enforcing checkability, no "escape hatch" inside handlers to get request
  34. Every combinator has associated interpretations through typeclasses
  35. ### 6
  36. Explain type alias, point out Capture
  37. Server is a type level function (type family), as mentioned earlier
  38. ### 7
  39. If we expand server (in ghci with kind!) we can see the actual type of the
  40. function
  41. ### 8
  42. Lets speak about some interpretations of these things
  43. ### 9
  44. Servant server is the main interpretation that people are interested in, it's used
  45. for taking a type specification and creating a server from it
  46. Based on WAI, the web application interface, common abstraction for web servers which came out of the Yesod project. Implemented by the web server warp, which Yesod runs on
  47. ### 10
  48. Explain snippet, path gets removed from server type (irrelevant for handler),
  49. route extracts string to value level
  50. ### 11
  51. Explain echo server quickly
  52. ### 12
  53. servant client allows generation of Haskell functions that query the API with the same types
  54. this makes for easy to use RPC for example
  55. ### 13
  56. A lot of other interpretations exist for all kinds of things, mock servers for testing, foreign functions in various languages, documentation ...
  57. ### 14
  58. Demo!
  59. 1. Go quickly through code
  60. 2. Run server, query with curl
  61. 3. Open javascript function
  62. 4. Show JS code in the thing
  63. 5. Open the map itself
  64. 6. Open GHCi, use client
  65. 7. Generate docs
  66. ### 15
  67. Conclusion
  68. Servant is pretty good, it's very easy to get started and it's great to raise the level of things that the compiler can tell you about when you do them wrong.
  69. ### 16
  70. Drawbacks.