erd VS esqueleto

I like it and the comparison site on https://text-to-diagram.com

I just wanted to drop a reference to Burnt Sushi's ERD tool [0]. It only does one diagram type: Entity Relationship Diagram. It's wonderful. Human-first syntax, code comments, and some simple formatting settings like colors and font sizes that help make more complex diagram pleasing and informative.

[0] https://github.com/BurntSushi/erd

Only tool I've come across is erd but have not personally used it. We use LucidChart for our ERDs at work. They have an API to export to PNG and to create documents within it. The documentation for the API is dense, but it is something I am hoping to take a hack day or two to try to understand and see if I can automate generating and updating our own ERDs.

Writing Haskell programs that rely on third-party packages is still an issue when it’s a not actively maintained package. They get out of date with the base library (Haskell’s standard library), and you might see yourself in a situation where you need to downgrade to an older version. This is not exclusive to Haskell, but it happens more often than I’d like to assume. However, if you only rely on known well-maintained libraries/frameworks such as Aeson, Squeleto, Yesod, and Parsec, to name a few, it’s unlikely you will face troubles at all, you just need to be more mindful of what you add as a dependency. There’s stackage.org now, a repository that works with Stack, providing a set of packages that are proven to work well together and help us to have reproducible builds in a more manageable way—not the solution for all the cases but it’s good to have it as an option.

However, we can use Esqueleto (”a bare bones, type-safe EDSL for SQL queries”) with Persistent's serialization to write type-safe SQL queries. It’s unlikely that you want to use Persistent by itself with SQL, so let’s use and review them together.

Postgresql-simple is a great library, it makes a nice use of overloaded strings to do the job. Some other nice libraries to keep an eye on are opaleye (postgres specific, which is equally nice but could be a bit difficult to get why the types are so big) and a combination of persistent (not DB specific! can work on postgres, sqlite, but also noSQL DBs like mongo, it's still easy to learn but you lose some things, such as joins due to the power of being agnostic) + esqueleto for type safe joins (be sure to look up the experimental package, it's a more comfortable syntax that will soon become the default one).

Using esqueleto in one of my haskell projects was a huge time sink and a major barrier to entry for colleagues.

In Haskell: https://hackage.haskell.org/package/esqueleto

Either it analyzes the given SQL to determine the in/out types of each SQL query, or it calls the database describe feature at compile-time.