Constructor

Denis Paia ( Yandex )

My name is Denis, I work at Yandex, and more precisely, I’m developing the frontend for the search results page.

Disclaimer: Denis talked about this in 2016, but we considered that as a demonstration of the architectural approach, this report is now even more relevant than then.

Today I’ll tell you about such a drop dead in our inner thing as Constructor, about how it turned out, why, and how we came to all of this. It seems to me that the decisions that we made during the implementation of this wonderful figota may not be useful only to us within our company, our team, but also to a host of other teams in your companies, for example. I don’t know if I mentioned it or not, but the project is really very cool. Why - now I will tell.



Now, in the era before the “designer”, before we implemented it, the development of even a typical product feature, the most standard one, took us an awesome amount of time: in the region of two weeks, maybe sometimes more, sometimes less, I will dwell on this in more detail. And now, when the Designer is implemented, we have precedents when features are done in a day - moreover, of the same complexity - or maybe less. And, best of all, often not even by us, not by the front-end. In general, it seems to me that this is just some awesome fabulous result, but nevertheless it is true, and as we get to this, I will now tell.



But first things first.

As I said, I’m working on a search results page, if you ever suddenly used Yandex for some reason - by the way, I advise you - you probably already saw it. If you haven’t seen it, then - look, it looks as follows.



You can drive it on your laptops, it’s even funnier live. 35, maybe 36 or 37 front-end workers from 6 cities work on it. In addition to the front-end, there are also managers, designers, testers, some huge number of guys from the backend.



In general, if you take a picture of everyone, it will turn out something like this.



What are we all doing?

We make a whole lot of features of all sorts of different, a significant part of them is grocery.



For example, this beautiful thing on the right with photos of Angelina Jolie, some kind of structured information, films where she was shot - in our terms, this is a separate feature. Quite large, it is called an object answer, if anyone is interested.



In addition to such large features, there is a significant part of the features smaller. For the user, they look just like not quite ordinary results on the output. With pictures, structured information, seeing, in general, something is a little special. And we have such features above the roof. For some reason, I have a figure in my head that there are about eighty of them, but I don’t know where I got it from, but, I think, it looks like the truth.



How does all this look technologically, if on top? For each such feature there is a data source, that is, the guys from the backend have mined the data and, through another backend, which we call a report, have already transferred it to us in the frontend. In the frontend, we have our own server part, where on the basis of this data we generated markup that is already sent to the user's browser and is actually a feature for the user. It seems that everything is simple. Now let's dwell on a specific feature, and on its example I will show what we had a big trouble and problem with.



So, suppose we need to make a feature. How does it all start? First, the backend guys should mine the data. For example, if we are going to make a feature about new devices - features of this kind are often called “sorcerers” in Yandex, if I repeat this word again, don’t be scared, it’s just a “feature”, why so - it doesn’t matter. So, for features you need to mine the data.



This data reaches us in the form of a JSON-chic, and the JSON-chic is very specific for each feature. That is, if this is a sorcerer of new devices, then there will be information about the device, a link to the market, the name of the manufacturer, maybe something like that. If it was a feature about social networks, there would be a user’s first name and surname, something else, his marital status, in general, some sort of figot in the feature domain.



In parallel with data mining, you need to draw a design for all this.



At that time, the design was represented by us as mock-ups, that is, in essence, pictures, but with beautiful, perhaps specifications, which indicate all the indents, sizes, and so on. That is, it was generally quite convenient for us.



After we have the data and design, the task is already set for the front-end, where on the basis of this input information we implement the component directly under the feature. In the process of implementation, we try to use some common things: buttons, links - from our small library.



After it seems to the front-endner that he has done a feature, he gives it for testing, and the tester convinces him that, most likely, the front-end is wrong.



What does the tester check? Firstly, that the feature works correctly under all platforms. We typeset directly for desktops, tablets, phones, for all browsers, the share of which on SERP (search engine results page) is more than, in my opinion, half a percent. In general, this is just a huge number of pieces that need to be checked. In addition, we have a fairly sophisticated logging system, and the tester checks that the developer there hasn’t done anything in it, that everything is fine.

