Constructor

Denis Pesya ( Yandex )

My name is Denis, I work in Yandex, and if more precisely, I am developing the frontend for the search results page.

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

Today I’ll tell you about our awesome internal thing as a Constructor, how it came out, why, and how we came to all this. It seems to me that the decisions that we made in the process of implementing this remarkable figy may not be useful only to us within our company, our team, but also to a whole multitude of other teams in your, for example, companies. I do not know if I mentioned it or not, but the project is really very cool. Why - I'll tell you now.


')
Now, in the era before the “designer”, before we implemented it, developing even a typical product feature, the most standard one, took an awesome amount of time: around two weeks, maybe, sometimes more, sometimes less, I will focus on this in more detail. And now, when the Designer is implemented, we have precedents, when features are done in a day - and the same complexity - and maybe less. And, which is the coolest, often not even by us, not by front-enders. In general, it seems to me that this is just some awesome fabulous result, but nevertheless it is true, and as we have come to this, I’m going to tell now.



But first things first.

As I have already said, I am working on the search results page, if for some reason you have suddenly used Yandex for some reason - by the way, I advise you, you probably have already seen it. If you have not seen it, then look at it, it looks like this.



You can drive in your laptops, it is even cooler in person. 35 or even 37 or 37 front-end vendors from 6 cities work on it. In addition to front-endders, there are managers, designers, testers, some huge number of backend guys.



In general, if all sfotkat, get something like this.



What are we all doing?

We make a lot of different features, a significant part of them is food.



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



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



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



So, suppose that we need to make a feature. How does it all start? First, the guys from the backend should get the data. For example, if we make a feature about new devices — features of this kind in Yandex are often called “witches”, if I repeat this word again, do not be intimidated, it’s just a feature, so why is it not important. So, for features it is necessary to eliminate the data.



This data reaches us in the form of a JSON chick, and the JSON chick is very specific for each feature. That is, if this is a koldunshchik 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 this were a feature about social networks, there would be the user's first name, last name, something else, his marital status, in general, some such figot in the subject area of ​​the feature.



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



The design at that time we had imagined them as layouts, that is, in fact, pictures, but with beautiful, perhaps, specifications, where all the indents, sizes, and so on are indicated. That is, we were generally comfortable enough.



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



After the frontender seems to have done the feature, he gives it to testing, and the tester convinces him that, most likely, the front-endender is wrong.



What does the tester check? First, that the feature works correctly under all platforms. We impose immediately for desktops, tablets, phones, for all browsers, the share of which on the SERP (search engine results page) is more than half a percent, in my opinion. In general, this is just a huge number of pieces that need to be checked. In addition, we have a rather complicated logging system, and the tester checks that the developer is not in it anywhere, that everything is fine.

And there is one common problem that designers on mock-ups always choose very beautiful data that fits well together and everything looks great. But the real world is often cruel and there are names on three lines, when you counted on one, or some of the data just does not come, and everything just goes around - it’s very scary. And, in general, the tester should check that there is no such thing.



After the tester has checked all this, he, most likely, returns the task to the frontier for revision. This frontage modifies, gives back to the tester, and so to the victorious. As soon as the tester thinks that everything looks great, the feature rolls into production. Plus or minus so.



And so we went through this cycle, we finally had such a wonderful feature - a sorcerer of new devices. It seems all is well, but there is one nuance: this cycle, which I am talking about, is quite long, it takes about two weeks. Of course, you can say that the developers are dumb, everyone should be fired. What is there to make up two weeks? I for one day now. But in fact this is certainly not the case. 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 some time.

We have made a feature. What happens next?



A month goes by, maybe more, and some other front-line manager from another manager and designer — not because they were in the first task — comes the task: “Make me a feature — clothes maker. Here's the data for you, here's your layout - go ahead, figach! ”



And the front-endander can either start doing it right away, or think that — hmmm — somewhere I have already seen such a feature. Let me find the source, maybe find another dude who did it. Let's try it with him, maybe something can be taken out into a common component and not to impose from the beginning.



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



