ROS 2 nodes created inside libraries, good practice?
In porting stuff to ROS2, I'm often faced with the problem of what to do with calls to the ROS api that are deep inside libraries. In ROS1, since a node and process when one to one, you could always make a new NodeHandle and wait for a message, call a service, etc anywhere you want.
You can largely do the same thing in ROS2 by creating (and destroying) a new rclcpp::Node on-the-fly in your library and then running a separate executor to get callbacks processed. Is this a good idea? Assuming it isn't doing this in a tight loop, is it likely to cause conflicts or other issues? Does it make sense to architect systems with ephemeral nodes?
I can't speak to whether or not this is good architecture, but my hunch is that this is a good option for very infrequent ROS API calls only - how would you be using the API if I may ask?
It could vary, so I'm interested in what factors to make the decision on. On one end, it might be something like an object that stays alive the whole time and manages it's own publishers/subscribers. On the other end, it could be simply subscribing and obtaining a single message or doing a single service call.
Apologies for the late reply - but I think this page touches on this topic a little bit. https://docs.ros.org/en/galactic/Conc...