And there is one common problem that layout designers always choose very beautiful data that fit together nicely and everything looks great. But the real world is often cruel and there are names on three lines, when they counted on one, or part of the data simply does not come, and everything disperses simply - it scares very badly. And, in general, the tester must verify that there is no such thing.



After the tester checked all this, he most likely returns the task to the front-end for revision. The front-end tender completes this, gives it back to the tester, and so on until victory. As soon as the tester believes that everything looks great, the feature rolls into production. Plus or minus like that.



And so we went through this cycle, in the end we got such a wonderful feature - a sorcerer of new devices. Everything seems to be fine, but there is one caveat: this cycle, which I am talking about, is quite long, it takes about two weeks. Of course, you can say that the developers are gouging, to fire everyone. What is there to make up for two weeks? I’m getting ready for the day. But actually this, of course, is not so. In fact, we simply have very serious quality requirements, that is, nothing should break: nowhere, under any circumstances, on any data and so on. And all this takes quite a considerable amount of time.

We did feature. What happens next?



Then a month passes, maybe more, and to some other front-end tender from another manager and designer - not from what they were in the first task - comes the task: “Do me a feature - a sorcerer of clothes. Here is the data for you, here’s the layout for you - go ahead, man! ”



And the front-end can either start doing it right away or think that - hmm - somewhere I already saw such a feature. Let’s find the source, maybe find another dude who did it. Let's rub it with him, maybe something can be taken out into the common component and not typeset from the beginning.



He finds this feature and understands the terrible: in spite of the fact that visually they seem to be similar - but what’s the same here - the fact is that the differences in details are just monstrous. That is, they have completely different specs, completely different. In principle, they are similar only in pictures, but even the captions for these pictures are of different colors, from different information: in one case, the price, in the other, some reviews are light blue. The front-end looks at it all: if you put this directly into the common component so, then, hell knows, maybe a feature will come in a week and I have to turn the API from this component into hell knows what. And in general, if all this is done, it will be necessary to re-test the old feature. In general, somehow it’s all been long, and I’ll make up for it better from scratch.



Okay. Takes, typeset.



I think you guessed what happens next.



Next comes the manager one more time.



Some, also with some feature.





And then another one.





And one more time. And for each of this we spent two weeks.



And we start to stand with something like that, like: “What the hell is going on? It seems that something is very wrong here! ”



If we try to formulate the problem less emotionally and without swearing, we come to the following. First, the features are done for a long time and this is to say the least, I would like to quickly.

Secondly, when someone smart sees that we have N similar features, it may come to his head - I don’t know if you paid attention or not, but in those pictures in five features the price was written in three different ways, which seems also not very good - and so, when someone notices this, it may come to his head, and let’s do something more or less the same here.

Oh, come on! Let's adjust the five layouts so that nothing breaks anywhere, and somehow bring them to a single look at least in some place, then we will test it all. In general, the problem is also very funny, but I don’t wish anyone like that.



Why is this happening? If you go down to the first level of this question, the answer is this: it happens because despite the fact that we have a component approach, all the trendy technologies, that’s all - for some reason, the features that we do cannot be reused. For some reason they are disposable (not features, but components), they are featured - and that’s all, with some rare exceptions.

If you go down a level deeper and ask: why is this happening? - then you can find two answers.

The first is that the developers are all very strange, suffer from garbage, fire all, hire new ones. But this answer is wrong.

The correct answer is as follows. There are two problems: the first - and it is actually small - the first problem is that for each feature the data comes in completely different, in the sense, generally. They come in the backend domain, we need to convert a lot of them, somehow use them. In short, this is some kind of work that should be done uniquely by feature. Okay, this seems to be solvable.



The second problem is more complicated - it's design. The fact is that for every feature, even a similar design comes different. Moreover, one often gets the impression that it differs in details not because it is necessary, product justified, but because “I am a designer, as I see it, I painted - everything, typeset”. And it seems that this is actually also a problem and the problem is much more serious.