Okay. Takes, imposes.



I think you guessed what happens next.



Next comes the manager one more time.



Some, too, with some fichey.





And then another.





And once more. And for each of this we spent two weeks.



And we start to stand approximately with such a facial expression, like: “What the hell is going on? It seems there is something very wrong! "



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

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

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



And why is this happening? If you go down to the first level of this question, the answer is as follows: this is because, despite the fact that we have a component approach, all modern 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 a feature - and that’s all, with some rare exception.

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 garbage, dismiss 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 is generally different, in the sense in general. They come in the subject area of ​​the backend, we need to transform them a lot, somehow use them. In short, this is some kind of work that should be done uniquely under the feature. Well, it seems to be solved.



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



Approximately with such thoughts we went to the designers and found out that their such situation also soars, but it soars them from a design point of view. They do not like the fact that we have a SERP, we have one page, and similar things on it are solved altogether in different ways, in different ways. That is, at first glance, they certainly look the same, but if you just open one feature and another - about the same thing - they will look different. And designers it soars, they want consistency.

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



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



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



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



After we have a prototype and data, the task is set on the front-end, where we look at the basis of the prototype, if the common components are used or not common, if the common components are used, then 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 better already, well, this approach has some problem. Let's take a look at it now.



Suppose we have such an unpretentious feature - a wizard of tours. Where, in fact, the naked "showcase" and the title. Since we already had a “showcase” in one of the previous tasks, it was somehow tested, probably not bad, we do this feature on time, just use the “showcase”, we use the title. We pass in testing. The tester is also not very deep looking, because he knows that this is a common component, and it has already been tested. And everything seems to be rolling in production - also quickly, this is no longer a week, these are more days, and everything seems to be fine.



A day later another manager may come and ask us just such a feature - the “market”.



It seems to be also a “showcase”, but there is a nuance. In fact, our “showcase” doesn’t know how to do that, and the front-endanger, who looks at her — at this task — he thinks: “Okay, okay. I need to modify the existing component of the storefront, pass 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 says to the manager, "and I will do this for you in two weeks."



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



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



Therefore, we introduce such a process as versioning and synchronization. What does this mean? This means that when a designer prototypes a component, in the sense that he prototypes a feature using some components, it is possible that he somehow develops and experiments these components. But when he realizes that a component in such a form would be good to try in production - that's all, we are ready to use it, - he will install a version for this component. And besides, he sets the task for the frontender 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?

Any: both the manager and the designer, having entered Depot, can see that a component of such a version is already on the layout, and it means that the front-endender can do it quickly. There is no component of such a version on the layout yet, but there is such a task. If any manager needs this component, then the manager - be prepared to wait. Therefore, in the process of creating a design, a prototype for the features manager with a designer can agree, as it should: quickly or completely drop dead.



The development scheme changes as follows. What the backenders are doing is clear to everyone, we don’t touch them. Designers prototype the design, simultaneously putting the common components into Depot and modifying the existing ones, putting versions to these components, setting tasks on the frontend, and in this place synchronizing with our library of the same common components, but already in the frontend, which is called the “designer”. After this, the task is put on the layout, where we collect features from the common components, and the designer and the manager at this stage already know that all the components of the front-end vendors are there, whether we can use everything quickly, or have to wait.

By the way, we posted in open access the video recordings of the last two years of the front-end Frontend Conf conference. Watch, learn, share and subscribe to the YouTube channel .

We collect feature, we hand over in testing, we roll in production. It seems everything is cool now, but we would not have been if we had not gone further.



What I am saying here is that designers take out common components in Depot. And let's think about what components may not be common at all? Seriously.

And we answered this question for ourselves as follows: in fact, all the components are common. Even if you have some kind of thing now used once, it would still be good for you to describe it, you 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 it will be needed by someone and he will be able either to use it or to modify and use it. This time.

In addition, we have such large components as layouts, which say that you have a heading on top, a stand under it, a text to the right of the thumb, a text in your showcase and so on. Most of them are also some well-established structures that would also be good to describe, describe how and when to use them and, in fact, use them.

