Trying to make building webapps easier in Haskell

While my previous post about Why building webapps in Haskell is harder than it ought to be, got a lot of attention it didn’t really solve my core problems. It’s not like the ~175 comments on Reddit threw up immediate quick-fixes to the issues I had raised. A lot of ORM-hating and how “OOP concepts can’t be translated to Haskell”

I get it. Transliterating concepts is not the answer. But I still need to know the right way to design non-trivial webapps in Haskell. The “right way”, at least for me will need to meet a few fuzzy requirements:

1. Uses Haskell’s rich type-system to reduce runtime bugs (or programmer errors) that a dynamically typed language would find hard to avoid.
2. A new programmer making a change to a large code-base should not feel afraid that he would inadvertently break something else without him/her even knowing about it.
3. Reduce the number of tests that one has to write.
4. Allow for rapid development and iteration of the core system design.
5. Be fun and easy to write.
6. Should not need a PhD in category theory :)

Since I can’t seem to find answers to my problems, I decided to figure them out on my own (with some help along the way, if possible). You can read my grand plan in entirety or make do with TL;DR below:

TL;DR

There is too much choice, with respect to libraries, when building a typical RDBMS-backed webapp. Most people (especially newcomers to Haskell) don’t know enough about advantages/disadvantages of various libraries to make the right choice. Making the wrong choice leads to a lot of needless frustration

I believe most things are possible in Haskell and its rich library ecosystem. However, making all of this work is not as easy as it ought to be. This is because the idiomatic and will-work for-80%-of-the-use-cases-with-20%-effort way of dealing with these things is not documented properly in one place.

The plan is to build a typical, Postgres-backed webapp in various Haskell libraries/frameworks to uncover the “Minimum Viable Architecture” in each.

Call for help

I’ve already begun my crazy plan with Servant+Opaleye. After my mis-step with Yesod, I believe Servant+Opaleye will be my silver bullet. But I can’t be sure. What if Yesod+Opaleye is the sweet spot? Too. Many. Choices.

Anyway, here’s Phase 1 of my world domination plan — writing a domain-level API on top a of the raw DB API (provided by Opaleye). And here’s me struggling with trying to design the API.

So, if you have any experience in designing & building systems in Haskell, especially webapp, please help me with my TODOs and RFCs.