With these thoughts in mind, we went to the designers and found out that their situation also soars, but it soars them from a design point of view. They don’t like that we have SERP, we have one page, and similar things on it are solved generally differently, in different ways. That is, they at first glance certainly look the same, but if you just open one feature and another - about the same thing - they will look different. And designers soar, they want consistency.

As a first step in the right direction, the designers themselves suggest: let’s begin to make prototypes, because it’s more difficult to prototype in prototypes than in Photoshop somehow unconsciously, to move something somewhere and so on.



Plus, this allows us to do the following: if designers start writing code - HTML, CSS - it means they can take out some common things in their components. For example, if a designer understands that now I am making several pictures in a row, this solves such and such a problem and this one hundred pounds will be useful to other designers - he can still consult with them at the same time - then he can put this into a common component, describe what it is, why it is, to describe what things in this component are configured, so that other designers can also use it. We have a repository called Depot for these components.



It looks like this. For example, the same component with pictures in a row, it is called a showcase. Designers now already know that they have a “showcase” component, and they try to reuse it in features. It describes which fields are configured in it, that is, which API it has, how to use it, and so on.



And if designers have components, then God himself ordered the front-end developers to start making the same library, but already on production technologies: with correct logging, for all browsers, and so on.



After we have the prototype and the data, the task is set to the frontend, where on the basis of the prototype we look at whether the components are common there or not common, if common components are used, we use or create such a component, and everything seems to be fine. The remaining steps with testing and rolling out in production do not change.

It seems to be getting better already, well, this approach has some problem. Come on, we'll look at her now.



Suppose we have such a simple feature - a sorcerer of tours. Where, in fact, the naked "showcase" and the title. Since the "showcase" was already done in one of the previous tasks, somehow tested, probably not bad, then we do this feature at a time, just use the "showcase", use the title. We hand over for testing. The tester also does not look very deeply anymore, because he knows that this is a common component, and he was already once tested. And it seems like it all rolls into production - also fast, this is not a week, it's more like days - and everything seems to be fine.



And in a day another manager may come and ask us such a feature - “market”.



It seems to be also a "showcase", but there is a nuance. Actually, our “window” does not know how to do this, and the front-end, who looks at it - at this task - he thinks: “Okay. “I need to modify the existing component of the storefront, put it into testing - check that all the features that use it have not fallen off, use it in my feature.” And ... "That component was made to you in two days," he tells the manager, "and I will do this for you for two weeks."



And the manager begins to look something like this: “Dudes! And here, and here is a common component - we kind of agreed on such an approach, but in one case will you do it for two days, and in the other two weeks? What the hell? ”



And we really think: “And what kind of garbage?” And, it seems, this is happening for the following reason: the fact is that the designer “showcase” has already managed to go ahead by the time this task has been set for us. The designer, of course, made a feature on his version of the showcase, we certainly did not know about it, and this is precisely our problem.



Therefore, we introduce a process such as versioning and synchronization. What does this mean? This means that the designer, when prototyping a component, - in the sense, prototyping a feature using some components - perhaps these components somehow develop, experiment. But when he realizes that a component in this form would be good to try in production - that's all, we are ready to use it - he will put a version for this component. And besides, he sets the task of the front-end to implement this version of the component. If after that he needs to change something in the component, this will be the next version.



It looks like this. And what does it give us?

Anyone: both the manager and the designer, having entered Depot, can see that the component of such and such version is already on the layout, and, therefore, the front-end can do this quickly. There is no component of such version on the layout yet, but there is such a task. If some manager needs this component, then, manager, be prepared to wait. Therefore, in the process of creating a design, a prototype for a feature, the manager and designer can agree on how to: quickly or absolutely drop dead.



The development scheme in this case changes as follows. What the beckenders do is understandable to everyone, we don’t touch them here. Designers prototype the design, simultaneously taking out the common components in Depot and modifying the existing ones, put down the versions for these components, set the tasks to the frontend, and in this place the same common components are synchronized with our library, but in the frontend, which is called the “designer” itself. After this, the task is set for layout, where we collect features from common components, and both the designer and the manager at this stage already know that the front-end providers have all the components, we can all use them quickly, or have to wait.