What does this approach give us?



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



If so, then the components under the feature degenerate into, in fact, the 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 has neither CSS, nor JS client - all this logic is implemented in the components; adapters do not reuse each other, and adapters are independent of each other too. In addition, one adapter is written strictly for one feature.

The restrictions seem to be many, but they don’t really interfere, but give us the following amazing result: if you are correcting some existing adapter, the worst thing - if everything is really bad - that you can break, is this particular feature - everything. Guaranteed, you will not break anything around, because you have neither client logic nor client styles in it. Guaranteed from this adapter, no one except this feature does not depend on the formulation of the problem, and so on.



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



This gives us the following, too, it seems to me awesome, a consequence: 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 loosely connected for some features, but on the whole it looks like this. That is, designers develop existing components and create new ones, develop the visual language of the SERP, and here it is. When the designer realizes that this component is ready for use in production, he fixes her version. We, by agreement with the managers, implement this version, test it in all extreme cases, in any situation we 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, can not 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 checkthat on this Beckend data, everything looks good, plus or minus, good - and that’s all, and this also goes to production. And this is the upper branch of the process, it is really damn fast.



And now another interesting question: if adapters are such a simple thing, they only deal with data conversion, cannot break anything, then you need a front-end qualification to write to them?



And we thought so, and thought that it really is not needed. Let the adapters be written by those who need it most, that is, the manager who is responsible for the feature, or the analyst, who needs this feature.



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



First, we made a web-face for them, through which they can write this adapter, connecting there the real data that the backeder had given him.



In addition, we made a documentation site for them, because of course we can get into the source code, see the API of our component, but the managers are not very fond of git, so they need a separate site.





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





In addition, we have documentation. I told her in detail at some MoscowJS. Now once again I will mention that this is all done on open technologies. There is JSDoc 3, which is fucking 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 is what everyone is doing.



Actually, what did we eventually come to?



We came to the conclusion that instead of the weeks that I talked about at the beginning of the report, features are done in hours or days — it's pretty darn fast anyway. 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 we had five new witch-dash-fichey nafigachil analyst. Previously, this could only be dreamed of. In addition, we are “free” - well, like “free” ... - we got complete 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 heavy, if the component is used a lot where, but then the entire SERP is guaranteed to be consistent. Just by architecture, by the formulation of the problem. And this is also very cool.

And with a bonus, we received the fact that now both managers and designers, and we work in the same terms: everyone knows that we have components that make up features; and to build a feature, everyone knows that you need to write an adapter, which is such a simple thing - converts data.



Actually, I don’t have enough 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. And the development of features, if the feature you do not have any mega-demanding, - the process is very fast.



Decisions that we made on the go. First, instead of models, designers are starting to make prototypes.

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

And since designers have common components, we even want to do the same for ourselves, that is, we also have common components.

In addition, we made component versioning by designers and synchronized design components with us.

And we realized that, in general, we have all the components in common, and if so, the development of a feature is in essence the writing of a simple data conversion adapter, 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 related, so they can be brought 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 do not develop 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 accelerate dramatically, you need to completely change the whole process for a lot 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 very, very many people, a very large number of people had to be taught to do something new, but we managed. And once we have done it, it means that you, most likely, will also do it. In addition, you can use any of our abstractions - from our chips that we have invented - in your own 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 did not even think about when inventing this. Think about it, perhaps it will be useful to you.

In addition, you may need to treat the project as a set of common components, and really common components. 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, being applied in the right place, will bring you a profit.

In addition, if you have the specifics of work such that you make many features based on 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 process entirely . It will certainly be a little difficult, but a 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-enders - do they go through some kind of code review? And how much govnokoda appears in the adapters?

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

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

But testers will certainly check this anyway, just just in case.

Question:
I have two questions. First: how long did it take for 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 while to hell of 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 seemed that the process might not converge. But we managed - everything is cool!

