Reactive Apps - Architecture

Hi guys,

I'm entering on Reactive Apps development and I have some doubts.
As far I could check, reactive apps are pretty similar to mobile apps, but I would like to know if the reactive apps architecture is also similar to mobile apps architecure, which mean, that we only going to have one UI module that will have all the screens.
Ex:
                   Module_UI
  ModuleA_CW      ModuleB_CW

Or

If the reactive apps architecture are similar to traditional web, 4 Layer Canvas.
What is the best way to go from a screen that is in Module A to a screen that is in Module B?
Ex:
  ModuleA_UI      ModuleB_UI

  ModuleA_CW    ModuleB_CW 


Which one is the best reactive app architecture approach?

Thanks in advance,
Diogo Miguel

Hello Diogo,

You can set the screen with the property Public = Yes call add the dependency on the consumer. 

Since this is a weak dependency you don't break any architecture rule.

Please see more information here and here about this topic.

In the second link you can also see this dependency as an example:


No impact on Consumer: The changes you performed in the producer causes no impact on the consumer module at runtime and the consumer immediately starts using your latest implementation. Example: Changing the content of a WebScreen (weak dependency) with no changes to its signature.


BR,

Luis

Hi Luís,

Thank you for the reply.
Thats what I thought, since the screen it's a weak reference we can reference it from Module A on Module B without problem.

But now I have another doubt, in case that I want to go from ModuleA_UI to ModuleB_UI and from ModuleB_UI to ModuleA_UI:
What is the best way to do it? Use only one UI? Use the GetEntryURL() server action to redirect for each module?

Best Regards,
Diogo Miguel 

Solution

Hello Miguel,

The best way to achieve that is to use the External Site widget and redirect to a specific URL.

Although it is a weak dependency, you should avoid screen destinations that imply side references between different End-User modules and use External URLs instead. This way you'll avoid direct references between these modules (in your scenario ModuleA_UI and ModuleB_UI) that could lead into side references (or cyclic, in your case).


Just create a RedirectToURL external site in your flow with an URL text input parameter and use it to execute the navigation. You should after define the On Click event of your link to this RedirectToURL destination and specificy the URL: "/<module's name>/<screen's name>"


Kind regards,

Rui Barradas

Solution

Hello Rui,

Thank you for the reply.
I thought doing that it wasn't a good pratice because of the danger that is put something hardcoded.

Best Regards,
Diogo Miguel

Hi, again Diogo,

In reactive you don't need to do that workaround. 

Since the screen references are weak references, you don't make a "cyclic reference" violation.

I made a test with your example and you can see here on Discovery that doesn't have any validation issue. Also, the producer module is in a light color because it is a weak reference:

Also see this release note on Discovery (version 5.0.6) here: https://www.outsystems.com/forge/component-versions/409

Release Notes for 5.0.6, OutSystems 11:

  • Reviewed the cyclic references: now screens don’t raise this issue but entities and structures continue to raise.

At Service Center, you can see that the Modules A and B are OK and don't have any warning about "Outdated dependency":


Hi all,

It is indeed true that screen references are weak references. Still, the reference is there, even though it is not considered as a violation.

Anyway, as far as I could find in documentation, OutSystems promotes loose coupling.


One way that OutSystems suggests to promote loose coupling is precisely to avoid screen destinations and use external URLs instead (both for reactive and traditional apps).

I was just suggesting what I read in OutSystems documentation :) but of course, there are other viable ways.


Kind regards,

Rui Barradas

Traditional. Reactive or Mobile follow the same patterns. It is more a mentality issue than a platform issue.

On all of the latest User Groups regarding Architecture Dashboard and 4 Layer Canvas, it was stated that links are weak references, therefore they won't cause issues. That change caused the end of the 4th layer in 4LC

It has been like this for about half a year, but documentation is still referencing it because changing everything without an explanation would cause more confusion than having an official answer and an unofficial answer and inform people little by little.

I wouldn't use an external URL unless it is the only option.