By the way, we made publicly available videos of the last two years of the conference of front-end developers Frontend Conf . Watch, study, share and subscribe to the YouTube channel .

We collect the feature, hand it over for testing, and roll it into production. Everything seems to be cool now, but we would not be us if we had not gone further.



I’m saying that designers take out common components in Depot. And let's think, what components may not be common at all? Seriously.

And we answered this question for ourselves as follows: in fact, all components are common. Even if you have used one thing now, it’s all the same good for you to describe it, as a designer, so that other designers understand why you came up with it at all, what it does, and maybe through some for half a year someone will need it and he will be able to either use it that way, or modify and use it. This time.

In addition, we have such large components as layouts, which say that you have a heading above, a curbstone under it, text to the right of the curbstone, a “showcase” under the text, and so on. For the most part, these are also some well-established constructions, which would also be nice to describe, describe how and when to use them and, in fact, to use.

What gives us this approach?



He gives us the following. If we have all the components in common, then what remains for us to implement the components directly under the feature? What she does? It turns out that with this approach, the component under the feature should do exactly one thing: convert the data that came in the backend format to a format that the API component of the “constructor” understands, often layouts, as the largest component.



If so, then the components under the feature degenerate into, in fact, an adapter. What is an adapter?



In our case, this is a pure function. If you have some kind of framework, it can be anything, but the following is important: it is important that the adapter does not affect the environment in any way, that is, it does not have CSS or JS client - all this logic is implemented in components; Adapters do not reuse each other, and adapters do not depend on each other either. In addition, one adapter is written strictly for one feature.

There seem to be a lot of limitations, but they don’t particularly interfere, but give us the following amazing result: if you edit some existing adapter, the worst thing — if everything is completely bad — that you can break is one particular feature - all. Guaranteed you won’t break anything around, because you don’t have client logic or client styles in it. No one except this feature is guaranteed to depend on this adapter simply for setting the task, and so on.



If you show this in the picture, then the whole scheme looks as follows. We have a code from the backend, which simply transmits “something”. The corresponding adapter is set against this “something”, which at the output says which component to render this feature, and what to apply to the input to this component. After that, it all falls into the “constructor”, which already generates the markup, and this markup goes to the user's browser.



This gives us the following, which, too, it seems to me, a drop dead, corollary: we have components in the library and we have all the components in common, and we also have an adapter. And with this approach, it turns out that the development of components and the development of features based on these components are actually separate processes.



At some points, they may be weakly connected for some features, but in general it looks like this. That is, designers develop existing components and create new ones, develop visual language SERP and that’s all. When the designer realizes that this component is ready for use in production, he fixes the version to her. By agreement with managers, we are implementing this version, testing it in all extreme cases, and in any situation we will make the component work well. And roll in production, separately. And if we need to make a feature - we just take and write the adapter. Since the adapter is guaranteed not to affect anything around, it cannot break anything, and so on, and uses those components that are already well tested, testing the adapter is essentially a trivial task. That is, you just need to check that on these back-end data, everything looks grocery plus or minus good - and that’s all, and that also rolls into production. Moreover, this upper branch of the process, it is really damn fast.



And now another interesting question: if the adapters are such a simple thing, they are only engaged in data conversion, they can’t break anything, then the fig needs front-end qualifications to write them?



And we thought and thought that we really didn’t need it. Let the adapters be written by those who need it most of all, that is, the manager who is responsible for the feature, or the analyst who really needs this feature.



But how to achieve this? There is one small problem: not all managers, not all analysts can do git, can do our flow, can commit to the repository, do pull-request and so on. But we are very lazy, so we still wanted the managers to do this, so we overpowered ourselves and did the following.



Firstly, we made a web-face for them through which they can write this adapter by connecting there the real data that the back-end has mined to him.



In addition, we made a site for them with documentation, because of course we can get into the source, see the API of our component, but the managers are lazy and git do not really like, so they need a separate site.





It looks as follows. The web interface looks like this - just for an example. On the left there is plus or minus real data from the backend, on the right is some kind of trivial adapter, and at the top there is a live-preview: how the manager’s feature will look in production. Perhaps the only thing that is missing is the buttons “pass for testing”, but we are working on it now.





