The Mobile App That Needed a Server Action It Did Not Have
A developer is building a simple mobile app in ODC to let staff scan a badge and look up a person's department. The lookup must query a server-side entity of 12,000 people. The developer writes a screen with a local variable for the scanned code and a client action that tries to query the entity directly. It does not work as expected. A colleague suggests pulling all 12,000 records to the device on first launch and searching locally. The app must work on shared tablets with intermittent connectivity, and the department data changes weekly.
1. Explain what is wrong with querying the entity from the client action and what the correct pattern is.
Read the worked answer
In ODC mobile, client-side logic runs on the device and cannot query server entities directly - data access happens through server actions exposed to the client, or through data fetched at screen preparation. The developer's client action has no server context, so the entity is not reachable the way it would be in a server action. The correct pattern: create a Server Action that takes the scanned code as input, runs an Aggregate filtered on that code, and returns a Structure with only the fields the screen needs (name, department, maybe a photo URL). The client action calls the server action and binds the result to the screen. This keeps the query server-side, returns one record instead of thousands, and respects the intermittent-connectivity constraint by failing fast and gracefully when offline.
2. Evaluate the colleague's suggestion to cache all 12,000 records on the device.
Read the worked answer
Reject it for this case. Twelve thousand records on a shared tablet is a large local footprint, a slow first-launch sync, and a staleness problem - the data changes weekly, so the cache is wrong within days and there is no reliable refresh on intermittent connectivity. It also puts the entire people directory on a device that is shared and possibly lost, which is a data-exposure issue, not just a performance one. The local-cache pattern is right when the working set is small and stable; here it is neither. The server-action lookup returns one record and is correct by construction.
3. Design the offline behaviour for the lookup so a technician on a bad connection is not stuck.
Read the worked answer
Two layers. First, the server action should time out quickly (a few seconds) and return a clear 'not available offline' result rather than hanging. Second, cache only what was recently looked up - a small local entity keyed by badge code storing the last N successful results with a timestamp, so a repeat scan of the same person works offline. Do not attempt to pre-cache the directory. On the screen, show the cached result with a visible 'last updated' marker so staff know it may be stale, and offer a retry when connectivity returns. This bounds the local data, keeps the weekly changes flowing through on next successful lookup, and degrades gracefully instead of blocking the workflow.