Hi, are there any good example of http4-based appl...

# http4k

[Marco Garofalo]

Hi, are there any good example of http4-based applications that showcase interactions with a database leveraging jdbc or jpa (ideally with repositories, entities, etc)?

[Cosmin Marginean]

We've ended up writing our own persistence / repository-pattern components, which I can't share, but it's very little code. We've explored Komapper, Ktorm, JetBrains Exposed, and Hibernate JPA.

We've settled (for now) on Komapper because it seemed the least intrusive in our data model (Komapper annotations only, which I'm not a fan of, but it was the lesser evil). Komapper also uses KSP to generate meta model at compile time, which I'd rather avoid, but it's not possible yet.

One thing to keep in mind is that Hibernate doesn't work well with data classes (https://kotlinexpertise.com/hibernate-with-kotlin-spring-boot/), which was a big stumbling block for us because we definitely want data classes, and engineers will eventually be tempted to use equals/hashcode unaware of the hibernate issues with it.

In short, we found the ORM world for Kotlin to be lagging, with most Kotlin libs trying to be both an ORM and Flyway, which intrudes on the design. While traditional (hibernate) solutions don't fit as well in Kotlin apps.

[dave]

We don't really have examples with ORMs etc because TBH there's not really much they can bring over the examples that should already be in the specific data access projects. You might find the hexagonal examples like this one or this one useful but they are more about system design with ports and adapters rather than specifics of library interaction

[Marco Garofalo]

Thanks for sharing guys, the reason why I was asking is that most of my experience is on spring-boot based applications, and is quite easy to jump on either jdbc or jpa to fulfil persistence needs, but I do understand that http4k is positioned more like a toolkit rather than a framework, so I guess the gap is to be expected. That said it would be nice to get some opinionated example in the docs.

[Andrew O'Hara]

My only JDBC examples are for legacy proprietary applications, but here's one that uses DynamoDB. With good system architecture, a repository isn't anything special. It's just another framework-agnostic dependency to be injected.

https://github.com/oharaandrew314/ribbit/tree/master/api

It can be jarring to learn how to work with repositories outside of an opinionated framework. Spring encourages you to mix service code with transaction logic whereas a hexagonal architecture would call for a cohesive repository that manages its own transactions.

[Marco Garofalo]

Thanks @Andrew O'Hara I’ll have a look, I don’t have any problem on the DDD/Separation-of-concerns side of things, I typically decouple my domain from the adapters, but outside of spring/spring-boot I can see there is Exposed (not yet v1.0) and few other libraries for persistence, so I am trying to understand what’s what, don’t want to come up with lots of boilerplate or re-invent the wheel, does that make sense?

[Andrew O'Hara]

No library is going to make you reinvent the wheel; they're usually designed the way they are for good reason. If you're looking for library suggestions:

• Exposed: the fact it's pre 1.0 is of little consequence; many people use it and love it. It's typesafe and very powerful. The higher-level DAO-layer can suffer from some of the hibernate-esque performance problems
• SqlDelight: Kind of a reverse-ORM; write the SQL to generate the interface and models. Wonderful to use, but as a android-"first" library, it doesn't always have the power you need for complicated queries
• JDBC: don't underestimate the power of this low-level interface. You're not reinventing the wheel if your goal is to get the most performant and efficient repository possible, but it requires good test coverage due to it's weak safety
• Komapper: haven't tried it but people like it
• Ktorm: haven't tried it but people like it
• jOOQ: Java-first, and haven't tried it, but still very popular in the Kotlin community

[dave]

Personally I think jooq is ace. It's a very good SQL substitute. ORMs are ORMs - handy but you can get bitten though and have to drop down to SQL. Personally I like having the control there so default to that 🙂

[fredrik.nordin]

Another happy user of Komapper here. If you want something closer to JDBC and SQL but with some more powah, have a look at JDBI, which has had kotlin support for a while now.

[MrNiamh]

I agree with Jooq, not to mention they have a kotlin generator now, so it doesn't feel java-y at all

[Marco Garofalo]

BTW I ended up using JOOQ as well, I find it quite interesting since if you know SQL you know JOOQ basically, and with the generator It’s also typesafe, added flyway migration+jooq code gen plugins and it works like a charm.