In addition, we have documentation. I spoke about it in detail on some of MoscowJS. I’ll mention once again that this is all done on open technologies. There is JSDoc 3, which is awesomely customizable. This is probably the third version of the documentation, but with each step we are getting closer to our ideal. Even now, it is already possible to fully use it, which everyone is doing.



Actually, what did we end up with?



We came to the conclusion that instead of the weeks that I spoke about at the beginning of the report, features are done in hours or in days - all the same damn fast. In addition, they are often made not even by us, but by managers or analysts. For example, we had a case not so long ago, when an analyst sent us five new dash-witch sorcerers. Previously, one could only dream of such a thing. In addition, we are “free” - well, as “free” ... - we got full synchronization with the design and full consistency in the design. Since all features use common components, and all components are strictly common, when you update one component, the process is of course quite difficult if the component is used a lot where, but all SERP is guaranteed to be consistent. Just in architecture, in setting the task. And this is also very cool.

And the bonus we got is that now both managers and designers, and we work in the same terms: everyone knows that we have the components from which features are built; and in order to build a feature, everyone knows that you need to write an adapter, which converts such a simple thing.



Actually, I no longer have time to paint the scheme in detail, but it is dramatically different from what I showed at the beginning. The main feature in it is the following: that the development of components and the development of features based on these components are separate processes. Moreover, the development of features, if the feature is not some mega-demanding one, the process is very fast.



The decisions we made along the way. Firstly, instead of mockups, designers start making prototypes.

And since they make prototypes - they can carry out some parts of these prototypes into common components.

And since designers have common components, then we all the more want to do the same for ourselves, that is, common components also appear in our company.

In addition, we made versioning of components at designers and synchronization of design components with us.

And we also realized that, in fact, all the components we have in common, and if so, the development of a feature is essentially writing a simple adapter for data conversion, which builds a feature based on these components.

And if so, since we have the development of adapters and components, it seems that these processes are actually not always connected, so they can be put into separate processes. That is, to develop components separately - to develop features separately.

And besides, the development of adapters is a simple process, and we are lazy, so we made it so that we are not developing adapters.

Actually, what am I doing all this for?



To the fact that you can use our experience. Starting from some trivial conclusions in the spirit that if in order to dramatically accelerate, you need to completely change the whole process for a bunch of people, and now you are afraid to do it - do not be afraid. Even in Yandex it turned out. Despite the fact that we have a very, very many people, a very large number of people had to be taught to do things in a new way, but we managed. And since we managed, it means you are likely to do the same. In addition, you can use any of our abstractions - from our chips that we invented - in your project. For example, it seemed to me that the idea with adapters is pretty cool and can take root even in those systems that I didn’t even think of when I came up with this. Think about it, maybe it will come in handy.

In addition, you may find it useful to treat the project as a set of common components, and really common ones. Or, perhaps you can convince designers to start making prototypes, or even make Depot for them. In general, anything.

Most likely, each of these steps, when applied in the right place, will bring you profit.

In addition, if you have a specificity of work such that you make a lot of features on the basis of different data, but the features visually have some kind of relationship, that is, they are not completely unique in each particular case, perhaps you can take our whole process . It will certainly be a little complicated, but profit will bring you too, as it brought profit to us.

In general, this is probably all.

You can clap, rejoice and ask questions.

QUESTIONS AND ANSWERS

Question:
Adapters that are not written by front-end adapters - do they go through some kind of code review? And how much govnokod appears in the adapters?

Answer:
Look, now they are passing some kind of code review, but we want to consciously refuse this.

Why? Because, as I already said, by condition, adapters do not affect anything around them. And if so, then most likely the person who created the adapter, or the department, in general, those people to whom it belongs, most likely they will change it later. This means that they work exactly with what they wrote. They are not for us. And the absence of such a code review - it will actually allow this process to be accelerated. Now he is still a little tied to us, because, as I have already shown, there is no “pass to tests” button. But when we do all this, we want to distance ourselves from all of this, simply, like: write, we are more or less all the same.

