“The Publishing Platform Project”

Here’s an article written following an interview with Shaun, Senior Software Engineer at Voodoo
He discusses the Publishing Platform Project that he recently worked on

As a Tech Engineer at Voodoo, I have the opportunity to develop and run innovative projects with the team. Our most recent project is the new version of our Publishing Platform, which is the interface used by external studios to contact Voodoo. It is used by the Publishing Managers to coach the studios and to view statistics on the iterations and the games as a whole.

Previous to the creation of the Publishing Platform there were no notifications, and publishing managers and/or developers were not aware of problems, which meant they couldn’t solve issues quickly enough. We needed alerts on events, for example, studio games to rate, new games to test, errors during campaign creation, to overcome communication problems with the studios and make us more responsive and effective.

Therefore, we needed to create a faster and more efficient system. We set about creating the Publishing Platform project with wider technical professions, including one product manager, one front-end, and back-end developers.

In order to create the platform, we created an independent service with Serverless and took the opportunity to test a Serverless database. This was the first time we had tested this kind of engine. We chose it because we needed an independent database and it seemed to be the most relevant method to use which had scalability.

In terms of technology, tasks, and bug management was done via Jira, the source code was on Github and deployments are automatic with CircleCI. We chose this technology as firstly, we were familiar with how it worked, and secondly, it was easy to test. The Serverless side was chosen because it was truly on-demand (you can’t know how many notification requests there will be per day, so you only pay when a notification is sent or read).

When it came to constraints these were mainly when it came to security, we needed to prevent anyone from having access to the notifications. In order to combat this, we sought the most suitable means of securing the site as quickly as possible.

“… changes had to be made that would break the compatibility”

We also found that when we created part of the code at the beginning that was functional, it was then also exploitable by the front. We realized that there were some concerns and that changes had to be made that would break the compatibility. This effectively meant that if we changed something on the server-side and put it into production, the front-end could not access notifications at all.

What was interesting was to find a way to prevent it from crashing, while we could make changes on the front-end, and keep an open system that worked with the front-end; we then updated the front-end for the security part, so we could clean up the server-side.

When it came to the project organization, we chose this project because it was an opportunity to create an independent service, rather than making a feature in the project itself. As there was another service that needed to be taken over from the real-time communication with the browser’s WebSockets, we had to make it more viable and maintainable.

The work on the project lasted about two months, we worked in a two-week sprint with daily meetings every morning to progress all elements. In terms of roles and responsibilities, the front-end developer created the front end. As a full-stack, I added code and created the back end. Every time we pushed code in our different subprojects, we made sure that at least one other developer checked the code for optimizations or bugs.

“That was how we iterated and ensured success”

Throughout the project planning, there were key milestones that we had to work through. We needed to ensure which notifications were going to be sent and to whom. There was preparation needed when it came to the architecture on the back-end, and we also needed to ensure that the server would communicate with the front-end. Testing was key especially in its integration environment and of the actual sending of notifications from some drafts. This created a maintenance cycle: we sent out notifications, we realized that something was missing, and modified the project. That was how we iterated and ensured success.

Conclusion

Upon completion of the project, we hosted an assessment, which had very positive results. The project allowed strong collaboration with the other members of the team. It allowed us to set up code and architecture bases so that we could add other small services to this project. The fact that it is a service independent from the rest also makes it easier to maintain, update, and amend elements that have no impact on the rest of the project.

“To go further”

With the success of this project, we are looking at developing new projects soon, which like this will be focused on how we can improve our practices to foster greater collaboration.

If you would like to join his team and work on the same type of project, please apply directly on our career site: https://www.voodoo.io/careers/jobs.