Boilerplate in Three Ways
In an odd congruency, we have three projects announcing releases within a few days of each other: scythe, fluent-repo-4j, and spring-crud-generator. They each have different scopes and purposes, but they all start with the same basic premise: generation of code.
Scythe: SQL is the System of Record for Schema
Scythe is a Rust project that accepts SQL as the basis of truth for a dataset, and generates a schema and code to interact with it for multiple databases and languages. It uses a linter for the SQL to reason about what the schema should look like based on the way it's used, which is a fascinating application of "user story" - it's using "how do you use the data" as the definition of a story and generating code for it, both for the schema (the DDL) and for whatever language backend is chosen, so you can use the SQL to generate code for Java, Rust, Typescript, Kotlin, Python, Go, and more.
spring-crud-generator: OpenAPI from a different view
spring-crud-generator takes a different approach. With this project, you create a configuration in YAML to describe an entity model, and the project creates a scaffolding around it, including tests, endpoints, caching configurations, various database configurations, even GraphQL and OpenAPI inputs.
It looks a lot like openapi-generator, with the core difference being that openapi-generator focuses on web services at the specification level; spring-crud-generator uses the entity model as the basis for the specification.
fluent-repo-4j: Spring Data JDBC without DDD
fluent-repo-4j is the standout here, based on its design and requirements: it's the least scaffolding-like of the three projects, because what it replaces is Spring Data JDBC. It's billed as "type-safe, declarative database queries without ORM overhead" - which may be true, but it's not unique even among the projects under Spring's formal umbrella; Spring Data JDBC is also without "ORM overhead," but one thing that does differentiate fluent-repo-4j is that it treats aggregates differently than Spring Data does.
This isn't a small thing; Spring Data uses a common aggregate model across its projects where it can, which can be good or bad, but it requires thinking about data as Spring Data does. Aggregate updates and reads can be expensive, because Spring Data acts like an ORM in places even if it's not one; you may not have to think of JPA managed entities the same way while using Spring Data MongoDB or Spring Data JDBC, but the design decisions from JPA still affect some operations.
Along the way, you get some paradigms more useful for functional programming that Spring Data usually provides; Spring has reactive programming models, of course, but fluent-repo-4j's models may be more appropriate for some users.
What It Means
These are all interesting projects and may be awesome. They certainly look like they could work, although spring-crud-generator calls to mind projects like FabriKt and openapi-generator, projects which "work" but use scare quotes rather deliberately (and generously).
The main thing that stood out was the timing: they're all based around the same idea of shortening the execution path from specification to implementation, all based on database access stories. It's an odd congruence that bears watching.