But testers will check this, of course, anyway, just in the case.

Question:
I have two questions. First: how long did it take you to make this whole ecosystem around components, adapters - to the end? Second: do your designers use git?

Answer:
I will answer in order.

It took quite a hell of a time, that is, it probably took us a year and a half, maybe a little more. But we have a lot of people, so initially, for example, it generally seemed that this process might not converge. But we managed - everything is cool!

And secondly, the designers here are really awesome people. I respect them immensely, not only because they use git. I, I think, have already told someone - I know our designer who knows Haskell and writes on it, so there are very serious guys.

Question:
I have a question about prototypes. Please tell me in more detail: what is included in them, what are they like and what did you make designers do? Because if I go to the designer now and say: “You need to make up the code,” he will just laugh hysterically.

Answer:
Look, we are actually very lucky with the designers in this regard, because the guys who are the main designers are technically savvy people, that is, their HTML-CSS is not scary, for example.

Initially, there was an idea that at least HTML and CSS would write, and what they could not do, would be described in words. But in the end, at some point, when we came to the designers, they already had, generally speaking, their own react-like framework - they wrote and made their prototypes on it. In general, they are some kind of monstrous guys. They just took - ok - the code, so the code, let's do it.

In fact, I understand that not all designers are like that, but right in the basic condition it’s enough that it is some kind of HTML with CSS. And if a designer cannot make a chip, let him simply describe it with words, but it’s important that it is in a centralized place. So that another designer could come to see - yeah, he behaves this way.

Like that.

Question:
The previous question was close, if I understand correctly, then in Depot you have stored ready-made HTML pieces that you can use. That is, the designers essentially prepare them themselves?

Answer:
Essentially, yes. Everything is a little cooler with us - as if I didn’t invest in it - in fact, it doesn’t store HTML pieces, but directly templates that designers can use, moreover, design templates: written by designers for designers. But the HTML chunks in this place would also work. Yes, indeed, the designer can go into this service - I’ll try to scroll to where he was now - in general, the designer can go into this service and see what components are there. Enter, and the information that is in this service is enough for him to use this component, and to understand how he behaves.

Here, of course, we don’t see a damn thing, but there is a list of components. The designer is looking and so on.

Question: The
second question: if everything, any, even the smallest entities are carried out into common elements, then how do they be structured? Because there you can drown from specific buttons, icons, pixels.

Answer:
I agree. Look, while it all lies flat list, but there are two big buts.

First, we have a BEM, thanks to which, for example, we don’t have twenty options for buttons - we have one button with customizable behavior, that is, it has themes, it has some kind of customization, and it is us in this place saves. Although sometimes duplication does occur, we try to get rid of it.

And secondly, really, now we want to break it down into two lists, but the truth is only two. The first one will contain reinforced concrete components that have already passed the test of time, they really use everything, in short, things that are difficult and expensive to edit, but they will affect a lot of people. And in the second - those same components that are used once or twice and in the future can grow into the first category.

Question:
And, accordingly, from the moment you switched from prototypes to prototypes, it turns out that you abandoned the concept of pixel perfect, do I understand correctly?

Answer:
Yes and no. On the one hand, it is clear that we do not open two pictures in Photoshop and do not look: so what is going on here? But on the other hand, we have not come to this yet, but we are actively moving forward, since all the components - they should be very close in any one, and we and the designers use different code, but the same set of components. Just, also by condition, our components cannot differ much, and everything seems to be fine in this place - that is, there is not pixel perfect, but close to that.

If dramatic differences appear in our components, we will most likely rake at some point, so we try to get rid of this.

Question:
That is, testers mainly conduct such more functional testing?

Answer:
A component on production - yes, and we are the only ones who look at design components and try to implement it in a similar way. That is, if, for example, the designer has a table with some kind of div c “display: table;”, and if we don’t have any objections, we will do the same so that later on, both us and them will develop approximately the same way expensive or cheap.

Question:
You advised us to try to implement your experience, and what tools did you use for this? You probably wrote a bunch of "bicycles" there, right? How much will it cost if I want to implement it in my company?

