# Haskell frameworks/libs
## Yesod
### Advantages
* <span style="color:green">Offers templating for type-safe, well-formed content</span>
While not required, Yesod offers templating through a Shakespearean family of languages to produce page code.
* <span style="color:green">Type safe URLs</span>
Ensures that data provided by the URL is type-safe. This means that data in the URL has a definitive type.
* <span style="color:green">Lots of batteries included</span>
E.g. modern systems for authentication, routes and resources access control, etc.
### Disadvantages
* <span style="color:red">Hard to customize</span>
Learning how Yesod works internally is hard. It is a large framework with complicated components. Finding the appropriate code and understanding how it contributes to the framework is difficult, meaning developers will struggle.
* <span style="color:red">Lots of template haskell</span>
## Scotty
### Advantages
* <span style="color:green">Simplicity (for simple applications)</span>
* <span style="color:green">Production-grade quality despite small size and simplicity</span>
* <span style="color:green">Overall good and easy to pick up for simple applications</span>
### Disadvantages
* <span style="color:red">Not very performance-oriented (observable with lots of requests)</span>
"Performance is a legitimate concern with scotty, because the last time I checked its source code, it wasn't doing anything fancy to speed up the routing. I.e. it keeps your routes in a list, and tries them one by one to see if they match a given request. Again though, as scary as this sounds, it never had any noticeable impact for us."
* <span style="color:red">Not very scalable</span>
* <span style="color:red">Bad with multipart requests</span>
* <span style="color:red">Gets very complicated for complex applications, no routing type-safety</span>
"Scotty is kind of a worst-of-both-worlds. It's not simple and it's not powerful.
Sure, it looks simple, but as soon as you try to do anything more flexible or powerful, you need to know how to dig into how monad transformers work. The documentation on extending it isn't great either.
For all this complexity, you don't even get a powerful web framework. The routing isn't type-safe. The parameter acquisition scheme isn't great. The response building team isn't great either.
I'd skip it and go for yesod (100% if you're building a server-side-rendered app, also a good choice for a JSON API) or servant (if you're only building a JSON REST API and would benefit strongly from the autogeneration and client derivation - eg, in a microservices context)."
* <span style="color:red">Not very large ecosystem, lacks features</span>
Since Scotty is small, it does not contain some features that a complex web application may need. Anything that Scotty can't provide must be either found or written, costing developers.
## Servant
### Advantages
* <span style="color:green">Excellent documentation</span>
* <span style="color:green">Automatic documentation and Haskell/JS query generation</span>
* <span style="color:green">No Template Haskell</span>
* <span style="color:green">Large ecosystem of related modules</span>
* <span style="color:green">Swagger</span>
"We actually have a few endpoints we serve over servant in order take advantage of servant-swagger."
Swagger is a project used to describe and document RESTful APIs. The core of the project is the OpenAPI Specification (OAS).
* <span style="color:green">Recomandat de Radu Ometita (cu precizarea ca si celelalte sunt bune si fiecare cu ale lui)</span>
### Disadvantages
* <span style="color:red">Extending functionality can be difficult</span>
Extending Servant's existing functionality can be made difficult by the complexity of its type level machinery. Luckily most use cases are able to avoid this.
* <span style="color:red">Changes to the API can be unsafe</span>
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.
* <span style="color:red">Very verbose and complicated route definitions</span>
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.
\
\
\
\
\
Links:
\
https://www.reddit.com/r/haskell/comments/l7q1dx/using_scotty_in_production/
https://www.andres-loeh.de/Servant/servant-wgp.pdf
https://www.slant.co/options/2270/~servant-review
https://www.slant.co/versus/2266/2270/~scotty_vs_servant
https://www.slant.co/options/2266/~scotty-review
https://www.slant.co/topics/727/~best-haskell-web-frameworks-for-building-restful-web-services