Is it possible to duplicate application into another totally new application ?

TakadaGuna

Hello,
Is there any way to duplicate an application as a totally separate application ? For example I want to have two applications: one application is a product catalog for company A, and one application is a product catalog for company B. Most of the tables would be similar, but some minor things are different, so I want to develop the apps separately after a certain point of development. But I don't want to build from scratch every time.

Thank you in advance. Appreciate this platform very much.

gabriel

Hello Takada,

Unfortunately a function like this does not exist at the moment. You can "fork" your app, meaning you can continue to work on different versions of your app; this works but has the downside that you can never install both apps on the same R3 instance.

But for this particular use case, I think another approach might even be better. You can build a base application, that contains all the common elements of your product catalog and then build 2 new apps on top of it. Then the 2 "child" applications extend the relations of the common base application with specific attributes / user interfaces.

This would have the benefit that you can add things to either the base (if both child applications need it) or to either child application if its specific. This is what we did with our Asset Base and Asset IT apps - Asset Base contains general product information that every other asset app would need and then Asset IT is one possible child app that builds on top of it.

Maybe this is a solution for your use case as well.

Florian

Well, the logs say (just for completeness' sake, and naturally not news to you):

 import of module '...' not required, same or newer version (5 -> 5) installed

So I cannot re-import the app as REI3 realizes that it's the very same app despite a different name.

I guess from my beginner's standpoint it would make sense to be able to copy apps as that would allow for having a template (with relations and forms for contacts, schools, and items, for example) and then creating forks for different use cases (parts to be shared among lab assistants, teaching material to be shared among teachers etc.). But I can see that my reasoning is more based on having small, separate apps in mind rather than having more complex structures with interlinked apps for one big use case running on an instance like you provide in your repo.

Or maybe I just haven't sufficiently understood app dependencies yet. Am I right in saying that those dependencies are meant to extend functionality across and enable data sharing between apps, rather than to allow for building separate apps with similar structures (kind of like having a template and forking functionality by somehow layering differences like different text patterns for form fields on top of it)?

gabriel But for this particular use case, I think another approach might even be better. You can build a base application, that contains all the common elements of your product catalog and then build 2 new apps on top of it. Then the 2 "child" applications extend the relations of the common base application with specific attributes / user interfaces.

If I understand this correctly, that would allow for development of both apps in the same instance. But since the two apps are meant for different companies, the two child apps have to be installed on different production sites because otherwise the data in the parent app's relations would be shared among both companies, right?

Gouds

Would be great to be able to run multiple of the same applications on the same server (Rename). Being able to clone and update the sub apps (clones) as the master repo updates. Much like the repo version control. Looking to have a single server instance (or cluster) but run containerized separate databases based off of a mater repo. Then as new features are published you could then update the separate databases based off the master repo and keep the client data separate. Exactly like you have now but multiple of the same on the one server.

Little of topic but would be handy in my instance. (Extending the above)

gabriel

Gouds
Unfortunately, this feature is far off with the current architecture of R3.

For our purposes, we run multiple R3 services on the same system, with each taking up very little memory (50-150mb) depending on what apps are installed. This way we can offer different apps/versions and can choose to update from a repo or not for specific use cases. For this the command line parameter servicename comes in handy - with it you can register multiple R3 services under different names in the same operating system.

Florian

Would this be an option for cloning an app?

Create app A and export it.
Rename the app to B.
Import the app as A again.

gabriel

Florian
Sorry, that would not work due to how we reference entities in r3 app schemas.

For an example of why this is hard, form duplication (which does something similar) takes hundreds of lines of code to find and replace references. And this is only for forms with limited complexity. And we need to update this logic every time we make changes to forms, attributes, and so on.

It is technically possible - but it would require weeks of work, probably a couple new solutions and likely a load of technical dept - where we have all this complexity and need to keep updating this anytime we change something.

The benefit of this are also slim, in my view. While it can be useful, in most cases people want to extend and not copy apps. If they copy apps, they loose all upgrade-options in the future, needing to support their apps forever themselves from that point onwards. I personally would prefer to work on solutions to make extending apps easier or more powerful, instead of working on app-duplication.

Florian

I apologize for coming back to my question as I probably don't understand the answer correctly.

Wouldn't a re-import of the app work like any other app import? I would then expect the two apps A and B to be fully independent. The benefit would be that one could create a template for similar but independent apps, e.g. where only minor tweaks like descriptions are necessary.

Do you maybe describe the effort to keep both apps in sync somehow after re-importing? Otherwise I just don't see the difference between this and any other import of an app, but also don't dare trying it on my instance if you say that wouldn't work.

gabriel

Florian Do you maybe describe the effort to keep both apps in sync somehow after re-importing? Otherwise I just don't see the difference between this and any other import of an app, but also don't dare trying it on my instance if you say that wouldn't work.

Nope, this would be the effort to enable the import of a 2nd version of an existing app. 🙂
The very short version: We use UUIDs for cross-reference and caching purposes. If you import a 2nd app, you need to replace all UUIDs and all references to those UUIDs in all entities (forms, fields, attributes, menus, icons, etc.) - because each UUID may never ever exist twice in the same instance.

But please, try it out 😉
You can export the same app with a different name and see if you can re-import it into an instance where the original app already exists.

gabriel

Florian I guess from my beginner's standpoint it would make sense to be able to copy apps as that would allow for having a template (with relations and forms for contacts, schools, and items, for example) and then creating forks for different use cases (parts to be shared among lab assistants, teaching material to be shared among teachers etc.). But I can see that my reasoning is more based on having small, separate apps in mind rather than having more complex structures with interlinked apps for one big use case running on an instance like you provide in your repo.

Even in this use case, building a base app that contains contacts, schools and items could be a much better idea.
Not only would you not need to re-implement all relevant relations, forms, logic, processing, access policies - you would also have synergies. If I use multiple apps that use the same base, I do not need to re-import all contacts or items - they would be there already.

Even if you need to separate access to specific records between apps, you can still use the same base relations, by defining separation criteria and filtering.

Florian If I understand this correctly, that would allow for development of both apps in the same instance. But since the two apps are meant for different companies, the two child apps have to be installed on different production sites because otherwise the data in the parent app's relations would be shared among both companies, right?

Why would the two apps be meant for different companies? I am confused 😅

Accessing the same base app between multiple dependent apps serves to centralize data / access / UI. It really does not have anything to do for whom an app is written. It is just a question about if it make sense to build centralized "buckets" of data / functionality. Why build 6 contact relations (and their UIs etc.) in various apps, if they are 99% identical and could benefit from using similar processing, APIs and so on.

Separating stuff into apps makes it modular, which of course also has some drawbacks, such as having to define the separation between apps - which can be tricky in some cases. It also requires thinking about access. But it can reduce redundancy, enable centralized features and is usually much easier to maintain.

Florian

Thanks for your detailed explanations! I actually now followed your suggestions and have built two apps on top of a shared Contacts app.

gabriel Why would the two apps be meant for different companies?

Here, I just referred to the original question (as I understood it)...