Словарь веб-разработчика

Git — распределённая система контроля версий. Каждый разработчик имеет полную копию репозитория (включая всю историю), может работать офлайн и синхронизироваться с командой через push/pull. Фактический стандарт в разработке ПО.Ключевые концепцииCommit — снимок состояния файлов с сообщением. Неизменяем после созданияBranch — параллельная линия разработки. Дешёвый и быстрый в GitMerge / Rebase — интеграция изменений из одной ветки в другую. Merge сохраняет полную историю, rebase делает линейнуюRemote — копия репозитория на сервере (GitHub, GitLab, Bitbucket)Базовые командыgit init / git clone git add . && git commit -m "message" git push / git pull git checkout -b feature/name git merge / git rebaseСтратегии ветвленияGit Flow (develop/release/hotfix), GitHub Flow (main + feature branches), Trunk-Based Development — без долгоживущих веток. Выбор зависит от размера команды и частоты релизов.

GitOps — практика управления инфраструктурой и деплоями через Git как единый источник правды. Желаемое состояние системы описывается в репозитории; специальный оператор автоматически синхронизирует реальное состояние с описанным. Ключевые принципы Декларативность — состояние инфраструктуры описывается файлами (Kubernetes manifests, Helm charts) Git как единый источник — любое изменение проходит через Pull Request с ревью и CI Автоматическая синхронизация — оператор (ArgoCD, Flux) отслеживает Git и применяет изменения Наблюдаемость — легко сравнить текущее состояние кластера с описанным в Git GitOps vs CI/CD Push Push — CI-пайплайн сам деплоит (kubectl apply). Требует credentials в CI Pull (GitOps) — оператор внутри кластера сам тянет изменения из Git. Меньше поверхность атаки Инструменты ArgoCD и Flux CD — наиболее популярные GitOps-операторы для Kubernetes.

Graceful Degradation (корректная деградация) — подход, при котором система продолжает частично функционировать при отказе компонентов, вместо полной остановки. «Деградировать корректно» лучше, чем «упасть полностью».ПримерыПоиск не отвечает → показать популярный контент вместо ошибкиRedis недоступен → повышенная нагрузка на БД, но сайт работаетПлатёжный провайдер недоступен → принять заказ, обработать позжеJavaScript заблокирован → базовая HTML-версия страницы всё равно доступнаProgressive Enhancement vs Graceful DegradationProgressive Enhancement — начинаем с базового опыта и постепенно добавляем функциональность для поддерживаемых средGraceful Degradation — проектируем для современной среды, но обеспечиваем fallback для слабыхРеализацияCircuit Breaker, fallback-ответы, timeout + retry, feature flags для отключения проблемных фич.

Graceful Shutdown (корректное завершение) — процесс остановки сервиса без резкого прерывания: сначала он перестаёт принимать новые запросы, завершает обработку активных и только потом останавливается. Альтернатива — kill -9, обрывающий соединения посередине. Зачем Не прерывать обрабатываемые HTTP-запросы Завершить транзакции в БД Зафиксировать сообщения из очереди перед остановкой Не показывать ошибки пользователям при деплое Unix сигналы SIGTERM — запрос на завершение (graceful). SIGKILL — принудительное завершение (нельзя перехватить). При деплое обычно отправляют SIGTERM, ждут N секунд (timeout), затем SIGKILL. В PHP pcntl_signal(SIGTERM, function () { $this->shouldStop = true; // остановить loop воркера после текущей задачи }); pcntl_async_signals(true); Kubernetes terminationGracePeriodSeconds — время ожидания между SIGTERM и SIGKILL. По умолчанию 30 секунд.

GraphQL — язык запросов для API, разработанный Facebook. Клиент сам описывает, какие именно поля ему нужны, и получает ровно их — без лишних данных (overfetching) и без необходимости делать несколько запросов (underfetching).GraphQL vs RESTREST: GET /users/42 возвращает весь объект User — клиент берёт только name. GraphQL: query { user(id: 42) { name } } — сервер возвращает только name. Один endpoint вместо десятков.Ключевые концепцииQuery — чтение данныхMutation — изменение данныхSubscription — реальное время через WebSocketSchema — типизированный контракт между клиентом и серверомКогда выбирать GraphQLИдеально для мобильных клиентов (минимум трафика), сложных вложенных данных и когда много разных клиентов с разными потребностями. REST проще для простого CRUD.

gRPC (Google Remote Procedure Call) — фреймворк для межсервисной коммуникации, использующий Protocol Buffers для сериализации и HTTP/2 в качестве транспорта. В 5–10 раз быстрее JSON/HTTP в большинстве задач.Protocol BuffersСхема описывается в .proto-файле, из которого генерируется код клиента и сервера на любом поддерживаемом языке. Бинарный формат — компактнее и быстрее JSON.message User { int32 id = 1; string name = 2; } service UserService { rpc GetUser (UserRequest) returns (User); }Преимущества перед RESTСкорость: бинарная сериализация, мультиплексирование HTTP/2Стриминг: одностороннее и двустороннееСтрогая типизация: изменение схемы фиксируется при компиляцииОграниченияgRPC плохо подходит для публичных API (браузеры не поддерживают без grpc-web proxy). Идеален для внутренней коммуникации между микросервисами.