This was a survey taker system built as a single page application (SPA) that is entirely driven by an external API. I was the lead developer on the project and was responsible for creating the SPA with Sirota’s in-house developers producing the API.

Architecture

Their developers were more software oriented and as such had little experience in developing external APIs, as such I gave a presentation to them and their CTO in different methodologies of API development.

From this we introduced Swagger into the workflow. Swagger allowed us to define the endpoints and their payloads for us both. Besides giving excellent overview of the project it also allowed the SPA and API to be developed independently of one another, this ensures the speed at which one is developed does not hinder the other.

As long as both systems adhere to the definitions in Swagger they could be seamlessly connected together once they were both completed.

Performance Considerations

Despite appearing as a simple survey taker on the surface there were many quite unique technical hurdles to overcome. Firstly, it had on average 100,000 concurrent users so we needed to be careful with not overloading the API, to address this I built a multi-tiered caching system so any data that could be saved locally – such as the dictionaries for multilingual functionality would be saved, only calling the API as a last resort.

The API could also control how the survey behaved in accordance with their server load. For instance if the server was still struggling under the load then it could tell the surveys to save their answers locally and only submit them to the server once the user had finished, but during a quieter period the answers could be saved upon changing page or even on completion of each question if they wanted.

The idea being that the client could control as much or as little about the surveys as they wanted.

Advanced Logic System

Following the concept of empowering their API a complex logic system was developed, which allowed the things such as “only show question 3 if the user answered ‘no’ to question 2” or even more complicated statements such as “if the user filled in question 1 and entered their answers to questions: 2, 3 and 4 average out to greater than 10 – skip page 2”.

The definition of this logic passed down from their API then parsed by the SPA to give the appropriate behaviour.

Result

The client was very happy with the result.