I’d like to take a stab at convincing you that this is much more powerful and much less shameful than it apparently appears to you at the moment.
You’ve got me beat in terms of programming experience, but only by a couple years or so, so I am also very steeped in decades of imperative thinking, and the way you describe the component “asking” the service something is very telling.
Trying to write webapps with an imperative mindset was for me a very frustrating experience. It always felt like I was fighting the framework. I found ReactiveX a confusing katamari of obscure tools, most of which seemed of at best academic interest, so I glommed onto a couple of them, made recipes, and deployed those religiously.
At some point, I decided this was not working at all, and that I had to fundamentally change the way I was thinking about things. Webapps are fundamentally reactive programs - they sit there, wait for users to interact with them, and respond to that interaction. That’s super-hard to debug at first, because I the programmer am no longer in charge of the code execution paths. I had to let that go, and trust that functional thinking could help me isolate parts of my app from one another, enabling them to be viewed and tested as distinct entities.
So, while there’s absolutely nothing wrong with what you’re doing with @Input bindings, realize that it has fundamental limitations as long as you’re slinging scalars around, and that much of Angular’s power comes from its ability to wire Observables up.
With that introduction, when you get a chance, please check out this post for a reactive strategy that automatically delivers fresh data to components exactly when they need it, and only then.
Incidentally, if you’re still reading, I would suggest using ngOnChanges instead of ngAfterContentInit for similar reasons - you have the same guarantee that the data is fresh, and you won’t miss updates that ngAfterContentInit would.