Web Apps: fast, cheap, cool

Each Web App (web app) is a small and fun frontend adventure.
Once at iFunny, we organized a “web app marathon”, entertained millions of users and made a lot of money along the way. And now they are ready to tell you how it all was.

To begin, I will introduce myself. My name is Anton, I am a TimCleed front-end team FunCorp.
And in this article I will share the experience of developing interactive web applications based on mobile WebView.

Web App View

WebView is a browser built into the mobile application.
And if there is a browser, it means that there are extensive features of HTML5, JS, CSS.
This is in theory. But what really?

But in fact we were interested in other questions:

• How well will iFunny take the new format?
• How problematic are such applications in development? Two years ago, the company lacked experience in this part, and really wanted to make up for it;
• Does this technology save time and money? The development cycle of such applications is shorter, therefore, this possibility exists.

Web App # 1: Hellowinner

In those days, the team consisted of two people and I worked on all the web apps alone. Two months have passed since I joined the team, so I went straight from the ship to the “web app ball”.

The first application was prepared for October 31 - the day of the celebration of Halloween. With the help of a mini-game with two buttons, it was planned to tickle the nerves of users and cause a reaction like this:

The application itself looked like this:

Users with excitement caught the button, the application mockingly invited to do it even faster. At the moment X, an animation suddenly appeared on the screen with shouts, sounds and vibrations, which caused a storm of emotions. And not only among users: looking at this hare even now slightly distorts me.

The technology stack was simple:

• Harp static site generator;
• Template Jade (now Pug);
• preprocessor LESS.

The Harp generator provided the complete infrastructure out of the box, so I wrote the code, generated a static site with CSS, HTML, JS, put the whole thing on the CDN, wrapped it in WebView and was happy. And there was something: the first experience with web applications gave such a peak in attendance that later each product manager considered it his duty to come up with something interesting.

Web App # 2: Putin vs Trump

Partially this story was mentioned in the article about feils . It's time to tell how it all really was.

In the next web app, it was decided to conduct user surveys. Of course, in a favorite format - on slippery and hot topics. The first poll was called President you want, and it was necessary to choose Putin or Trump.

In contrast to the first application, the second implied the presence of the server part and work with the database. At that time, it was thought that it was quite simple and, being a front-end developer, I could manage. Coped. With some reservations.

I used MongoDB as a database: the iFunny mobile client API spun on this particular system, there was a ready cluster, and the choice was obvious. Express.js was chosen as a server framework. All the same Jade (Pug) as a template engine, LESS as a preprocessor and static build using Gulp.

In the first hours after the launch of the new application, over a million users voted. And then there was a curiosity: the amount of interest exceeded 100%. Not 146% of course, near.

Instead of using the standard increment from the database, I used the banal “current value = current value + 1”. And I learned about such a concept as the competitiveness of requests in general only in production. Well, yes, let the elephant in the china shop.

It turned out funny, and users took it as a good joke.
I corrected errors in the deep night, with trembling hands and with mats. These 10 thousand queries per second taught a good lesson, and I promised myself not to do this anymore.

That poll corrected:

Web App # 3: Booby Bird

After the impressive success of the previous web app, it was decided to launch a full HTML5 game. And since the department still employed 2 people, the development was entrusted to a Chinese freelancer, who was found by product managers.

The guy - well done, tried to glory:

• assembled the game in a WYSIWYG editor;
• wrote the server part in PHP according to manuals with StackOverflow;
• bonded these parts with the help of the glue known only to him;
• gave results in the form of obfuscated files.

My optimism finally dried up after the application flatly refused to run on the combat domain. As a result, I transferred the code to the already tested Express.js and, as far as I could, added patches to the obfuscated client code. The game came to life. Even then it was clear that the design is fragile and rests on an honest word.

At the end of the game there was a rating of the best players and, of course, they broke it 10 minutes after the release. Users dug out a link to save the results and massively began to change the values ​​in it. I released an update in which I personalized the link using a JWT token, and the mass hilling of the top is over.

