Choosing Between Reactive Web and Traditional Web Under a Deadline
A new developer must build an internal request-tracking app in ODC. Requirements: about 60 concurrent internal users, a table view with filters, a detail form, role-based access for Requester and Approver, and email notifications on status change. The team lead says 'just use whatever is fastest to build.' The developer has prior experience only with Traditional Web in OutSystems 11 and has not used ODC before. There is a 3-week deadline and one other developer available for review only. The app will run on a shared tenant with other internal apps.
1. Recommend an app type and justify it against the stated constraints, not against general preference.
Read the worked answer
Reactive Web. In ODC, Reactive Web is the default and best-supported web app type for new development; Traditional Web patterns from O11 do not map one-to-one, and choosing a legacy-style path in ODC creates friction with the platform's current tooling and review. For 60 concurrent users with a filtered table and a form, Reactive Web's client-side rendering and screen-level data fetching are a good fit, and the built-in role model covers Requester/Approver. The honest counter-argument is the developer's O11 background: the learning curve is real. But 'fastest to build' over three weeks favours building on the platform's current path with a reviewer, rather than porting O11 habits into an environment where they may not apply. The decision should be confirmed with the reviewer before day one.
2. The developer plans to load all requests into a client variable on screen load and filter in the browser. Evaluate this for the stated scale.
Read the worked answer
Reject it. Loading all requests to the client and filtering in the browser is a pattern that works on demo data and fails as the table grows - it also exposes every request to the client regardless of role, which breaks the Requester/Approver boundary. Instead, use a server-side Aggregate with input parameters bound to the filter controls, and a pagination or infinite-scroll pattern so only the visible page is fetched. Apply the role filter in the query itself (e.g. request's requester = current user for Requesters), not in the UI. This keeps payload small, keeps authorisation on the server, and scales past 60 users without redesign.
3. What is the single biggest schedule risk, and how do you de-risk it in week one?
Read the worked answer
The biggest risk is not the feature list - it is the developer's unfamiliarity with ODC concepts (tenant, app types, deployment model, role assignment) colliding with a hard three-week deadline. De-risk in week one by building a thin vertical slice end to end: one entity, one filtered list, one detail form, one role check, one email - deployed to the shared tenant and reviewed by the second developer before any further features are built. That surfaces environment and platform surprises while there is still time to react, and it gives the reviewer something concrete to correct. Feature work in weeks two and three then proceeds on a proven foundation.