Business problem

Our client has multiple business opportunities to run interactive content in various locations. They already had a few of them running in environments where internet access was limited.

As the number of opportunities has raised, our client asked us to help build a platform that is capable to speed up their content creation and distribution process and implement a reusable solution.

Based on the initial discussions, the constraints of the possible locations and the desire of handling content were clarified, but the actual content modeling was a grey area for everybody.

Goals

We have aimed to provide a specialized content management platform with a built-in preview, separated web-based preview, and content distribution sub-systems.

We have formulated our constraints toward technical solutions:

• the solution needs to be flexible to support sharp changes in the content management domain without major development effort
• the interactive content needs to be usable offline
• the business logic needs to be shared between multiple components
• the content management and preview components need to be available online for our client only

Solution

It was obvious that the content editor and display were web frontend heavy, where the developers would spend their time the most. By adding a heavyweight backend for sharing the business logic we would have slowed down the team by introducing unnecessary dependency between frontend and backend work.

This was the main motivator to let the frontend development flow without blockers, we just need to find the correct tool for supporting it from the backend side.

This tool was Hasura's GraphQL Engine, which allowed us to just model our database, and it was exposing it as a GraphQL API.

We took advantage of the GraphQL Engine features like

• Role-Based Authorization using OAuth 2 JWT tokens
• Custom REST actions to control Digital Asset Management integrations
• Schema Migrations to do database refactoring
• GraphQL Subscriptions to provide a better content management user experience by displaying real-time changes from the database
• The Admin console where every developer could change the database or other settings

As the GraphQL Engine provided a solution for all data access needs of the web applications, our backend efforts have been freed up to cope with the tasks from the problem domain.

Drawbacks

Having close relationship between GraphQL schema and the database schema, every change in the database can possibly introduce updates to multiple web applications. In more traditional systems a backend hides the data storage complexities from the clients by having a separate interface. Without this interface, the risk of overcomplicating frontend code in the web application rose, and possibly destroying the sustainable pace of development.

The business logic has been also pushed into the web applications, thus additional effort was needed to keep logic in multiple applications in-sync with each other.

Unfortunately, we had to create and roll out our own content management user interface, because GraphQL Engine is not a CMS system. In the end, this was the only drawback that we had to solve by coding ourselves.

Win against the drawbacks

We have placed shared logic into libraries, which multiple web applications could use later. These libraries helped to reduce the maintenance cost of keeping logic in sync across multiple web applications. This is a simple, but effective software design trick.

Using a monorepo for storing all components code allowed us to validate the GraphQL queries against the actual database and GraphQL Schema in a build pipeline. This prevented lots of bugs and investigation time.

Advantages

The GraphQL Engine has boosted our development, frontend developers could easily modify database structure and progress with their tasks without relying on somebody.

This shows that this tool is excellent for rapid validation of experiments. Basically, this is what we were searching for as our first goal.

To support offline available interactive content, we used Jamstack and implemented with Next.js as the site generator and GraphQL Engine as "Headless CMS". This duo is working nicely together, also using Typescript, the build time validation of GraphQL queries was extremely easy.

I also would like to emphasize the Hasura's documentation, which helped a lot in integration with Auth0 and setting up the production deployment. The GraphQL Engine is lightweight, it needs minimal resources under the load we have and scales well when needed, and it has free and open-source variants.

Conclusion

Overall we had allocated 3 frontend developers and 0.5 backend developers to this project. To show the time gained using Hasura, let me share that the backend developer also prepared the cloud infrastructure and implemented the majority of the content delivery solution while working only half-time on the project. Without the GraphQL Engine, there would have been several weeks of development just for getting the data from the database to the frontends.

I am glad that we found and used this tool, and I also suggest for everybody who has a similar situation as we had, give it a try.