And secondly, our designers are really awesome people. I respect them immensely, not only because they use git. I, to my mind, have already said to someone - I know our designer, who knows Haskell and writes on him, so there are very serious guys there.

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

Answer:
Look, we are really very lucky with the designers in this regard, because the guys who are the main designers of 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 should be written, and what they could not do, they were described in words. But in the end, at some point, when we came to the designers, they generally had, generally speaking, their reactive framework - they wrote and made their prototypes on it. In general, they guys are some monstrous simple. They just took - ok - code so 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 for it to be some kind of HTML just with CSS. And if the designer cannot make some kind of chip, let him describe with words simply, but it is important that in a centralized place. To another designer could come to see - yeah, behaves this way.

Like that.

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

Answer:
In fact, yes. We have everything a little bit even cooler, as if I didn’t invest in it, it’s not actually the HTML pieces that are stored there, but the templates that designers can use, moreover, they are design templates: written by designers for designers. But HTML-pieces in this place would also fit. Yes, indeed, a designer can go into this service — I’ll now try to squander where he was, in general, a designer can go into this service and see what components are there. To enter, and the information that is in this service is enough for him to use this component and to understand how he behaves.

Here we certainly can not see the fig, but there is a list of components. The designer looks and so on.

Question:
The second question is: if everything, any, even the smallest entities, are put into common elements, how does their structuring occur? Because there from the buttons specific, icons, pixels, you can drown.

Answer:
I agree. Look, while this is all a flat list, but there are two “but” big ones.

First, we have BEM, thanks to which we, for example, do not have twenty options of buttons - we have one button with flexible behavior, that is, it has themes, it has some kind of customization, and we have it in this place saves. Although sometimes this duplication really happens, we try to get rid of it.

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

Question:
And, accordingly, from the moment you moved from mock-ups to prototypes, you, it turns out, 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 happening here? But on the other hand, we haven’t come to this yet, but we are actively going, because all the components, they should be very close in any one, and we, and the designers, let us use different code, but the same set of components. Simply, according to the condition, our components cannot differ much, and in this place, everything seems to be fine - that is, there is not a pixel perfect, but close to it.

If we have dramatic differences in the components, at some point we will most likely ogrebem, so we try to get rid of it.

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

Answer:
The component on the production is yes, and we are the only ones looking at the design components, and we are trying to implement it in a similar way. That is, if, for example, a designer has a table with some div c “display: table;”, and if we do not have any objections, we do the same so that later on we will have approximately the same development as we develop 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 your “bikes” 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 about specific technologies, - that you need to take this “bicycle” and put it in your house - this is about the approach. Even at that moment when you start thinking about a project not as: here I have a page, and we somehow impose it, - and this is all; But how realistic is it about a set of components ready for reuse - whatever you use there, I don’t know, an Excel table, for example. This is likely to bring you some benefit.

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

Answer:
This system is actually quite cheap. The most expensive was the movement towards this approach. It is now after the story, every step seems obvious and clear - what is there to do? In fact, when we all thought about it, there were options for it, and, in general, what we came to like in principle is the most valuable thing.

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

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

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

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

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

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

Question:
The question is that with the adapter - is understandable. This component must then be derived somewhere, that is, it is necessary to determine the place and how it is called, and so on. How does this happen? Who does this?

Answer:
Look, in our specifics, namely our project, our place is quite understandable. We have a kit in the form of a cap, left column, footer - it's all clear. And inside there is a list that just goes through what the data sent: they send us an array with objects that basically only the type is indicated - essentially the type of source - and besides that there can be any fucking information. Actually, in this place, we call the adapters mechanism, which this data converts and feeds to the input also the mechanism of this “constructor” - it selects the correct component, calls it with the necessary API, returns HTML, and the element is rendered under one.

Question:
But these data, which define the structure - they are stored on which side, and who rules them?

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

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

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

