@dhruv1 So here's a long-winded answer

I mean @dhruv1

The question I always ask about any tool is: What value does it provide me in this situation?

For Component, the short answer is: It provides dependency injection and lifecycle management.

Lifecycle management is obvious, and it doesn't appear that's your primary concern. (Though I will point out that you could create a resource pool for accessing App-B, and then you would need lifecycle management. This isn't necessarily a good idea, but it's not necessarily a poor one either.)

The main benefit of dependency injection is: Flexibility.

You can dynamically configure how an interaction will occur at runtime.

So back to your scenario:

Idea1: You've created a component that, I'm assuming, implements some protocol, and that can be swapped out with another implementation at any time.

Idea2: You've created an implementation-dependent interaction. My-App now must know 1) there exists a string that is a URL to App-B, and 2) that string is contained in an atom.

My take is: If you're going to use a dependency injection scheme, make sure you're getting the full benefit from it. As far as I can tell Idea1 provides more flexibility than Idea2.

That's not to say that you must use a dependency injection scheme. Some apps don't warrant that level of flexibility.

And I'm not sure what your use-case is.

But, if you don't need that level of flexibility, I would do the absolute easiest thing: (defonce url "http://...")

I should note that, in a professional setting, I would always opt for dependency injection. Most professional-grade applications have such a long lifespan that flexibility is key to longterm success.

One last observation: For Idea1, you don't seem to need lifecycle management at all as it stands. I would just construct the record with a url (map->App-B {:url "http://..."}) and then mark it as a dependency of My-App. I don't see what benefit associng/dissocing the url provides.