Lifting User Experience with Cloud Functions
Traditional Approach
Requests from the app go to the API, where requests are processed and results sent back as response. Often, once the client processes the response more data is needed (e.g. additional user data), thus new requests are fired to the cloud (e.g. to FireStore). User interface rendering (HTML generation) can’t proceed on the client until all required data is available.
- This approach is simple and is very well understood
- It has higher latency due to more app ⇔ cloud roundtrips
- This approach requires page reload for the user to get new features (this is relevant as some of our clients run very long sessions, e.g. in kiosk mode)
Server Side Rendering (SSR)
With server side rendering we aim to generate all (or most) of HTML on the server. This is naturally done using Cloud Functions, so server management is not an issue with this approach.
- Single app ⇔ cloud roundtrip (lower user visible latency!)
- More opportunity to run complex rendering code (e.g. for A/B testing)
- Interactivity still requires client code.
Let’s consider the cons argument. Making SSR generated HTML interactive is called “hydration”. This typically is still a better user experience as user needs to see rendered UI before taking actions, thus interactivity can sustain higher latency without user experience degradation.
Server side rendering could be applied to native apps as well. In one of the coming posts we’ll consider engineering trade-offs for server side rendering in our SwiftUI app on iOS.