[lucasdicioccio]

I have a (non-contributor) experience with the PostgREST codebase. It's true PostgREST codebase is not great (lots of long functions, need some work to extract the main program into a library etc.) but the codebase definitely is easy to navigate and modify. For a transient project at work I've asked a dev to evaluate how much work it would be to port PostgREST to MSSQL. My dev had a working proof-of-concept in a few days. The bottleneck was not navigating and patching PostgREST codebase but dealing with MSSQL. We decided to go another route only for the lack of a native MSSQL driver in Haskell: there's an ODBC driver (which my dev used for his PoC) but I don't really trust ODBC+FreeTDS. Hence, we'll write a good-old C# binary with a Microsoft-blessed driver to expose the few ad-hoc queries our own team needs rather than a generic solution for the whole company and we'll move on. In short, I have some data invalidating your argument about the PostgREST code style being indefensible. Although I don't enjoy PostgREST codebase I love the product because it delivers what the website claims. Rather than diminishing the hard work of devs using a throwaway/slandering account, I just reckon that Haskell and "ship it culture" are reconcilable.

[Apaec]

I also did something similar to postgREST for MSSQL in java, not in haskell because of the same driver issues you mentioned. I managed to implement jwt auth pgREST style taking advantage of MSSQL user impersonation though I did jumped into some limitations, for example the lack of enviroment variables in transaction scope in MSSQL forces you to have to declare one db user for an app user.

I have little experience in Haskell despite that it was easy for me to understand the gist of what postgREST does and port it to java.

[mst]

ODBC+FreeTDS is not generally a good idea. Microsoft's ODBC driver works fine though.

https://blog.afoolishmanifesto.com/posts/install-and-configu... explains how to get it going on debian.