Okapi – A micro web framework for Haskell(okapi.wiki)
okapi.wiki
Okapi – A micro web framework for Haskell
https://www.okapi.wiki/
27 comments
Looks really nice but I haven’t tried it yet. I wrote a small book on my take on Haskell programming using a small subset of the language (read for free on my web site https://markwatson.com). When I update my book I might add an Okapi example. I have played around with Spock for simple web apps and that is nice enough, but I am really impressed by the care in putting together the Okapi documentation web site. Great material, nicely presented.
The author of this framework is also doing very interesting work on building Haskell server pages [1], taking inspiration from redbean's Lua server pages[2].
[1] https://monadic.systems/post7 [2] https://redbean.dev/#lua
[1] https://monadic.systems/post7 [2] https://redbean.dev/#lua
In case anyone else who's played with search engines thinks, "Wait, Okapi sounds familiar," here you go: https://en.wikipedia.org/wiki/Okapi_BM25
The "Get Started" and "View on GitHub" links both have `href="/"`, so they don't work.
The "Get Started" and "View on GitHub" links both have `href="/"`, so they don't work.
Thanks for sharing, although I feel like this is more likely just following the "put a bird on it" trend of naming software frameworks after animals
Thanks, this made me realize how good Haskell is for declaring API routing.
Hope the docs for Monad Transformer could be completed for me to understand and use the framework then.
Haskell for web? That's very impressive if you can get it to work at scale. This is the hardest language I have ever personally tried to learn.
Of course you can. As early as 2012, Michael Snoyman has written a book about it, Developing Web Applications with Haskell and Yesod. Yesod is an old web framework by now, but it's not even the oldest. Happstack is even older than that.
Do you write web applications in Haskell? It’s not clear where the community is, and that’s troublesome because for those not well oriented with Haskell, the adventure is solitary.
MS seems to be doing a bit of Rust these days, so I kind of wonder if the spiritual successor is another, albeit less hardcore, language.
For me, it’s been difficult because I don’t know where the false starts are, and don’t have the unlimited time I once had to wallow and grow without any community support. Other languages are just more approachable, but something eats at me that Haskell is worth it.
MS seems to be doing a bit of Rust these days, so I kind of wonder if the spiritual successor is another, albeit less hardcore, language.
For me, it’s been difficult because I don’t know where the false starts are, and don’t have the unlimited time I once had to wallow and grow without any community support. Other languages are just more approachable, but something eats at me that Haskell is worth it.
Not the person that you're responding to, but I write web applications in Haskell. Previously with Servant and these days mostly with scotty. Happy to try to answer any questions you have here, but there are great communities of helpful people on Reddit (r/haskell and r/haskellquestions) and the FP Slack as well. There's no need to go at it alone.
And you're right, Haskell is definitely worth it.
And you're right, Haskell is definitely worth it.
Not PP, but how often do you find yourself tracking down lazy-evaluation / GC-related performance issues?
I've heard some horror stories and I honestly don't have the mental model yet to track these things down. Even learning Rust, it still has the same "stack + heap + eager eval" sort of thing as C++.
I'm not sure how much of this is done in practice, or if the folks who've had it happen to them are just prolific at internet complaints.
I've heard some horror stories and I honestly don't have the mental model yet to track these things down. Even learning Rust, it still has the same "stack + heap + eager eval" sort of thing as C++.
I'm not sure how much of this is done in practice, or if the folks who've had it happen to them are just prolific at internet complaints.
Honestly, pretty much never, but the stuff I work on these days does not have significant performance or scalability requirements so usually I just write the most straightforward code possible and it's fast enough and doesn't leak.
The only place I really ran into that was on a project that inherited a framework written by consultants and that was really due to problems with the framework and not the language. Though I do still cargo cult some practices from those days that may be helping me to avoid some pitfalls today without realizing it -- eg. almost every field of almost every run of the mill business-domain data structure I create is strict (eg `!Int` instead of just `Int`).
I imagine you're going to hear more of the horror stories on the internet than the successes, but that sort of thing can be legitimately frustrating when coming to Haskell from other languages just because a lot of what you know goes out the window and you have to learn new concepts from scratch while getting up to speed on a new language with a new tool chain, etc. At some point you make it over the hump and it largely becomes a non-issue.
The only place I really ran into that was on a project that inherited a framework written by consultants and that was really due to problems with the framework and not the language. Though I do still cargo cult some practices from those days that may be helping me to avoid some pitfalls today without realizing it -- eg. almost every field of almost every run of the mill business-domain data structure I create is strict (eg `!Int` instead of just `Int`).
I imagine you're going to hear more of the horror stories on the internet than the successes, but that sort of thing can be legitimately frustrating when coming to Haskell from other languages just because a lot of what you know goes out the window and you have to learn new concepts from scratch while getting up to speed on a new language with a new tool chain, etc. At some point you make it over the hump and it largely becomes a non-issue.
I’ve done quite a few small to medium sized projects in Haskell, both personal and commercial, and worked on one larger system at an investment bank. It’s really easy to avoid those issues with modern Haskell, just following some rules of thumb (e.g. annotate all your datatype members with ! to make them strict) and avoiding some well known pitfalls.
I saw someone complaining about a memory leak the other day on reddit, and it boiled down to someone using annotations to control inlining and insisting that it ought to work. If you’re not flying close to the sun, you’re unlikely to have serious trouble.
I wrote a really nice system with Servant recently which does stream processing and serving of large files using the ‘streaming’ library (https://hackage.haskell.org/package/streaming). In its initial versions, my app wasn’t very snappy with large files, but I didn’t think much of it - it seemed acceptable. But while I was cleaning up the code I made a small change that improved its performance by an order of magnitude. I’d have to go check what it was now, but the gist of it was using these really high level abstractions in a suboptimal way. I don’t think that’s an issue with Haskell itself, so much as the tradeoffs involved in using powerful abstractions you don’t fully understand. I was super pleased with the end result though.
I saw someone complaining about a memory leak the other day on reddit, and it boiled down to someone using annotations to control inlining and insisting that it ought to work. If you’re not flying close to the sun, you’re unlikely to have serious trouble.
I wrote a really nice system with Servant recently which does stream processing and serving of large files using the ‘streaming’ library (https://hackage.haskell.org/package/streaming). In its initial versions, my app wasn’t very snappy with large files, but I didn’t think much of it - it seemed acceptable. But while I was cleaning up the code I made a small change that improved its performance by an order of magnitude. I’d have to go check what it was now, but the gist of it was using these really high level abstractions in a suboptimal way. I don’t think that’s an issue with Haskell itself, so much as the tradeoffs involved in using powerful abstractions you don’t fully understand. I was super pleased with the end result though.
Web application/service development is probably the most mature domain in Haskell's ecosystem after compilers & interpreters. Maybe it even exceeds that since so many people are using it.
There are plenty of people doing it for their jobs.
There are plenty of people doing it for their jobs.
Yes, I used to write web applications in Haskell. I did that before Rust was viable for writing web applications (and way before Rust reached 1.0). The community has IMO become a bit smaller after Rust became so popular.
I still miss HKT and the productivity benefits from those (the classic mostly true joke is that there are multiple npm packages whose entire functionality can be replaced by a single function in the standard library, `traverse`), but Rust's traits system is good enough.
I still miss HKT and the productivity benefits from those (the classic mostly true joke is that there are multiple npm packages whose entire functionality can be replaced by a single function in the standard library, `traverse`), but Rust's traits system is good enough.
Michael used to write lots of great Haskell material. I experimented with Yesod but used Spock (really simple framework) more. For business reasons, his company now supports non-Haskell languages.
Have you tried C? I’m not being snarky, remembering all the undefined behavior is a task in itself. I’m a Haskell neophyte, but I often find myself reaching for things haskell has in the box when I’m writing something in another language.
To me, it’s like the people who describe a cat as “just like a dog” as a positive trait for the cat. Why deal with the “just like” version if you can have the real thing? Just get a dog. So I find myself reaching for these tools and then I try to just go to the real thing. Unfortunately I can’t run Haskell on an ESP32 :)
Btw, this is not to denigrate cats, they are great in their own right. Not for me, I’m violently allergic and somewhat particular to having the things I ensure exist be thankful, but I respect everyone’s choices in the fluffy friend department.
To me, it’s like the people who describe a cat as “just like a dog” as a positive trait for the cat. Why deal with the “just like” version if you can have the real thing? Just get a dog. So I find myself reaching for these tools and then I try to just go to the real thing. Unfortunately I can’t run Haskell on an ESP32 :)
Btw, this is not to denigrate cats, they are great in their own right. Not for me, I’m violently allergic and somewhat particular to having the things I ensure exist be thankful, but I respect everyone’s choices in the fluffy friend department.
> somewhat particular to having the things I ensure exist be thankful
Sounds like a certain deity
Sounds like a certain deity
monads still keep me awake at night
Monads are only complicated if you have to unlearn stuff. You've probably written a ton of monads by accident, regardless of what language you use.
exactly, I finally got them when looking at examples in other languages. I never could shake the interest off because I caught a glimpse of god when trying haskell. The language didn't stick on me but I always miss haskell monads.
Because you can't stop thinking how great are they, right? Same
with
so you need to keep in mind both the order of the alternatives in todoAPI as well as the bodies of the individual handlers. That gets unwieldy very quickly.
It also seems likely to lead to the same problems with error handling that you tend to get with combinator parsers, where you usually only get details about the last failing branch, while the interesting failure might have been an earlier one.
Quiz question (I don't know the answer): What happens to a request for /todos/foo?