Answer:
Look here, what’s the matter, it’s not a matter of specific technologies — that you need to take this “bicycle” and put it in your place — the matter is in the approach. Even at the moment when you start to think about the project differently: here I have a page, and we somehow typeset it, and that’s all; but how real is it about a set of components ready for reuse - whatever you use there, I don’t know, a plate in Excel, for example. This is likely to bring you some benefit.

Question:
No, but you talked about the fact that the manager can go in, it’s convenient there, almost to write the adapter yourself. This system was developed - how much is it? If I want to introduce a similar?

Answer:
This system is actually quite cheap. The most expensive was moving towards this approach. Now, after the story, every step seems obvious and understandable - but what is there to do? In fact, when we all thought about it, there were a bunch of options and, in general, what we came to like, in principle, we liked - this is the most valuable.

Question:
But there are no ready-made solutions on the Internet that can be connected? And you do not spread?

Answer:
I am afraid I can not offer them to you, simply because we have our own technology stack. That is, even if these solutions were, they would be for the BEM stack, which most likely does not suit you. Therefore, here, unfortunately, no.

Question:
How did you make the manager want to create these components himself, or rather build them, write these descriptors?

Answer:
Very simple! Case, look, in the following. The fact is that the work of the front-end vendors is a fig, and when the manager comes to you and says:
- How much can you do this task?

- Well, we have some other project there for two weeks, and then maybe something else, and maybe three weeks later I’ll sit down to your task and will do it for half a day. And you can - here you have a web tool - take it and do it yourself now.

From the point of view of the manager, the choice is clear, it seems to me.

Question:
The question is, what about the adapter? This component must then be removed somewhere, that is, you need to determine the place and how it is called, and so on. How does this happen? Who is doing this?

Answer:
Look, in our specifics, namely our project, the place we have is quite understandable. We have a body kit in the form of a cap, left column, footer - this is all clear. And inside there is a list that simply goes through what the data sent: they send us an array with objects in which only the type is specified, in fact the source type, and there can be any kind of besides. Actually, in this place, we call the adapter mechanism, which converts this data and feeds the mechanism of this “constructor” as an input - it selects the right component, calls it with the necessary API, returns HTML, and the element is rendered one by one.

Question:
But this data, which determines the structure, is on whose side are it stored, and who rules it?

Answer:
Look, the data that determines that this output result will be under it, and not vice versa - it is on the backend, because we have the concept of ranking. All this is machine learning, the whole fucking thing. And within the framework of one component, who determines what type of text is according to the table, and not vice versa, it can determine either the layout component, if it is hard enough, or if the layout component is flexible enough, the manager himself can determine in the adapter. Within one feature, he has freedom.

Question:
That is, data from the backend appears, it looks if there is an adapter, then this is displayed. If not, then ...

Answer:
If not, then - oops! - nothing is displayed.

Question:
Thank you very much for the report. It’s very interesting, and very familiar, because at the company several times we used an almost identical development approach. But the question is not even about technology, but there is such an urgent problem: the fact that while this engine, generator is being developed, everything works wonderfully, but a moment arises when the technologies become obsolete and need to be rewritten. Actually, this sometimes even casts doubt on the part of managers in general, in principle, this approach. The question is how much resources you spend on keeping technology up to date and updating it.

Answer:
Look, if I understand you correctly, this is a question a little about another area. That is, no matter what technology it is implemented - it is likely to work anyway. Technology update is some kind of parallel process. It occurs in parallel with this movement. Now I can’t even tell you how many resources, but some are leaving: we are constantly changing something, we are constantly developing template engines, then this. But, it seems that in the framework of this project, this is not dramatically affected. That is, I can’t understand how this is related.

Lead answer:
Denis and I have already discussed this thing. And there, specifically in Yandex, they used such a strange thing as BEM-JSON, and they all had templates, in fact, in this jason like that. It’s complicated, it’s not clear why this thing was needed, it’s so scary.

Speaker’s remark:
I’ll tell you after the report — a good thing.

