We then laid out rules on how each of these conceptual models would be understood and exchanged between client and server. Essentially, the server needs to vend out a page response that talks in terms of these entities so that the client can then render them.
- Page Layout Type : Every page will have an associated layout type that is a detailed spec with details like:
- What spaces appear on the page and where (by platform)
- Limits like min/max widgets that can be accommodated in each space
- How will the layout differ in case of portrait/landscape mode on mobile clients
2. Space Type: A set of enums to represent various types of “slots” that a page layout may contain. The association of what page layout contains supports what spaces is known on the server and client side.
3. Widget Type/Widget Template: The widget template spec defines:
- The UI/UX of the widget
- The schema of the data returned by the server for widgets of this template
- Details of what fields returned by the server should be data bound to what components of the widget
- Recursive links to specs of templates of each possible nested widget that this widget may contain.
- All possible interactions with the widget, along with animations, etc.
Each widget type can have a different UI based on the platform, owing to form factor differences, or platform interaction models. But the UI, UX of the widget is expected to serve the same purpose on all platforms.
Additionally, which widget templates are compatible with what space-type is known on the server side ahead of time.
These known types and type associations then allow the server to give a page response that contains all the required data and metadata for the client to compose a page out of its spaces, wherein the spaces compose themselves from their constituent widgets and so on.
The widget object along with the widget template type contains three crucial pieces of information that allows a widget to truly come to life:
- Widget data: This is the data that the client uses to paint the widget. Note that a widget may be rendered using different templates on different devices (e.g. when browsing content trays, web platforms will show an expanded image with content details in hover state whereas app will only show poster images with minimal content data). Depending on the chosen template, the widget data model may vary accordingly.
2. Widget Actions: A widget that just renders and shows something is good, but interactivity sparks life into it. This is where actions come in. Actions are predefined and well understood interactions that a widget supports and reacts to. What to do on a particular action can be communicated by the server using some known types. Here are some standard action types that we support as of today:
- Navigation
- Animations
- Standard Macros like logout, Add to Watchlist
3. Widget Analytics: In order to measure the performance, engagement and effectiveness of our experiences, we perform tonnes of instrumentation at page, space and widget levels and collect a bunch of interesting data from client side experiences. This is the third critical bit of data in the widget response (more on this in a separate blog).
Putting it all together, here’s how a sample page response from the server would look like
Alright, so a quick recap on what we’ve learnt so far about the Hotstar X architecture:
- We adopted a widget based architecture and defined tenets to drive the framework.
- We identified key components, their boundaries and properties including what aspects would be known to the server vs. the client.
- For a widget, we identified and defined the three critical property sets that allow us to send out a complete widget data model from the server.
- We wrapped up with a sample end to end page response data model that could be understood and rendered by the client.
Once this was done, we were able to kickstart the development on the client and server side. In the next article, we will deep dive into our server side architecture and how we went about building our flavour of a Backend For Frontend (BFF) architecture.
Want to code with the authors of this blog? Write your own? Work on mind-melting, tough engineering problems? We’re always hiring! Check out openings at https://careers.hotstar.com/.
