I am doing a reverse migration from a reactive web app to a traditional web.
I tried to import the reactive web app module into the traditional web. But there are some modules that cannot be imported (eg: Screen, Block, Resource, ...). However, there are still some modules that can be imported (eg: Server Action).
So I am wondering if there is any impact when still using the reactive web app module in the traditional web?
hi @Ha Duc Phuoc , hope you are doing well.
reactive and traditional are different although they share the same platform and service studio.so your traditional app will work fine if you only consume server-side logic, data models, and static entities from the reactive module. but you cannot reuse UI or client-side logic from reactive modules. if you try you will end up with broken references or runtime errors.This means any UI needs to be rebuilt in the Traditional app (screen, blocks, etc.).
what you can try is :
you can use reactive modules in traditional web only for backend logic and data, there won't be any impact there; but UI elements must be rebuilt.
hope it helps.thanks and regards!
Hi @Wahaj Adil
Thanks for your feedback. I will try your suggestion.
you're welcome. @Ha Duc Phuoc let me know if you need further assistance.
Using Reactive Web App modules in a Traditional Web application during a reverse migration process introduces several challenges and limitations due to the fundamental differences between these frameworks. Here are the primary impacts:
Compatibility Issues: Reactive Web uses a client-side framework powered by React.js, which operates differently from the server-side rendering architecture of Traditional Web Reactive web overview and best practices. Mixing the two can lead to inconsistencies in how data and UI updates are handled.
No Client-Side Features: Reactive Web offers features like client-side events, client variables, and asynchronous data fetching, which are unavailable in Traditional Web. These features will not function or will need to be re-engineered if the modules are used in a Traditional Web application Traditional to Reactive App migration reference.
UI and Functional Mismatches: UI elements and patterns specific to Reactive Apps may need to be rebuilt, as Reactive Web components (using modern libraries) are not natively compatible with Traditional Web's UI widgets Reactive web overview and best practices.
Performance Challenges: The way Reactive Web processes and renders UI elements can introduce inefficiencies when integrated into a Traditional Web context, as the latter relies entirely on synchronous server-side interactions for rendering and data management.
No Reverse Support for Session Variables: Traditional Web relies on session variables to maintain state, while Reactive Web uses client variables stored on the browser. This discrepancy needs to be addressed during the reverse migration, especially for features requiring state management Reactive web overview and best practices.
Security Considerations: Client-side logic in Reactive Web can expose sensitive operations and data when used improperly. If elements are used in a Traditional Web environment without adequate safeguards, application security might be compromised Traditional to Reactive App migration reference.
Given these differences, attempting such a reverse migration may lead to significant redevelopment effort. If possible, it's better to refactor and rebuild the functionality entirely in the Traditional Web paradigm rather than attempting to reuse Reactive Web modules.
Hi,
It is perfectly possible to mix Traditional and Reactive apps, and it is also possible to consume Server Actions from a Reactive module in a Traditional module. It is also possible to redirect from a Traditional Screen to a Reactive Screen and vice versa (e.g. via menu). Also the login persists between Traditional and Reactive.
Of course, one would typically have a Traditional factory and move to a Reactive one, instead of vice versa, but mixing Traditional and Reactive is the same for both situations.