Lead answer:
And then it turned out that, you know, you can change the technological stack inside, and completely leave this JSON. And the same thing, they can take on the site and change the framework, which renders the view there - to replace with React or with something else. But this whole sheet, the whole backend - it all remains the same. In this case, specifically to the project, it is easily replaced.

And to rewrite this thing here is also probably not very difficult, here are a bunch of separate small tools, - took it and rewrote it under a new stack, for example. With this they are doing well, it seems to me.

Question:
You say 30 front-end developers, you wrote such a cool thing. Now, instead of two weeks, it takes hours and days. But at the same time, you say that it’s such a load anyway that managers were even forced to make adapters. And what are these 30 front-end developers doing now?

Answer:
Ah! Easy! Easy! I forgot to tell the most important thing.

Now, while the project is being implemented, it has already been pumped into production. Now, in fact, I also drove only upstairs, it took me 35 minutes. In each of the places there are some nuances, some problems that should be further developed. Actually, now we are doing this. Plus, now there are some unique pieces in unique places, and some of the guys are engaged in them.

But when it all takes root, in the sense, completely in the minds of all managers, when all the managers are real, like, how to make a feature: well, now I’ll go and write the adapter - it's easy right away.

Then it’s really not clear what such a crowd of people will do, and this bothers me a little.

Question:
This whole thing is now implemented in SERP, right? That is, on one page, on one search results? But is it planned to scale somehow, that is, to other projects, neighboring ones, somehow?

Answer:
It is partly planned, but this question is actually very topic-related and rather complicated.

I would like to scale it, yes, no questions asked - but ... This approach with a common library - it works very well when you have one and a large project, because it is essentially a folder in the project. You need to fix the component - you rule, everything, everything is fine here. If it’s really possible to put it into a separate git repository, if you don’t have any Perforce that can do this well, then it’s very easy to get rid of difficulties in this place due to queues, due to conflicts, due to the fact that you just to fix the audit, and there different people are figuring, it’s all tested differently. In general, problems can begin here.

We are looking in this direction. We have not yet thought how to solve them. Maybe we’ll decide, and maybe I’ll tell you about it too, but so far this lives on in the framework of one project. We are actively working on it now, and that’s all.

Lead answer:
Also, the technological stack on different projects may differ slightly.

Answer:
Maybe, yes. But it would be possible to implement at least in similar ones, but it’s also because of - it’s unclear how to commit to one library at the same time — that is, we have thirty of ours, and also from all other projects, without breaking anything , because each dude has expertise only within the framework of his project.

In general, this is an interesting problem, maybe we will solve it, maybe I will talk about it.

Lead answer:
See you in a year, and they will tell us how it happened.

Answer:
This does not work well, because if you have all the components common, then this is a separate team, this will be “all developers” or most of them. Because besides components and infrastructure there is nothing more to saw.

Question:
Come on two questions, first: how many people worked on all these things, so that designers understand, managers, who do you have there - that's it? And in some ways, it looks like Ucoz, but without ads, it seems to me not?

Answer:
The first is how many people worked. At the very beginning, it was one front-end - this is me, a designer and two managers. At some point, the team grew to as many as five or four front-end-providers, - at a time when it was all actively, actively, actively sawed, all at once. Now in the team that deals with core, there are three people, namely three front-end, about designers and back-end, well, one designer. How many beckenders are behind all this, I honestly don’t know.

And now we have active work - it is to teach everyone to do everything correctly. That is, the guys have already become accustomed to the idea that yes, it’s necessary, but there are some other overlaps due to the fact that stupidly there, in total, it affected a person for a hundred probably - a lot. Now we are doing about this.

The fact that it looks like Ucoz - yes, something like that. This is very similar to CMS, but I don’t think that in the context of such a project, someone thought that a similar approach was generally applicable. And it is applicable so suddenly. Which is cool.

Contacts

» Lostsoul@yandex-team.ru

This report is a transcript of one of the best speeches at the professional conference of front-end developers Frontend Conf .

Starting this year, we decided to separate the " Frontend Architecture " section into a separate track at the conference of developers of highly loaded systems HighLoad ++ . We invite speakers and listeners!