Imagine we have a weweb application that has 10 screens. The following are 2 ways I know of to build the interface in WeWeb. Would you expect there to be any observed or demonstrable performance differences between these 2 approaches? (Assume in all cases, data for each screen is fetched as needed, and not all at once).
Approach A: Build all screens as conditionally rendered Sections on a single weweb page. A variable determines which section (or screen) is displayed at any given time, giving the user of navigating through âpagesâ in the app.
Approach B: Build all screens as separate pages in web, and âlinkâ them with a multi-page section. As far as I know, weweb renders these as a single page vueJS app.
Are there any best practices we should be aware of regarding this topic?
If you are using âPrivate accessâ, Approach A is much faster, and you can achieve quite instant loading.
The reason is that when loading a new page (Approach B) weweb is contacting backend to verify user group and access, and blocking loading while waiting for response. How long this takes, is depending on your location, as Weweb only has a server in USA, for me that means around the world and is SLOW.
You can bypass this with on page workflows. Also I âd rather shoot myself in a foot than do 10 pages web app on one page. It would be a mess no matter how hard you try.
Thanks @thomlov and @Broberto for contributing to this conversation. @Broberto, Could you please elaborate on what you mean by âyou can bypass this with on page workflowsâ (maybe with an example)? Also, I really appreciate you sharing your very strong opinion (ârather shoot myself in the footâ - LOL). Can you elaborate on what would be a mess no matter how hard you tried? @joyce@flo Any opinions on this?
Instead of using Wewebâs own private page system, you can instead check for correct access yourself. Then it becomes non-blocking. Backside is that any static content will load, and show to the user even if the user does not have access. I believe that is what Broberto is refering to?
Iâm successfully using a combination of Approach A and B, and using a variable to define what page is visible. You have to manage loading of collections yourself, within your logic, but other than that it is not a mess for me at least.
From the situation you proposed making a logic of 10 pages in one single page, with workflows and conditional rendering means having 10 pages of bindings/variables interlacing on a page, which adds a certain complexity. As for the Workflows, you can check on page/app load the userâs state, eliminating the need for the WeWebâs private pages setup - which is known to cause issues as @thomlov pointed in his answer, due to the fact that WeWeb needs to double check against your rule.
This also can be handled if you want it to be smooth, e.g. the flash of content can be solved with the conditional rendering as well. Itâs just some more work.
Thanks guys. @raydeck What do you think about dedicating an Office Hours session to this topic/discussion (or maybe a special event)? Attendees (hopefully including @Broberto and @thomlov) could maybe show examples of how theyâve handled this issue. This feels like such an important issue, and it would be great to get that discussion recorded (as you always do) to serve as an ongoing asset to new & existing members of the StateChange community.
Apologies to the weweb community members who are not StateChange members. I posted this discussions in both communities and I forgot which one I was responding in
I would definitely go with approach B, much easier to scale and maintain in my opinion.
FYI, the performance limitations to this approach when using private pages will soon be lifted because weâre making changes to how we handle those. (Canât give an ETA yet but dev work is in progress and performance will be greatly improved worldwide)
In the meantime, as @Broberto mentioned, you could use workflows on page load to implement private pages (redirecting unauthenticated and/or unauthorized users to another page) without using WeWebâs built-in private page feature.
@Broberto When you say check the userâs state you mean check to see if theyâre authenticated, and if they have the approved role. Can I assume you mean checking auth.role directly rather than defining roles and groups in weweb?
