“The lifetime of a tab can be almost infinite”: Timofey Chaptykov on JS development on VK
- What exactly do you do in VK?
- Mostly I am developing a message section. But we have a small team, and the area of responsibility of each developer is quite wide. And the longer a person works here, the wider it is.
- Last year I visited St. Petersburg four times. At some point, I decided it was easier to move. Well, it was difficult to refuse the offer to work on one of the largest, most complex and massive projects with an extremely demanding audience.
There are a lot of large IT companies in Novosibirsk that have vacancies in web development: Yandex, 2GIS, JetBrains, SberTech, Tinkoff.ru. So I would say that in Novosibirsk there are guys who can do complex scalable front-end. There are several local conferences and meetings, once a year one of the largest CodeFest IT conferences in Russia is held.
- VK has an almost 100 millionth monthly audience. How does such traffic affect development in general and JS / frontend in particular?
- Now all changes are released first for a small percentage of users. For these users, we collect separate statistics. It helps us evaluate whether the release will affect the load.
Sometimes this is not enough. We roll out some features 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 manage to roll back the changes or release hotfixes before the peak load occurs and there is a risk of service failure.
Under our load, we cannot afford simple approaches to updating statics. We cannot afford to combine all the scripts into one file and update it with every deploy. If all users come simultaneously for the file, it will be difficult to withstand the load. One extra request made by 100 million users can lead to disastrous consequences. Therefore, we version the statics, load dynamically (the page will load the version of the statics that is compatible with it), break it into small pieces according to the sections and features of the site.
We cannot make some changes 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 is such that impossible events become a daily routine. If a bug is played once per million, this means that this bug will be played many times daily. We need to work out in detail even the most incredible scenarios.
The front end is affected by the fact that sometimes the cases of VKontakte use are very different from other sites. For example, the lifetime of a message tab can be almost infinite: you open a tab and it lives for months. This 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 organizednot quite 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 will often hear talk 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. Of the common resources - a system for code splitting and versioning statics, working with multilingualism, utilities for working with DOM, server requests, a small shared repository, some reusable user interface solutions.
- A long time ago, when Node.js was a little-known niche solution, its popularizer in Russia becameVK developer Oleg Illarionov. Do they use Node.js in VK now that it’s more than mainstream?
- In most cases, for objective reasons, we can not use Node.js on the backend - it is too slow on our volumes. Therefore, we, like the whole industry, use Node.js to build the frontend. And there we use a traditional set of tools: Gulp, Webpack, Babel.
- Earlier, VKontakte laid out their own KPHP developments in open source - and in the case of JS, does the social network have any significant internal “bikes” that could theoretically end up in open source, or do you mostly use ready-made solutions there?
- We have very few ready-made solutions in production. In package.json, only 4 dependencies are declared in the main repository. Two of them are polyphiles, two are libraries for recording and encoding sound in mp3.
There are many significant internal bicycles. 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 one could feel a significant benefit from its implementation.
Nevertheless, I expect that we will have more open source software in the front-end area.
“The JS world is often criticized from the perspective of“ in the modern frontend, to write “Hello world, you need 360 MB of dependencies.” And when working at VK this brings inconvenience, 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 pace of developing new features. And all the same team of several dozen developers on all our products.
- your reporton HolyJS is called "React at the speed of light: not quite an ordinary server rendering." And does it stop you from using React because it was created on Facebook? :)
- Come to the report, there I will tell you that the final solution is not based on React =)
I would consider React more as a term for an approach than as a name for a specific library. Speaking about React, we usually mean Virtual DOM, declarative rendering, component approach, JSX.
In most cases, React can be replaced with minimal effort by another library that uses the same principles. And also find some benchmarks that show that the selected solution is faster under certain circumstances. =)
I like Preact, a tiny 4K library that provides all the basic features we are used to in React.
React itself is not currently used on the VKontakte website, but it is in several of our projects. For example, VK Messenger is a Electron desktop application written in React.
- Thanks. Finally, I want to clarify because of your ironic tweet about the notification counter: can you briefly explain why this is a difficult task for everyone who does not encounter this professionally?
- The counter of new 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 confusing multi-level systems with caching, asynchronous task execution, queues and calculations, which are carried out on a huge number of servers. As a result, the failure of any part of any of these systems can lead to the fact that the user sees an incorrect value on the counter.
It seems ironic to me that the complexity of systems in IT is constantly attracting my attention to the broken red counters of some applications on my phone.