Live Streaming Platform for International Labour Organisation (ILO)

Key benefits of this approach include a convenient user interface for site editors, with excellent support for content translation and granular user permissions; readily-available advanced features such as search, SSO and GraphQL export; fast content delivery and reactive user experience for visitors; scalability and security.

1. Identity and Web Design

   We started work basing ourselves on mockups already previously prepared by the Nuvole team. Those designs and mockups since then evolved greatly, with the expertise of both teams contributing to a modern, clean website that pleases both newcomer visitors and the ILO team alike.

   It’s worth mentioning how preparing these mockups on Figma has helped us immensely in this kind of collaborative model, by helping us keep up with layout changes during implementation, provide feedback, and implement those layouts quickly. It is a tool we have been using for years and will likely continue to do so in as many future projects as possible.

2. Video Platform (Kaltura)

   ILO already manages their extensive video library via a platform called Kaltura. With a comprehensive JS Player library. We simply had to integrate it into each webpage that contains a video.

   This JS Player already supports all the options we need for the videos, including switching audio tracks, captions tracks, fullscreen, and other typical video-playing abilities.

   When such comprehensive open-source software already exists and is ready to use, we can really focus on functionality rather than implementation. It’s really a win for everyone.

3. Content Management System (CMS)

   Drupal, an open source PHP CMS, was chosen to back the platform. It is a robust piece of software that allows any platform editors to just focus on their content, knowing that in the end it will be properly applied to the built pages.

   Since custom functionality was paramount to the platform, Drupal was an ideal choice as, beyond being open source, it is designed with custom functionality in mind; creating new fully integrated modules is straightforward, and allows for virtually any functionality conceivable.

   Content structure was designed to closely mimic the page structure shown to the user. The relationship with Kaltura videos is extremely simple as well, given their unique video ids.

   While most of this backend work was handled by Nuvole, together we designed a Graphql interface for the website to query all this information in an efficient and optimal manner, while retaining its availability for future uses of all this content in other applications and platforms.

4. Static Site Generator (SSG)

   We chose NextJS as our frontend framework. We already have extensive experience with it, as it has been our go-to choice for many similar projects.

   NextJS is a React-based framework that allows us to create statically rendered pages based on complex content structures from one or many diverse backends, as well as keeping the possibility of dynamic content being served via API routes or other kinds of server-side processing and rendered requests.

   It was a simple and logical step to make use of the GraphQL interface, developed in the backend, as the source of content for the NextJS frontend. This produced a fully static site, optimized for SEO and fast content delivery, that seamlessly integrates the Kaltura JS Player library within the page’s React code.

   
   

5. Hosting

   We used Netlify to host the frontend, not just to make sure speed is not a problem, but also to avoid ever going offline. Netlify has a Content Delivery System to store your project and serve it fast and secure to your user browser. On top of that, their free tier is very generous.

   The backend is hosted in Platform.sh, which allows for similar CD/CI (Continuous Deployment and Integration) for PHP based systems such as Drupal, with a reasonably low cost.

   A content change in the backend triggers an immediate new build of the frontend, via a hook in Netlify, assuring that the frontend is constantly updated.

   
   

6. Livestreams (AWS AppSync)

   Some events hosted by the platform are delivered live and, as explained, it was paramount that those are triggered automatically and immediately in the visitor’s browser. We simply could not rely on new deploys of the frontend because a) while still fast (usually a minute or two) it’s really not that immediate, and b) the user would still need to manually refresh the page to see the new content.

   We adopted AppSync, a managed service offered by AWS, that consists of a Graphql interface that a browser can query directly, and subscribe to changes to its content via WebSockets - a means of connection alternative to HTTP connections that is kept open for immediate delivery of new data.

   With the Drupal backend also communicating with this Livestream service, to control which Livestreams are active or not, the end result was a perfect symbiosis. The browser can visit a livestream page hours in advance, and be kept open there. The livestream will immediately be triggered as soon as the event starts.

   It is still important to keep best practices and respect a user’s experience. As such, the user still needs to hit “Play” for the livestream to trigger as well. A user can however hit play beforehand, and watch pre-recorded videos while they wait, or simply hit play as soon as the “Live” label appears.

   
   

From the technical point of view, the following were very good learning points for the development team:

• NextJS continues to prove itself as a solid, reliable, and versatile solution for many different use cases. Its hybrid approach to Static Site Generator + Server-Side Rendering was a clear win also in this project. For sure we’re keeping it in our arsenal of tools to use in many future projects.
• Drupal continues to have relevance in a static-first web world, and in our opinion, that trend will only increase from now. Focusing on its CMS capabilities, we used Drupal as a headless backend, together with custom functionality for the specific needs of this project that were built seamlessly using its own methods, in particular leveraging direct connections to Kaltura and its video library.
• The AWS service integration was “the” big challenge. While we already have experience with other AWS services, this was our first time using AppSync. From the start, we decided to make use of their helper tools to do the initial setup, as it would assist us by automating a great deal of the service configuration on the AWS side of things so that we could focus on its functionality. However, given that they have at least three major CLI tools being developed by completely separate teams, we found the discrepancies in documentation, and even inconsistencies in their implementation (i.e. bugs…) at times frustrating. We settled on using Amplify to handle automated deployments of this service, via Github Actions, however, it took some effort to find the configuration and command sequence necessary to achieve our structure and authentication needs. As with everything related to AWS, it was a learning experience that gave us a whole new outlook on how these types of services are built and used across the ecosystem.
• Being no strangers to collaborations with other teams, we found it a pleasant experience to work together with the Nuvole team. Having our roles clearly defined, with Marzee focusing on the frontend while Nuvole worked on the backend, we managed to build great synergy by being involved in each other’s tasks, to provide often necessary insight into what would influence and restrict the other team. This only further reinforced our conviction that role separation does not equal task accountability; in order to build a solid and cohesive product, all teams must work together in all aspects, and be conscious of any limitations, problems, and even achievements of the other teams, to know how to best adapt and develop their own tasks.