Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing Servant vs wai-routes, the Slant community recommends Servant for most people. In the question“What are the best Haskell web frameworks for building RESTful web services?” Servant is ranked 3rd while wai-routes is ranked 6th. The most important reason people chose Servant is:
Routes are defined end-to-end with type declarations. This allows your API to be introspective, serving its own documentation and derived query code, via jQuery for Javascript and `servant-client` for Haskell.
Question Ranking
Pros
Pro Automatic documentation and Haskell/JS query generation
Routes are defined end-to-end with type declarations. This allows your API to be introspective, serving its own documentation and derived query code, via jQuery for Javascript and servant-client for Haskell.
Pro Excellent documentation
We Haskellers are accustomed to flying completely blind when using many libraries, luckily with Servant this isn’t the case. It features comprehensive tutorials, literate haskell examples for many use cases and great Haddock documentation for everything else.
Pro No Template Haskell
Everything is done within the confines of the existing type system, which helps keep compile times down.
Pro Nice ecosystem
Fairly large ecosystem of related modules for additional functionality.
Pro Provides type-safe routes
Automatically maps routes to datatypes which are checked at compile time. It uses Template Haskell to reduce boilerplate.
Pro Freely mix "unrouted" handlers with typesafe routing and middleware
Can be used without any routing or Template Haskell. "Unrouted" handlers can be freely mixed and matched with typed routing and middleware.
Pro Easy to customise
Wai-routes is extremely easy to customise. It's neutral to other parts of the system such as the templating language, or the wai server being used. Wai-routes only targets and provides full access to the wai API. The wai-routes handlers are also simple functions which are passed the request data and the environment and return a Response in IO. Arbitrary middleware, routes, and handlers can be mixed together to construct an application.
Pro Lightweight
Performs quite well when compared with other Haskell web frameworks.
Pro Subsites support
Subsites provide encapsulation and ability compile time enforcement of contracts between main site and subsites.
Pro Provides nested routes
Nested routes allow reduction of boilerplate code.
Pro Route annotations
Route annotations provide an easy way to "mark" routes for extra processing.
Cons
Con Complicated internals
Extending Servant's existing functionality can be made difficult by the complexity of its type level machinery. Lucky most use cases are able to avoid this.
Con Route specifications and implementations are only connected by their position in a large type list
You actually have to count the index of the entry where you changed the specification, and then go and change the entry at the same index in the list of implementation methods. There is no other indication that the two are connected. This along with complex and verbose route definitions, makes it very hard to safely make changes to an API.
Con Route definitions are more verbose and complicated than other options
You are required to define a number of separate complicated types and their implementations which are usually spread out over a number of files. This makes it hard to figure out the API.
Con Learning curve
Even though it's a "micro" framework, it has a steep learning curve when using advanced features such as subsites.
