Backend возможно Flashcards
(38 cards)
Provide few examples of HTTP headers?
content-length, content-type, cookie, authorization, user-agent
What are HTTP status codes?
Расскажи подробнее (выучить самые популярные коды)
HTTP status codes…
From 100 to 199 are reserved for informational status codes.
From 200 to 299 there are success codes
From 300 to 399 there are redirect codes
From 400 to 499 are frontend error codes
From 500 to 599 there are backend error codes
What is proxy?
What is reverse-proxy?
What is difference between them?
Proxy is a server that stands between client and destination server and act on behalf of client.
The purpose of proxy-server can be different.
It can be used to hide real client IP address and another information, or to act like VPN, or just to do some caching in order to improve performance.
The reverse-proxy is a server that stands between server and clients and act on behalf of destination server. It takes requests from clients and then re-send them to real server or servers.
It can be used for multiple purposes. First of all, in order to protect real servers from direct access and improve safety, but it also can be used as traffic balancer and requests router, or, again, be used to cache some data in order to improve performance.
What actions have you personally taken on recent projects to increase maintainability of your code?
Okay… At first, I am trying to keep same code style, because this makes code reading much easier. This was implemented as on my current workplace, same in my pet projects. This touches indentation, naming, etcetera.
Second, is splitting code into small functional blocks, each of what contains only certain information, and I am trying to avoid code mixing, following first SOLID principle.
All in all, I am trying always remember about SOLID and KISS principles and follow them.
What is DNS and what it needed for?
DNS or Domain Name System, is a system used in Internet to transform human-readable domain names, like youtube.com, into IP addresses, which are used by computers for identification and interaction.
What is TDD (Test Driven Development)?
Test Driven Development is a development, where when you want to add new functionality into your application, you write tests, covering this functionality, first, and only then write code for this functionality itself.
This approach makes your code more covered with tests, so it makes it more reliable. Also, when you are writing tests, you have time to think about, for example, what your function should return in what cases, and what are edge cases, etcetera, so this is easier to write man functionality after writing tests.
Explain the difference between mutable and immutable objects. What is an example of an immutable object in JavaScript? What are the pros and cons of immutability? How can you achieve immutability in your own code?
Mutable objects can be changed, while immutable objects is not possible to change.
About pros and cons. From one side, immutability makes states easier to manage, because you are always sure, that if you somewhere used any value, it won’t be accidentally changed somewhere else, and program is more predictable.
From another side, in case of immutability, if you want to somehow modify string, for example, then you create another new object, containing all changes, and this takes additional memory and time.
About how to achieve immutability. For simple things like number or string, we can just use const word when declaring variables with these values. But for more complex things like arrays and objects you need to use special libraries, which provide this immutability functional, or write your own code which will allow you to interact with arrays and objects like if they were immutable too.
What is Domain Driven Design?
Domain driven design is such architectural approach that tells you to split your application into certain parts based on a business domain, where business domain is a certain specific part of business that has quite a lot of internal connections with itself, and that has a much smaller number of dependencies and connections with other parts of your business than inside itself.
And when you are developing this specific part based on a certain domain, this can be just a model inside your monolith service, or this can be a separate microservice, you rely on ideas, terminology, and opinion of experts who work in this specific part of this business.
What is the difference between a process and a thread within an operating system?
Process is an instance of executable program. This instance includes program code itself, memory, required for code execution, and environment variables. Address space of each process is isolated, so that means that memory that this process uses can’t be directly accessed by other process.
But this isolation and process context itself is quite heavy and requires a lot of resources when creating new one or switching between processes.
Thread is execution unit, that exists inside process scope. Process can have multiple threads that work on its execution. Threads share same resources and address space inside process, and make it possible for process to do some work in parallel, using multiple threads.
To sum up, processes are isolated from each other, but threads share same memory space inside process scope.
Process creation is more complicated and takes more resources that creation of new thread.
Communication between processes is complicated and slow, but threads can communicate quickly.
Errors in one process won’t affect other processes, but error in one thread can crash whole process it belongs to.
Processes are good for things, that should be isolated from each other and be more reliable, while threads are good for splitting process work into multiple parts in order to do it quickly, for example in video redactors.
Как выглядит структура типичного проекта, с которым ты работал?
Ну, сама папка проекта, в ней отдельные папки для api, где лежат прото файлы сервиса, папка с автоматически генерируемым платформой кодом, где всякие базовые штуки, вроде взаимодействия с корпоративным чатом, кроной, кафкой, и всем таким.
Ещё есть отдельная папка для хранения middleware и миграций базы данных.
В отдельной папке также тесты, и ещё код, сгенерированный по прото файлам из самого проекта, и из проектов, которые в специальном файле указаны как связанные с этим проектом. Ну то есть, чтобы можно было туда слать запросы.
Ну и ещё в отдельной папке сам main файл, и внутренний код самого проекта
Как выглядит запрос к RPC ручке?
Ну, обычно это выглядит так, что у тебя есть Golang код, сгенерированный специальной тулзой на базе .proto контракта, и ты вызываешь функции из этого сгенерированного кода.
Этот код сохраняется в pkg
internal/pkg/package name из protobuf файла, который ты указываешь в конфигурации для генератора кода mimir, он под капотом вызывается в scratch. ты просто пишешь make generate и происходит магия
Сгенереный код хранится в internal/pb/…
При вызове функции, туда передаётся коннект
Коннект создаётся в отдельном клиенте (просто обёртка для удобного вызова)
При инициализации нашего сервиса мы создаём клиенты для каждого сервиса с которым мы работаем и сохраняем в структуру сервиса (структура данных)
Как выглядит процесс создания новой RPC ручки?
Ну, сначала описывается сама структура метода в .proto файле сервиса, если надо добавляются новые структуры для описания аргументов или возвращаемого значения.
Потом на базе этого обновляется сгенерированный код.
Потом в функции инициализации там где ты регистрируешь свой сервис который ты ранее определил в .proto файле, ты подставляешь структуру, которая имплементирует методы сервиса.
- Описал ручку в .proto файле
- Запустил скрипт для генерации кода.
Генерируется код который занимается сериализацией и десериализацией запросов при использовании ручки.
Генерируется функция-обработчик транспортного слоя, она изначально не заимплементирована, её надо имплементить, и конвертить внутри неё данные gRPC запроса в данные, передаваемые в конечный handler, и конвертировать ответ handler в gRPC структуры данных. - Сделать имплементацию конечной логики в отдельной функции в соответствующем package.
Каким образом делали запрос по RPC к другим сервисам?
On our projects, our services had list of related services in their config. Using special “make” command you could generate a Go client from .proto files for each of these services.
There were two versions of functions used to work with these clients that you use when write your code.
First uses config that you provide once when just start up your service, in main file, and second one is customizable, where you can provide your own connection to be used, but this case you have to do all related things like closing it manually.
Каким образом фронт делал запросы к RPC ручкам?
А фронт не делал запросы к RPC ручкам, фронт ходил на REST ручки, а потом уже с них запросы перенаправлялись куда надо.
Что такое Protocol Buffers, и как они связаны с gRPC?
Protocol Buffers это бинарный формат сериализации данных, который используется в gRPC. То есть, там мы не текст и не JSON какой-нибудь передаём, а в .proto файле определяем контракт, и потом на базе этого .proto файла происходит сериализация и десереализация.
Какие есть основные типы RPC в gRPC?
Well, there are two variants of data transfer in gRPC. So, this can be unary connection, or this can be stream. In case of unary connection, we send the information once, and that’s it. In case of stream, we can send packages of information until stream is closed. So, there are four possible combinations of this data transfer in gRPC. unary connection from both sides, server stream, client stream, and bidirectional stream.
Расскажите о максимальном объёме данных, который передавался через gRPC.
Вроде бы по дефолту максимальный размер пакета это 4 мегабайта, если нужно больше, то нужно либо редактировать конфиги, либо использовать стриминг.
Как оптимизировать gRPC на высоконагруженных системах?
Что можно сделать…
Ну, например, настроить тайм-ауты. Чтобы операции долго не висели, если второй сервис не отвечает.
Ещё, если нам надо передавать много данных между клиентом и сервером, то использовать не отдельные запросы, а по возможности стримы.
Ещё, можно стучаться не напрямую к какому-то конкретному серверу, а на балансировщик, и от него уже перенаправлять запросы на кластер серверов.
Ещё, если у нас есть такая ситуация, при которой мы знаем, что за относительно короткий период времени может быть выполнено несколько одних и тех же запросов, возвращающих одни и те же данные, то мы можем использовать кеширование.
Ещё, можно использовать асинхронные механизмы обработки запросов, например через брокеры сообщений, а не стучаться к сервису напрямую. Особенно, если запрос занимает много времени.
Как организовать обратную совместимость в gRPC?
Ну, во-первых, не надо изменять номера полей. Если поле больше не используется, то его номер нельзя переиспользовать.
Не нужно удалять методы сервисов.
Использовали ли вы gRPC-Gateway? Как вы настраивали его?
У нас на проекте использовался для генерации API, к которому ходит фронт, но это уже было, и я это не настраивал.
Объясните, как работают interceptor-ы в gRPC. Использовали ли вы их?
Интерцепторы это middleware
Как вы дебажили ошибки, связанные с gRPC?
Ну, основных инструмента три, это логи запросов, это сваггер, который можно использовать для отправки запросов и проверки, всё ли идёт как надо, и это Jaeger, чтобы глянуть путь запроса и попробовать понять, когда и почему что-то пошло не так.
Что вы делали в случае появления Deadline Exceeded или Unavailable?
- Проверяем, что это ошибка именно запроса, а не где-то в коде
- Если ошибка запроса, то изучаем подробности, статус, message и детали.
- Используем их для того, чтобы вернуть ошибку с максимальным количеством информации и человекочитаемым описанием.
Если это не ошибка скажем, неправильных аргументов, или ещё чего-то, а просто запрос exceeded или unavailable, и твоя ручка не синхронная и не имеет прям жёстких временных рамок, то можно несколько раз повторить запрос.
Что бы вы выбрали: gRPC или REST для нового проекта? Почему?
Зависит от многих факторов.
Если бы мне нужно было бы просто создать одиночный сервис, то я бы использовал REST, потому что так меньше мороки.
А вот если бы у меня было много микросервисов, да ещё нужно было бы часто между ними ходить, да ещё и нагрузка была бы большая, то там уже gRPC, потому что он в такой ситуации оказывается более быстрым и удобным.
When using gRPC instead of REST, it’s much easier to avoid contract mismatches.