But I couldn’t protect the code that got to the user entirely: obfuscation was taken care of, and requests over the network were viewed in the corresponding utilities. Individual users who knew how to use sniffers, again disassembled the link with the results and sent a lot of different nonsense there. For which they were then sent to the ban themselves, the benefit of the bundled JWT token turned out to be beyond their powers.

This web app still scored a decent amount of views and, to our surprise, had a very long tail of repeated visits.

Web App # 4: Holiday Giveaway

On one of the most beloved holidays by Americans - Christmas - a lottery was arranged, in which consoles, gift cards, cameras, T-shirts and a number of other amenities were played. A total of 4 draws were held, each at a strictly defined time. After the next draw, the registration was opened for the next one.

"Under the hood" were all the same Express.js, Jade (Pug), LESS. A large peak of attendance was expected, and I used a separate MongoDB cluster as a database. And even conducted load testing, so that this time everything just turned out as it should. Well, you understand.

Web app showed excellent results: about 3 million participants already in the first round. But with the success came the difficulties.

First, the problem arose in the NGINX and PM2 combination, which was used to control the instances of the application. I sincerely was scared, I didn’t understand what to do: HTML5, CSS, JS, and here there are some timewalks on the network, devops-engineers puzzled and the silent demanding look of the technical director. After some time, the problem was resolved, and before the next prize draw there was time left. I naively began to believe that everything was fine now, I was tormented.

And here again the problem: the scheduler built into the server side refused to make a second draw. For some reason, I decided to check the results of the script and it turned out that they were missing. The moon was outside the window, the problem did not work out locally - everything worked, and time inexorably went against me: the publication of the results of the second draw was approaching. Saved by the fact that I prudently left the possibility of manual launch. A minute before the publication of the results of the draw, I launched the script, made sure that it worked correctly, and exhaled.

This was followed by sleepless night hours, in which I kept as best I could: I watched movies, tried to get carried away by the search for errors, dozed in an embrace with an alarm clock. At 3 o'clock in the morning I launched the final draw, rechecked everything again and fell asleep.

Such sacrifices were justified: after 24 hours, the web app had more than 12 million views, thousands of comments and a lot of fuss on social networks. Users got very excited: they definitely liked the app. Yes, and I liked what to hide.

Cons and pros webapps

Cons :

• a lot of tears were shed with Samsung, because WebView is the default browser, and Samsung love to customize everything. And if desktop browsers, mobile Chrome and Safari displayed a web app correctly, then Samsung has something to distribute. This brand is very popular in the USA, it was necessary to repair;
• after all mapping problems were fixed, it could turn out that the application worked incorrectly in combat conditions. And the reason was trivial: if you forgot to put a couple of checkboxes when building a mobile application - and again! - scrolling in WebView did not work as it should. And this is most likely a new release and at least several days of delayed launch.

Pros:

• quickly . The average development time is two weeks. The first week is an active development, the second is tests, fixes and refinement;
• cheaply The cost savings are huge. A web app can create one front-end developer for all platforms. Dear mobile developers are not involved here. And even if attracted, it is rare and small.
• cool The format can really be interesting to users. Judging by many indicators (the number of comments, registrations, session time in games), the audience likes such interactivity. They like to notice mistakes and savor them, they like to break and fly into bans, they like to discuss the whole thing. And what could be better than a heated and involved community for a UGC product?

During the period from September to December, 6 web app was done. And each of them gave good results. "Web App Marathon" allowed to answer all the questions of interest, including the most important: yes, this is definitely a worthwhile topic to continue to deal with it.

Now the development of web apps has already been put on stream: for the past 2017 there were 94 of them, and by the number of sessions something is about 101 million. By the way, most of them can be viewed here .

I, in turn, understood something about working in a grocery company.

When the issue was solved with the change of work, I was mentally preparing for the fact that doing one product is boring, and I most likely have to “nag the site” for the next 2 years. When I had to do a web app, burn with increment, see more than 10K requests per second, run scripts at night with my hands, I realized how wrong I was. I really had to "cut the product", however, every week - a new one. And this is a great fan and decent skill development.

By the way, those “next 2 years” I still had to “cut the site”, only as a new lead from a frontend team that had been formed from scratch. This experience will be fun web app. I will tell about it in the following article.