digitallyinduced / ihp

🔥 The fastest way to build type safe web apps. IHP is a new batteries-included web framework optimized for longterm productivity and programmer happiness
https://ihp.digitallyinduced.com/
MIT License
4.9k stars 194 forks source link

Subscribe to email link is broken in the README + a typed SQL question #1467

Closed benjamin-thomas closed 2 years ago

benjamin-thomas commented 2 years ago

This link is broken: "subscribe to the IHP release emails"


Just having a quick look at your framework this morning by following along the "first-project" tutorial, wow wow wow!!

Very appealing for someone discovering Haskell (it feels very nice and logical coming from a rails background).

I see you mention in your docs the necessity to revert to writing raw SQL queries once a complexity threshold has been reached.

Have you considered integrating this library into IHP? https://github.com/dylex/postgresql-typed

I evaluated it a few days ago in a simple demo here

I'm considering changing tools/language to introduce as much type safety as possible and improve my productivity. That's how I stumbled upon your framework btw.

mpscholten commented 2 years ago

Really happy to hear you like it :)

Thanks 👍 Just updated the link.

Yes, we've discussed the idea of having typesafe sql at several IHP meetups in the past. We'd likely not use postgresql-typed directly, because that needs to connect to the database directly. Instead we'd parse the Schema.sql and manually type check against it. So it's likely we'll have this in the future 👍

I'm considering changing tools/language to introduce as much type safety as possible and improve my productivity. That's how I stumbled upon your framework btw.

Good choice 💯

benjamin-thomas commented 2 years ago

Subscribed!

Instead we'd parse the Schema.sql and manually type check against it. So it's likely we'll have this in the future

I'm drooling ;)

If you're interested in additional input, I've been learning Rust by following along this book: https://www.zero2prod.com

Here the author recommends using a (great) typesafe SQL library called "sqlx": https://github.com/launchbadge/sqlx

Sqlx does require having a database connection to type check queries in dev mode (like postgresql-typed), but also has the ability to export the schema and use that instead. More info at the bottom of this section: https://github.com/launchbadge/sqlx#compile-time-verification

Maybe their solution could serve as inspiration to you.

If you want to play with this tech, you can have a look at my implementation of the book's tutorial here: https://github.com/benjamin-thomas/zero2prod

I'm half-way through and diverged a little from the book though. The dev env is docker-based so it should be pretty painless to setup.

Have a great weekend :)

mpscholten commented 2 years ago

Thanks for sharing 👍 Looking into it right now :)

Thanks and have a great weekend as well!

benjamin-thomas commented 2 years ago

Since I see you're into code generation, I'll submit one more.

Another approach to get type safety is to write SQL queries in a file (+1 for readability), then have a parser transform the queries into the target language dialect (into functions basically).

That's the approach taken by this golang library: https://github.com/jschaf/pggen. A DB connection is required at this compilation step though, to validate the sourced SQL statements are correct (check column exists, extract db type info, etc.).

I don't have a project to share with this one, but I've been using it for a work project and I'd say it's worth a look.

I does make dev workflow more complicated though.

Keep up the great work :)

mpscholten commented 2 years ago

Interesting idea 👍 Reminds me a bit of certain GraphQL libraries that follow a similiar path of writing the query in a different file.

I agree that this could be more readable, especially for larger queries. On the other hand the inline sql seems easier to use and the code is more located at it's usage site vs being located in a separate file.

I'll keep this in mind when we're implementing this. Maybe we can give both variants a try and see what works better in practise.