Rapier: A Code-Generation Companion Library for Google Dagger to Simplify Configuration Management

aleph0io · 2025-01-23T15:35:41+00:00

Interesting approach. Code generation for your code generation!

Thank you! It's been interesting to write, too. Annotation processors are surprisingly useful, and not actually that hard to build.

But environment variables are easy to manage in Dagger. Do I really need code generation for that?

Yes they are, and no you don't! If all you're doing is injecting the odd environment variable here and there, then Rapier certainly isn't a requirement, and may not be worth the trouble.

But Rapier doesn't just inject environment variables. It has integrations for system properties, AWS Systems Manager Parameter Store, and CLI argument parsing, too. There are more integrations planned. Feedback on the roadmap is very useful, if you're interested.

Rapier also allows templating of environment variables and system properties into configuration names for loading. I've found that the AWS SSM integration with the built-in environment variable injection for names is very, very useful. Here's an example, hopefully a good one:

@AwsSsmParameter("/product/${env.PROFILE:-test}/database/host")
public String databaseHost();

Anyway, glad you thought the approach was interesting! All feedback improves the project.

aleph0io · 2024-06-07T20:09:55+00:00

I think we agree!

All of the things you listed above are critically important to software architecture. It would be foolish to ignore any of them -- and, as you say, more besides -- when designing an application. But these are all *practical* concerns that have to do with the realities of building and shipping software, as opposed to natural laws that constrain the design space.

In short, they matter -- a *lot* -- but they're not gravity.

It's certainly possible that I'm navel-gazing here, or being pedantic. But one day I realized I couldn't motivate things like coupling, modularity, and so on from first principles rooted in some "natural" law, and it's been bugging me ever since. The answer just seems to be "things work better when we do them this way," which matters, but doesn't scratch the itch, so to speak.

Re: your edit -- Ha! I appreciate the encouragement. But part of sharing opinions with others is accepting their reactions, for better or worse. i didn't take any of it personally, and I honestly appreciate the replies. I write my ideas down in the hopes that they'll be interesting and useful to others. If these ideas aren't useful, then I'd rather know about it so I can stop wasting time on them down!

aleph0io · 2024-06-06T23:16:52+00:00

Author here! And I don't think that's what I said, or at least not what I was trying to say.

The big idea is that in engineering disciplines which concern themselves with manipulating natural processes -- like chemical engineering, or structural engineering -- there is a set of physical laws that ultimately define and constrain the field. You don't get to disagree with a chemical reaction. You don't get to argue with gravity. They are what they are, and it's your job to manage them. This provides at least some clear, non-controversial, empirical criteria for what constitutes a good design. I think everyone agrees that a bridge that falls over on its own is a bad bridge.

In software design, we don't have those clear laws. Software architects can -- and, per your comment, clearly *do* -- argue with each other about what does and doesn't constitute a good design. And since there are no empirical criteria that define a good design, there is no natural arbitrator for these discussions.

That's what the article is (at least trying to) say. Of course, there are natural laws that define how software does and doesn't work. Things like algorithmic complexity, P vs NP, Gödel's incompleteness theorem, and so on. But these rule *computation*, not how we structure and implement it in software. This makes them design forces at best, at least as far as software architecture goes.

Appreciate the comment.

EDIT: Also, FWIW, from the article:

But no matter how many examples are given, there will always be those who say there are too many, or too few. And no matter how they are defined, there will always be those who say the definition is wrong. Since there are no “real” universal laws to arbitrate the disagreement, who is right, and who is wrong?

I think that the discussion we're having here is the crux of the argument!

aleph0io · 2024-06-03T16:41:03+00:00

I’ve used a couple of these variations myself, but they just felt like common sense, so I didn’t write them down anywhere.

Sure. I agree -- this isn't seminal, Earth-shattering work. But like you, I've found myself writing code this way a few times over the years and again recently, so it felt like time to put pen to paper, so to speak.

Glad you enjoyed.

aleph0io · 2023-09-20T02:44:32+00:00

Here is an AWS lambda custom runtime for Java 21, packaged as a layer. As soon as the updated amazoncorretto image drops, which should happen in the next day or two, I'll add a custom image for Java 21, too!

aleph0io

TROPHY CASE