The 15th of December in 2015 started like any other day. I picked up the keys from the reception and walked upstairs to the 2nd floor. While drinking my coffee, I was wondering whether people were willing to fill out 30-40 fields to look attractive in event managers' eyes.
In this project, speakers are the goods. Speakerhub.com is the place where event organizers can search for speakers for their next conference. Andras contacted us with this idea on a summer-day back in 2015. The primary function is that speakers can upload and edit their profiles. They appear in the searching list upon the information they have added, to be found by people interested. So our most important aspects of this function are reliability and stability.
Fast development vs. scalable solution
Drupal makes it possible to build prototypes quickly. This fast construction made it possible for us to react rapidly to Andras' diversified ideas. It took half a year to create the system, which is giving the ridge of today's application.
There were 45 fields available to build the user profile by the time the system was going live. The development did not stop. We added further functions to the project. Some of these refined the possibilities of data upload, others fine-tuned the notification system of the site or were functions that make editor work easier. And of course, a considerable amount of development happened to assure the financial sustainability of the project.
When the target group started to use the site, and new registrations arrived en masse, I got a clear answer to my first question. After a year, we had a vast number of visitors, and our system faced severe challenges. While the number of users increased, and the profiles expanded, the response time decreased. Last summer, the number of fields reached 120, which generated multiple problems that we couldn't solve with our previous techniques, and we couldn't afford to postpone the resolution.
Server concerns
The toughest recurring problem was slowness. We have several projects like this, where we operate with a massive amount of data, content, or users. We have also experience in describing something very explicitly. We have made fields before that can store up to 200 values. We have proven methods to handle these kinds of functions. The solution can either be reorganizing or fine-tuning the server environment parameters. But in this case, we needed to handle everything at the same time. If we treated one of the problems in a conventional way, we experienced further efficiency destruction on a different point or risked stability.
We continuously received development ideas and needs from both our client and the users, so we always could add to the project in a way that we could eliminate previously known problems, and we got the opportunity to avoid future complications. But there was still a request that we had to deny for a long time.
The reason was that we knew that the profile editor interface reached its limits when, despite any new features or improvement suggestions, the usage of the site will be slower. The outcome will spoil the user experience. As it was not an option to stop adding functions, we looked around to find a resolution for the current status.
We informed Andras that the time had come to find an easily scalable solution instead of implementing new functions, to replace the profile editor provided by Drupal.
Frontend cosmetic upgrade
We collected all acute problems, and looked into previous requests that we did not complete or could only solve with a compromise. It was our new bunch of demands. We also considered the main aspects, such as performance, upgradability, and sustainability. As a next step, we tried to understand at which points the actual status did not correspond to the new standards. Is there a possibility to make some improvements at least at one point in the project, or do we need to apply radical adjustments?
After taking measurements and inspecting theories, radical interference seemed the way forward in the long term, so we collected the above-described needs into common standards. We defined the target and the steps to reach it. From a technical point of view, this was a new area for us, so we made a small pilot project to test whether the planned solution will make any progress at all. We presented the results to our customers, who accepted it, and we started the actual work.
In the second part of the article, I will specify which kind of solutions we considered, and which was our decisive vote at the end.
Share with your friends!