Question:
Thank you very much for the report. Very interesting, and very familiar, because several times in the company we used an almost identical approach to development. But the question is not even about technology, but there is such an urgent problem: the fact that while this engine is being developed, the generator, and everything works wonderfully, but there is a moment when technologies become obsolete, and it needs to be rewritten. Actually, it is sometimes generally questioned by managers in general, in principle, this approach. The question is how many resources do you have to maintain the relevance of technologies and their updating.

Answer:
Look, if I understand you correctly, this question is a little bit about another area. That is, whatever the technology to implement it - it will most likely work anyway. Technology update is a kind of parallel process. It occurs in parallel with this movement. I can’t even tell you how many resources, but some are leaving: we are constantly changing something, constantly developing template engines, then - that. But it seems that under this project, it does not dramatically affect. That is, I can not understand how it is connected.

Host 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 one such. It is difficult, it is not clear why this thing was needed, it is all so terrible.

Speaker Replica:
I'll tell you after the report - a good thing.

Host answer:
And then it turned out that, you know, you can change the technological stack inside, and leave this JSON completely. And the same thing, they can take on the site and change the framework, which renders view there - replace it with React or 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 it’s probably not too difficult to rewrite this thing either, here are a bunch of separate small tools, I took it and rewrote it under a new stack, for example. With this, they are fine, it seems to me.

Question:
You say - 30 developers on the front end, 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 still such a load that the managers were even forced to make adapters. What are the 30 front-end developers doing now?

Answer:
BUT! Easy! Easy! The most important thing forgot to tell.

Now, while the project has been implemented, it has already been rolled out in production. Now, in fact, I, too, chased only tops, it took me 35 minutes. In each of the places there are some nuances, some problems that need to be improved. Actually, we are doing this now. Plus, now there are some unique things in unique places and some of the guys are engaged in precisely them.

But when all this is implemented, in the sense, it is completely in the minds of all managers, when all managers are real, such as how to make a feature: well, I’m going to write an adapter, it’s simple right away.

Then it is really not clear what such a crowd of people will do, and this worries me a little.

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

Answer:
Partly planned, but the question is actually very relevant and quite complex.

I would like to be scaled, yes, no questions asked - but ... This approach with the shared library - it works very well when you have a single project and a large one, because this 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 make it into a separate guitar repository, if you don’t have any Perforce that does a good job with it, then it’s very easy to complicate things in this place at the expense of queues, due to conflicts, because you just need to to fix the audit, and there different people figachat, it is all differently tested. In general, there may be problems.

We are looking in this direction. Not yet thought how to solve them. Perhaps, we will decide, and, perhaps, I will also talk about this, but for now it lives within the framework of one project. We are now actively finalizing it, and this is all.

Host answer:
Technological stack may differ slightly on different projects.

Answer:
Maybe, maybe, yes. But it would be possible at least to introduce them in similar ones, but there, too, because of - it is not clear just how to commit to everyone at the same time in one library - that is, we have thirty of ours, and still there 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, perhaps we will solve it, perhaps I will tell you about it.

Host answer:
In a year we will see you, and they will tell us how it happened.

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

Question:
Let me ask you two questions, first: how many people worked on all these things, so that the designers could understand, the managers, who do you have all of them? And somehow it looks like Ucoz, only without ads, it seems to me, no?

Answer:
The first is how many people worked. At the very beginning it was one fronder - this is me, a designer and two managers. At some point, the team has grown to as many as five or four front-tenders, - at the moment when this is all straight, actively actively sawed, everything is straight away. Now there are three people in the team that deals with bark, namely three front-end vendors, about designers and backenders, well, one designer. How many backenders are behind all this, I honestly do not know.

And now we have active work - to teach everyone to do everything correctly. That is, the guys have already got used to the idea that yes, this is necessary, but there are some other lining due to the fact that stupidly we have there in the amount that affected a person over a hundred probably — a lot. Now we are doing about it.

The fact that it looks like Ucoz - yes, something like this. This is very similar to CMS, but I do not think that in the context of such a project, someone thought that a similar approach is generally applicable. And it applies so suddenly. What is cool.

Contacts

» Lostsoul@yandex-team.ru

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

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