Hello @Darya_Verzhbinsky,
I'm glad you asked! 
It's a bit of architecture that has evolved from the limitations of modules, so I'd be happy to elaborate. I'm currently using an iFrame within my main app that leverages a dynamic URL. By changing the path along with a couple of hashtags, I can asynchronously load content from specific modules in the background. Then, I simply toggle its visibility to make it seem like it's instantly loaded.
Doing this the old-fashioned way would introduce numerous issues in terms of scalability and performance. Inserting separate modules would mean managing multiple components and their individual visibility, along with the fact that each module gets initiated before I have requested it to do so. This last part is particularly important, considering modules have their own queries that all start executing unless I provide some active output value—but this comes with trade-offs.
In my current setup, all I need to do is decide on a naming convention and then adjust the iFrame's source URL to get the relevant content. Better yet, when the hashtag in these iFrame sources is adjusted, the page doesn’t fully reload but instead updates dynamically based on the hashtag values.
I've found this technique to work quite well, even though it may not be something you’d recommend in the documentation. That said, I do think there are a couple of takeaways for those developing and improving modules in Retool:
- If there were a way to dynamically load specific modules, that would be quite convenient.
- If any module could be loaded asynchronously—only when it's visible—it could also provide a performance boost.
Again, I'm trying to minimize the number of components and queries, as your docs mention that this affects performance. I'm using modules in the first place for this exact reason and to provide better namespacing.
Hope this helps give you an idea of how I’m leveraging module URLs.
