Frameworks are not only on the backend, but also on the frontend (and there are generally in a bunch of other languages that are not related to the web). Among them are React, Angular, and Vue. JS that makes it easier to write code for user interactions. At the same time, such frameworks are not too SEO-friendly, and sites on them are likely to have problems with promotion. Instead of transmitting the entire HTML structure to the browser, the server part (backend) of such sites gives specially prepared data in JSON format so that the front-end JS framework can output the page based on them. It’s the type of data that Google just does not understand. But this can be circumvented if you prepare this data in a special way — you don't need to render it immediately.

What is bootstrap

Twitter Bootstrap is a UI library, a set of individual elements, although in general it can also be called a framework for CSS, since it helps in interface development.

The Bootstrap 12-column grid, which is used for site layout and which you might have heard, is part of Twitter Bootstrap. Also inside the framework there are standard types of elements, buttons and everything. It often happens that frameworks are not monolithic and consist of several parts that can be used separately. 

Designing the database structure

Here you have a technical task: it contains goods, buyers, reference books, shops, cities and so on. But while specific entities are not highlighted here, the relationships between these entities are not painted, the fields for them are also not specified. And that's all it takes. Therefore, one of the first tasks of designing the database structure is for the programmer to draw up a diagram with the structure of entities, their fields and relationships. First of all, for myself, in order to understand for myself how it happens inside (and so that later it does not suddenly turn out that the remnants of the goods have a dependence on the store, and this was not taken into account).

In fact, in order to create a database structure, a programmer needs to read all the TOR, understand what is there, figure out what connections are there, ask the project manager additional questions and only then draw and create tables (In Bitrix — infoblocks). Yes, something can be finalized and added later, but if something is not taken into account, it will have to be at least partially redone.

What are infoblocks and how do they differ from highload infoblocks

If a database is a repository of some information, then infoblocks are a "wrapper" from a database with a beautiful interface, with some additional features (SEO, for example) and with the ability to create a section structure, link elements, etc. Plus infoblocks: convenient for a content manager because of the mass default features.

Minus: because of this "heaped-up", they create a large load on the server (there is too much extra in them), and on huge amounts of information (millions of records) they work slowly.

Because of the latter, Bitrix came up with highload-infoblocks, but this is their marketing name. These are directories or tables for data — less versatile and designed for narrow tasks, but due to the lack of “bells and whistles” they work faster.

Crowns and agents — what it is, how it works and what it is used for

For many sites, it is necessary to periodically perform some tasks: for example, perform an exchange with 1C, increase some counter on the main page, and collect data from somewhere else. Crown — to help. This is a special program running on the server side that performs periodic tasks. She has a special file where scripts are written for launching and the frequency of these launches.

This file is edited manually — a separate line is created for each task inside the crown. When laying out the site on a real working server, each line of the crown must also be manually transferred. If something has been finalized in the new sprint, and a new periodic task has been added, we must not forget to "go" to the server and add it with our hands. It's a chore.

Bitrix has come up with its own mechanism for periodic tasks. Only one line is added to the cron file, in which Bitrix says: "Complete your periodic tasks." Bitrix should describe in a special format what it should do and with what frequency. Each such entry is called an "Agent" in Bitrix terminology.

How does the cron launch of Bitrix agents work

The plus of agents is that tasks do not need to be managed separately, such a structure is easier to deploy, and transferring a site from one server to another (if suddenly needed) is easier to do, and nothing will be lost during the transfer. If the crohn's task file suddenly turns out to be damaged, it is easier to restore one record than 15.

If nothing is configured on the crown (for example, there is no way to edit the crown — this sometimes happens on shared hosting), Bitrix will still perform periodic tasks - with restrictions and slightly flawed, but it will. There are two possible execution options: 1) on the server side (agents via cron) and 2) during the page request, on hits (hit) when the page opens and Bitrix executes some agent. The second option is fundamentally worse, because there is a limit on the time to create a page for the client (often no more than one minute and this is a certain amount of memory). But who wants to wait for some agent to work out (which, moreover, may not be optimally written) if you just need to update the page, for example, news?

In a nutshell about integration

Integration is the use of some data from a third—party system inside the site. Most often we have integration with 1C: we take goods and prices created by the customer so that we can sell goods both online and offline.

There is a written module for integration with 1C in Bitrix — it is not always enough (when additional fields are needed, for example), but more often we use it. In any case, it takes some time to set up, although we take more or less ready-made code. Integration with third-party services (with API or something similar) is almost always written from scratch.

API — Application Program Interface, some kind of interface of some program that describes standard methods (which can be transmitted using the API) with standard answers (what answers can be received for requests).

To integrate via the API, the programmer must take a description of this system, see how it works: the site should send a request to it or it should be the first to "knock" on the side of the site. You also need to see in what format it communicates (in what data format and by what protocol), what data it needs to take and how it will report them (and in which tables inside Bitrix they need to be folded). All this should be in the documentation — if there is no documentation, it is almost impossible to work with the API.

When everything is studied, we start writing code: connect here, take the data → check that they came and they are correct. Everything is written manually for each individual API integration. But here's a caveat: there can be a combat and test mode for the API (accesses, servers) — this is necessary to conduct development and testing without affecting the combat site / combat data. Not always necessary, but often depends on the complexity of the API itself. Strict correspondence of communication protocols is necessary, that is, descriptions of which address to contact, which request to send, what data will be received, etc., so that the programmer can proceed directly to development, because otherwise they will have to be coordinated in the process, which no one likes. Of course, changes may be present, but it is undesirable that this happens too often. Similarly, if suddenly the test API does not match the description (or the combat API differs from the test ONE, and it is not described.)

There are several standard protocols (data formats — for example, XML or JSON), but inside them data can be represented as you like. Therefore, it is impossible to write something that works from one API so that the same code can work on another API without any edits: there are other methods, and other data, and another structure. But at the same time, the work of a particular API can be transferred from one project to another.

If we integrate with some third-party services, then we usually do a technical specification for integration — a description of the methods and which of them we will use, how they relate to the entities of the site. Without this description, it is not clear how to write code, and you can very much “screw up”.

For typical services (such as deliveries), the Bitrix store has ready-made integration modules that already know where to "knock" and what data to transmit, you can configure them. In fact, a module is a ready—made piece of code for working with something.

When a site does not have an API, but you need to integrate with it, you have to parse the site data — load the site pages, pretending to be a browser, take some necessary pieces from them and put them into a database. Let's talk about this in the next article.