Any existing Rails vs Yesod feature parity comparison?

Learn
#1

Has someone already done a comparison of a recent Rails version and a recent Yesod version for feature parity for REST API development? I’m interested in reading such a comparison if it already exists. If not, no worries and no need to generate one in this discussion thread. I’ll just do my own homework.

3 Likes
#2

I don’t know of one, but it seems like IHP might be a closer reference point than Yesod. IHP seems to be targeting that same niche as Rails of being opinionated, quick to get started with, aimed at people new to the language.

4 Likes
#3

Thanks. Definitely not touching nix right now, since most of dev team would be running mac.

It doesn’t have to be beginner friendly. I might have a budget to hire a consultant to write documentation for libraries that aren’t beginner friendly.

I am looking for something with the most commercial users that comes closest to matching the rails rest API mode features below. I assume the most likely options are yesod or servant + persistent.

Handled at the middleware layer:

  • Logging: Rails applications log every request, with a level of verbosity appropriate for the current mode. Rails logs in development include information about the request environment, database queries, and basic performance information.
  • Security: Rails detects and thwarts IP spoofing attacks and handles cryptographic signatures in a timing attack aware way. Don’t know what an IP spoofing attack or a timing attack is? Exactly.
  • Parameter Parsing: Want to specify your parameters as JSON instead of as a URL-encoded String? No problem. Rails will decode the JSON for you and make it available in params. Want to use nested URL-encoded parameters? That works too.
  • Conditional GETs: Rails handles conditional GET (ETag and Last-Modified) processing request headers and returning the correct response headers and status code. All you need to do is use the stale? check in your controller, and Rails will handle all of the HTTP details for you.
  • HEAD requests: Rails will transparently convert HEAD requests into GET ones, and return just the headers on the way out. This makes HEAD work reliably in all Rails APIs.

Handled at the Action Pack layer:

  • Resourceful Routing: If you’re building a RESTful JSON API, you want to be using the Rails router. Clean and conventional mapping from HTTP to controllers means not having to spend time thinking about how to model your API in terms of HTTP.
  • URL Generation: The flip side of routing is URL generation. A good API based on HTTP includes URLs (see the GitHub Gist API for an example).
  • Caching: Rails provides page, action, and fragment caching. Fragment caching is especially helpful when building up a nested JSON object.
  • Basic, Digest, and Token Authentication: Rails comes with out-of-the-box support for three kinds of HTTP authentication.
  • Instrumentation: Rails has an instrumentation API that triggers registered handlers for a variety of events, such as action processing, sending a file or data, redirection, and database queries. The payload of each event comes with relevant information (for the action processing event, the payload includes the controller, action, parameters, request format, request method, and the request’s full path).
1 Like
#4

Ihp docs are amazing!!!

1 Like
#5

Just want to point out that IHP is primarly developed on macOS, so everything typically works fine there :slight_smile:

3 Likes
#6

I don’t think you have worked somewhere where management and peers disliked Haskell and you have tried to advocate for it. I was in that situation in the past. This situation wouldn’t be like that, but people would definitely be comparing Haskell against other languages. The last thing I would want to deal with is troubleshooting someone’s nix installation before they even compile their first line of Haskell, let alone teaching about monads, all the concepts in Haskell.

For a team that is gung ho on trying haskell, ihp makes sense, but most beginners will be comparison shopping and you don’t want nix issues to be a factor in the comparison.

1 Like
#7

Actually, you might be able to document an official way of using vscode’s remote-ssh or openvscode server to have ihp run on Linux on a server, but have developers use vscode with any os to connect to the server.

I think you have mentioned gitpod and codespaces in your prior discussions.

#8

There’s an official GitPod template. It’s documented here: IHP Guide

Here’s a direct link to GitPod if you want to give it a try: Dashboard — Gitpod

IMO using GitPod is a lot simpler than manually dealing with vscode remote-ssh. So it might be a good alternative :slight_smile:

1 Like
#9

Is the essence of ihp to use shell scripts for code gen to keep things DRY instead of template haskell or type level programming?

#10

We try to avoid too much type level programming in user level code to keep IHP easy to use for non-haskell experts.

GHC generally generates unhelpful error messages when dealing with these complex type level things. This makes haskell newcomers get stuck when they’re just starting their IHP project. To avoid that from happening we sometimes use more simple concepts (like code gen instead of TH)

2 Likes
#11

I duplicated the gitpod template to gitlab and tried it in gitpod. It got pretty far. The build of the development environment took about ten minutes. Once the IDE started, I encountered the following error:

[13 of 13] Compiling Main             ( Main.hs, interpreted )
Ok, 13 modules loaded.
ok

initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /nix/store/j1by8l462jik0hyssba202faca06nlrk-postgresql-13.5/bin/pg_ctl -D build/db/state -l logfile start

CREATE EXTENSION
CREATE TYPE
CREATE FUNCTION

<interactive>:5:37: error:
    * Variable not in scope: app :: Async a0
    * Perhaps you meant `ClassyPrelude.ap' (imported from ClassyPrelude)
Ok, 13 modules loaded.
Server started

I’m unsure if this was a fatal error or a warning. I’ll try it again in a few months, out of curiosity.

#12

Does IHP work now on ARM64 Mac? I tried it a while ago and I got spurious nix build errors.

#13

This is a kind of race condition that happens on the first start in GitPod :slight_smile: But it doesn’t affect anything and can be ignored. The app and dev server are working as expected even with the above error.

#14

The current master version is already working on M1 (we just set up a M1 macbook last week at digitally induced, so it’s definitely confirmed to be working on master with M1). The last release v0.18 is not yet working on M1. It’s time we release v0.19 :slight_smile:

#15

Well, keep me posted on this one, I’m really keen on trying IHP, however I only have an M1 Mac to try it on.

#16

Got it. I tried it again and everything is running in the gitpod browser vscode, and if I use VS Code’s “Simple Browser”, it shows the site.

For me, the only other thing that I would want is different templates - one template for a full stack site and one template for a REST API. I don’t need any of this now, but if you are planning for a later release, I might use it later on.