“The lifetime of a tab can be almost endless”: Timofey Chaptykov about JS development on VKontakte

This spring, VKontakte blog wrote "We are ready to start talking about what is behind the facade of the product." We did not miss the opportunity - and on the eve of the JavaScript conference of HolyJS , where VK developer Timofey Chaptykov gave a presentation , asked him a few questions.

- What exactly do you do in the VC?

- Mostly I am developing a message section. But we have a small team, and the responsibility of each developer is quite wide. And the longer a person works here, the wider it is.
')
- Before working in the VC, you lived in Novosibirsk - because of this work and moved? Recently, a Novosibirsk Java developer told us that he has a great life in Novosibirsk, and that in a city with JavaScript and frontend, are there many vacancies, is the local JS community developed?

- Last year I visited St. Petersburg four times. At some point I decided that it was easier to move. Well, to refuse the proposal to work on one of the largest, most complex and mass projects with an extremely demanding audience was difficult.

There are a lot of large IT-companies in Novosibirsk that have jobs in web development: Yandex, 2GIS, JetBrains, SberTech, Tinkoff.ru. So I would say that in Novosibirsk there are guys who can make a complex scalable frontend. There are several local conferences and meetings, once a year one of the largest IT conferences in Russia is held.

- VK has almost 100 million monthly audience. How does such attendance affect development in general and JS / frontend in particular?

- Now all changes are first released for a small percentage of users. For these users, we collect separate statistics. It helps us to assess whether the release will affect the load.

Sometimes this is not enough. Some of the features we roll out only at night, if we assume the possibility that the release may affect performance and work under load. At night, Moscow time, the load is lower, and if we see anomalies in the graphs, we will have time to roll back the changes or release hot fixes before the peak load occurs and there is a risk of service failure.

With our load, we cannot afford simple approaches to updating statics. We can not afford to combine all the scripts into one file and update it with each delay. If all users come at the same time behind the file, it will be difficult to sustain the load. One extra request, which will make 100 million users, can lead to disastrous consequences. Therefore, we version the statics, load dynamically (the page will load the version of statics that is compatible with it), break into small pieces by sections and site features.

Some changes we can not make directly. We cannot turn off the site for several days while the database is being migrated with billions of records.

When you have 100 million active users per month, probability theory starts working against you. The number of experiments such that impossible events become a daily routine. If the bug is reproduced once per million, this means that this bug will be played many times daily. It is necessary to work out even the most incredible scenarios in detail.

The frontend is affected by the fact that sometimes VKontakte case studies are very different from other sites. For example, the lifetime of a tab with messages can be almost endless: you open a tab, and it lives for months. It makes us think more about memory consumption.

Sometimes strict performance requirements arise from a large amount of code. For example, the assembly had to be organized not entirely trivial and mainstream.

I think we more often than most developers have to think about data structures, including on the client. In our kitchen, you often hear conversations about algorithms and data structures than about new libraries and methodologies.

On the site, we almost do not use external dependencies. Technically, each section on the client is a separate JS application. From shared resources - a system for codesplit and static versioning, working with multilanguage, utilities for working with DOM, server requests, a small shared storage, some reusable solutions for the user interface.



- Long ago, when Node.js was a little-known niche solution, VK developer Oleg Illarionov became its popularizer in Russia. Do they use Node.js in VK now, when it is more than mainstream?

- In most cases, for objective reasons, we cannot use Node.js on the backend — too slowly on our volumes. Therefore, we, like the entire industry, use Node.js to build the frontend. And there we use the traditional set of tools: Gulp, Webpack, Babel.

- Earlier, VKontakte posted its own KPHP developments into open source - and in the case of JS, do the social networks have any significant internal “bikes” that could theoretically be in the open source, or are you mainly using ready-made solutions?

- We use very few ready-made solutions in production. In package.json, in the main repository, only 4 dependencies are declared. Two of them are polyfills, two are libraries for recording and encoding audio to mp3.

Significant domestic bicycles a lot. But often our solutions are highly specialized, they will not be in demand in the “mass” development sector. For example, the infrastructure around KPHP has a fairly high entry threshold, its use imposes certain restrictions. And there are not so many projects on which it would be possible to feel significant benefits from its implementation.

Nevertheless, I expect that we will have more open-source software in the field of frontend.

“The JS world is often criticized from the perspective of“ in the modern frontend, to write “Hello world”, you need 360 MB of dependencies. ” Does it bring inconvenience when working in VC, or is it an insignificant factor in such a large-scale project compared to others?

- Well, this is definitely not the main problem that we have to solve =) We have 140 MB of dependencies in node_modules. In my opinion, one of the most serious technical challenges is the elimination of technical debt and the development of infrastructure for development and testing. In our realities, we must do this without slowing down the development of new features. And yet the same team of several dozen developers for all our products.

- Your report on HolyJS is called “React with the speed of light: not quite the usual server rendering.” Doesn’t it prevent you from using React that it was created in Facebook? :)

- Come to the report, there I will tell you that the final decision is not based on React =)

I would consider React as a term for an approach rather than as the name of a specific library. Speaking about React, we usually mean Virtual DOM, declarative rendering, component approach, JSX.

In most cases, React can, with minimal effort, be replaced with another library that uses the same principles. And find some benchmarks that show that the chosen solution works faster under certain circumstances. =)

I like Preact, a tiny 4 KB library that provides all the basic features we are used to in React.

React itself is not currently used on the VKontakte site, but there are several of our projects. For example, VK Messenger is a desktop application on Electron, written in React.

- Thank. Finally, I would like to clarify because of your ironic tweet about the notification counter: can you briefly explain to anyone who does not face this professionally why this is a difficult task?


- The counter of notifications is one number that is displayed as a result of the work of a huge number of systems. And usually these are complex and intricate multi-level systems with caching, asynchronous execution of tasks, queues and calculations that are performed on a huge number of servers. As a result, failure of any part of any of these systems may result in the user seeing the wrong value on the counter.

It seems to me ironic that the complexity of systems in IT is constantly attracting my attention with broken red counters in some applications on my phone.