ИТ-архитектура

7. Правильно обрабатывайте ошибки

Здесь мы хотим устранить любую путаницу при возникновении ошибок, поэтому нам нужно правильно обрабатывать их и возвращать код ответа, который указывает в точности на то, какая ошибка произошла (ошибки от 400 до 5xx). Вместе с кодом состояния нам нужно вернуть некоторые детали в теле ответа.

8. Применяйте необходимые методы обеспечения безопасности

Мы хотим, чтобы вся связь между клиентом и сервером была защищена, а это значит, что нам нужно постоянно использовать SSL/TLS, без исключений. Кроме того, разрешите аутентификацию через ключи API, которые должны передаваться с помощью пользовательского заголовка HTTP, с указанием истечения срока их действия.

9. Используйте нумерацию страниц

Используйте нумерацию страниц, если нашему API нужно вернуть много данных, так как это сделает наш API готовым к будущим изменениям. Здесь рекомендуется использовать page и page_size.

Например, /products?page=10&page_size=20

10. Управление версиями

Очень важно вести версионирование API с первой версии, так как у наших API могут быть разные пользователи. Это позволит нашим пользователям не зависеть от изменений, которые мы можем сделать в будущем. Версии API могут передаваться через заголовки HTTP или параметры запроса/пути.

Например, /products/v1/4

И не забывайте документировать API, потому что API будет хорош настолько, насколько качественна его документация. Документация должна содержать примеры полных циклов запроса/ответа. Здесь мы можем использовать определение OpenAPI в качестве источника истины.

Если вы хотите начать разработку API, ознакомьтесь со спецификациями Swagger, OpenAPI, Postman или Stoplight.

Лучшие практики в разработке API

#перевод_для_канала_itarchitecture

В повседневной работе в качестве инженеров-программистов большинство использует или создает REST API. Стандартный подход обеспечения коммуникации между системами - посредством API. Поэтому, чтобы избежать проблем в будущем, очень важно правильно проектировать REST API. Верно определенный API должен быть простым в работе, лаконичным и затруднять его неправильное использование.

Вот несколько общих рекомендаций:

1. Используйте существительные вместо глаголов

Глаголы не должны использоваться в конечных точках (endpoints). Вместо этого путь должен содержать существительные, которые идентифицируют объект, к которому принадлежит endpoint, объект, к которому мы обращаемся или который изменяем.

Например, вместо использования /getAllClients для получения всех клиентов используйте /clients.

2. Используйте существительные ресурса во множественном числе

Старайтесь использовать форму множественного числа для существительных ресурса, потому что это подходит для всех типов endpoints.

Например, вместо использования /employee/:id/ используйте /employees/:id/

3. API должны быть последовательными

Под последовательностью подразумевается предсказуемость. Поведение endpoints должно следовать единым правилам. Таким образом, используйте один и тот же подход для ресурсов, одни и те же методы аутентификации для всех endpoints, используйте одни и те же заголовки, используйте одни и те же коды состояния и т. д.

4. Сохраняйте API простыми

Мы должны сделать так, чтобы имена всех endpoints были ориентированы на сущности, с которыми они работают. Если мы хотим определить API для пользователей, мы бы определили его как:

/users
/users/124

Таким образом, первый API получает всех пользователей, а второй получает конкретного пользователя.

5. Используйте правильные коды состояния

Этот пункт особо важен. Есть много кодов состояния HTTP, но мы обычно используем только некоторые из них. Не используйте слишком много, но используйте одни и те же коды состояния для одних и тех же результатов в API, например,

- 200 - запрос выполнен успешно
- 201 - запрос выполнен успешно и привёл к созданию ресурса
- 400 - некорректный запрос
- 401 - несанкционированный запрос
- 403 - отсутствуют разрешения
- 404 - недостающие ресурсы
- 5xx - внутренние ошибки

6. Не возвращайте обычный текст

REST API должны принимать JSON для полезной нагрузки запроса, а также отвечать в формате JSON, так как это стандарт для передачи данных в REST. Тем не менее, недостаточно просто вернуть тело со строкой в формате JSON, нам также нужно указать заголовок Content-Type как application/json. Единственным исключением является отправка и получение файлов между клиентом и сервером.

#podcast

А что если в больших компаниях действительно слишком много команд и разработчиков?

https://pca.st/episode/ca8b66af-bda0-4c91-944d-41de71b90efb

Прекрасная визуализация

Что происходит, когда вы вводите URL-адрес в браузере?

#перевод_для_канала_itarchitecture

Процесс включает в себя браузер, операционную систему вашего компьютера, вашего интернет-провайдера, сервер, на котором вы размещаете сайт, и службы, работающие на этом сервере.

𝟭. Вы вводите https://somewebsite.com/page в своем браузере и нажимаете Enter

Здесь https:// - это схема, которая говорит браузеру подключиться к серверу с помощью TLS. Somewebsite.com - это доменное имя сайта, которое указывает на конкретный IP-адрес сервера. А /page - это путь к нужному вам ресурсу.

𝟮. Браузер ищет IP-адрес домена

После того, как вы ввели URL-адрес в свой браузер и нажали Enter, браузер должен выяснить, к какому серверу в Интернете подключиться. Для этого он должен искать IP-адрес сервера, на котором размещен веб-сайт, используя введенный вами домен. Для этого используется поиск DNS. Здесь он определяет, можем ли мы найти его в кэше; если нет, DNS должен искать серверы доменных имен от корня до третьего уровня.

𝟯. Браузер инициирует TCP-соединение с сервером

Протокол управления передачей, более известный как TCP, используется во всей общедоступной инфраструктуре маршрутизации Интернета для маршрутизации пакетов из запроса клиентского браузера через маршрутизатор, интернет-провайдера, через интернет-обмен для переключения интернет-провайдеров или сетей и, наконец, для поиска сервера с IP-адресом для подключения. Это довольно неэффективный путь. Вместо этого многие веб-сайты используют CDN для кэширования как статических, так и динамических материалов ближе к своим клиентам.

𝟰. Браузер отправляет HTTP-запрос на сервер

Теперь, когда браузер подключен к серверу, он соответствует требованиям взаимодействия, накладываемым протоколом HTTP(s). Чтобы запросить содержимое страницы, браузер сначала отправляет HTTP-запрос на сервер. Запрос HTTP состоит из: тела запроса, заголовка и строки запроса. Сервер может определить, что клиент хочет сделать, используя информацию в строке запроса.

𝟱. Сервер обрабатывает запрос и отправляет ответ

Сервер принимает запрос и определяет, как его обработать в зависимости от данных в строке запроса, заголовках и теле. Сервер получает материал по этому URL-адресу для запросов GET /page/ HTTP/1.1, создает ответ, а затем доставляет его обратно клиенту с кодом состояния HTTP.

𝟲. Браузер отображает содержимое

Браузер проверяет заголовки ответов на предмет инструкций по рендерингу ресурса после получения ответа сервера. Заголовок Content-Type информирует браузер о том, что HTML-ресурс был получен в теле ответа.

Про платформу 1С

#podcast

У ИТ комьюнити сложилось устойчивое негативное отношение к 1С. "Софт для бухгалтеров, программирование на русском, древние подходы к разработке, и вообще это не настоящее программирование!" — выдержка из 99% обсуждений этой платформы. Но зачастую устоявшиеся взгляды могут не отражать реальную картину дел. С какими инструментами работают современные разработчики 1С и какая них любимая IDE? Какого это - программировать на русском, и можно ли иначе Применимы ли DevOps практики к разработке на 1С?

https://pca.st/episode/fdb19024-f56e-4855-a2d3-66921bbfd105

Детали

Когда использовать GraphQL, gRPC и REST?

#перевод_для_канала_itarchitecture

Когда дело доходит до разработки клиент-серверных приложений, разработчики могут выбирать из множества коммуникационных протоколов. Использование GraphQL, gRPC и REST довольно распространено в современных проектах. Каждый протокол может предоставить множество преимуществ в зависимости от требований вашего приложения.

GraphQL - это гибкий подход к запросам данных, который фокусируется на конкретных запросах и предоставляет только то, что необходимо. Тот факт, что GraphQL ориентирован на клиента, отличает его от других API. В противовес стандартному подходу, когда все решения принимает клиент. Его преимущества заключаются в том, что он не зависит от языка программирования, запросы выполняются через единый endpoint* и он строго типизирован, поскольку имеет схемы.

* Endpoint (конечная точка) представляет собой некий шлюз, который соединяет серверные процессы приложения с внешним интерфейсом.

REST - самый популярный подход. Он отлично подходит, когда домен можно описать как набор ресурсов. REST - это stateless (без состояния) архитектура для передачи данных. Некоторые преимущества REST заключаются в том, что это хорошо зарекомендовавший себя стандарт, он прост в использовании и имеет хорошую поддержку кэширования.

gRPC - это метод, который предлагает легкую и быструю систему для получения данных. Здесь основное различие заключается в том, как он описывает взаимодействия по контракту. Он опирается на контракты; архитектура - это не то, что регулирует взаимодействие; это отношения между сервером и клиентом. В то время как обработка и расчеты делегируются удаленному серверу, на котором размещен ресурс, большая часть возможностей имеется на стороне клиента. Его основные преимущества заключаются в том, что у него легкие клиенты, он очень эффективен, так как использует протокольные буферы для отправки/получения данных, а также предлагается как Open Source.

Итак, когда выбирать каждый из этих протоколов:

✅ Используйте REST, если вы создаете веб-приложение в стиле CRUD или работаете с хорошо структурированными данными.

✅ Используйте gRPC, если у вас приватный API и выполняются разнообразные операции. Кроме того, если важна высокая производительность.

✅ Используйте GraphQL, если у вас есть общедоступный API, который должен быть гибким для настройки запросов, и вы хотите добавить данные из разных источников в общедоступный API.

Как вы видите, каждый из этих вариантов имеет конкретные специфики и преимущества. В этом случае нет единственного фаворита, поэтому использование того или иного подхода зависит от ваших целей и стратегии.

Дополнительные подробности в таблице ниже.

Автор таблицы: LogRocket.

Схема модульного монолита

Почему сначала надо разрабатывать (модульный) монолит?

#перевод_для_канала_itarchitecture

В последние годы мы наблюдаем значительное увеличение количества приложений, созданных с использованием микросервисной архитектуры. Основная причина, по которой мы выбираем этот подход, заключается в предоставлении возможности небольшим командам работать изолированно, не мешая друг другу. Тем не менее, это организационная проблема, а не техническая. Мы также можем построить каждый сервис на отдельной технологии и масштабировать самостоятельно.

В микросервисном подходе также есть несколько недостатков - система становится сложной для обслуживания и диагностики проблем (логирование и отслеживание). И это очень важно при работе с микросервисами.

Между тем, создание монолитов само по себе не является лучшим решением. В последние годы мы часто видели идентификацию монолита с архитектурой big ball of mud (“большой шар грязи”) или только написания устаревающего кода, что на самом деле некорректно. Да, монолиты не могут масштабировать независимые части системы или релизить их отдельно, в этом самые большие недостатки монолита. Тем не менее, вы можете писать отличный и качественный код внутри. Также монолит приносит нам гораздо меньшую сложность, сокращение сетевых вызовов, упрощение логирования и т.п.

Одним из хороших вариантов решения проблем единого монолита может быть построение модульного монолита, в котором мы все еще можем иметь отдельные модули и работать над ними, и при этом поддерживать простоту. Правильно построенный модульный монолит может при необходимости, с определенным объемом доработок преобразован в микросервисное решение завтра.

Когда мы хотим построить модульный монолит, важно сначала разделить систему на управляемые модули, прежде чем собирать эти модули в монолит для развертывания. Поскольку вся связь между модулями может привести к межсетевым вызовам, если вы решите разбить его на сервисы в будущем, high cohesion (высокая согласованность) и low coupling (низкая связность) имеют решающее значение. Это означает, что вся межмодульная связь должна быть абстрактной, асинхронной или основанной на обмене сообщениями, чтобы модули могли обрабатывать вызовы, которые будут проходить по сети в будущем.

Как мы можем реализовать такую концепцию? Мы создаем отдельные модули, каждый из которых может иметь свою собственную архитектуру, и эти модули объединяются в один API Gateway (шлюз API). Это позволяет нам развертывать всю систему как монолит, но позволяет нам извлекать отдельные модули в сервисы, если это необходимо в будущем.

Как работает электронная почта?

В этом посте мы рассмотрим, что происходит, когда Алиса отправляет электронное письмо Бобу.
 
1. Алиса входит в свой клиент Outlook, пишет электронное письмо и нажимает “Отправить". Электронное письмо отправляется на почтовый сервер Outlook. Протокол связи между клиентом Outlook и почтовым сервером - SMTP.
 
2. Почтовый сервер Outlook запрашивает у службы DNS адрес SMTP-сервера получателя. В данном случае это SMTP-сервер Gmail. Затем он передает электронную почту на почтовый сервер Gmail. Протокол связи между почтовыми серверами - SMTP.
 
3. Сервер Gmail хранит электронную почту и делает ее доступной Бобу - получателю.
 
4. Когда Боб открывает клиент Gmail, последний получает новые электронные письма через сервер IMAP/POP Gmail.
 
Краткое резюме:
 
SMTP: Simple Mail Transfer Protocol (SMTP) - это стандартный протокол для отправки электронной почты с одного почтового сервера на другой. 
Самые популярные протоколы для получения электронной почты известны как Post Office Protocol (POP) и Internet Mail Access Protocol (IMAP).
 
POP - это стандартный почтовый протокол для получения и загрузки электронной почты с удаленного почтового сервера на локальный почтовый клиент. Как только электронные письма загружаются на ваше устройство, они удаляются с почтового сервера, что означает, что вы можете получить доступ к электронной почте только на одном устройстве. Детали POP освещены в RFC 1939. POP требует, чтобы почтовые клиенты загружали всю электронную почту. Если электронное письмо содержит большое вложение, загрузка может занять много времени.
 
IMAP также является стандартным почтовым протоколом для получения электронной почты для локального почтового клиента. Когда вы читаете электронное письмо, вы подключаетесь к внешнему почтовому серверу, и данные передаются на локальное устройство. IMAP загружает сообщение только тогда, когда вы нажимаете на него, и электронные письма не удаляются с почтовых серверов, что означает, что вы можете получить доступ к почте с нескольких устройств.

Обзор архитектуры Twitter

#перевод_для_канала_itarchitecture

Да, Илон Маск недавно купил Твиттер, но что там под капотом?
Вот обзор архитектуры Twitter, обслуживающей более 230 миллионов пользователей.

Люди постоянно генерируют контент в Twitter. Ключевая задача Twitter в эффективном распространении данного контента. Как отправить его своим многочисленным подписчикам? Настоящий челендж - это преодоление ограничений работы в режиме реального времени. Цель - доставка потока сообщений до пользователя не более чем за 5 секунд.

Жизнь твита:

1. Твит поступает через Write API.
2. Write API направляет запрос в службу Fanout.
3. Служба Fanout выполняет много обработки и хранит твиты в кэше Redis.
4. Служба Timeline используется для поиска сервера Redis, на котором есть таймлайн пользователя (лента твитов в хронологии).
5. Пользователь извлекает свой таймлайн через службу Timeline.

Поиск и обнаружение

Ingester: аннотирует и токенизирует твиты, чтобы данные могли быть проиндексированы.
Earlybird: хранит поисковый индекс.
Blender: создает таймлайны поиска и обнаружения.

Отправка уведомлений

- HTTP push;
- push на мобильные устройства.

Что такое API Gateway (шлюз API)?

#перевод_для_канала_itarchitecture

Инструмент управления API, известный как API Gateway, находится между клиентом и группой backend сервисов. API Gateway выполняет функцию обратного прокси-сервера, принимая все вызовы интерфейса прикладного программирования (API), объединяя различные сервисы, необходимые для их выполнения, и возвращая правильный результат.

Большинство корпоративных API развертывается с использованием API Gateway. Аутентификация пользователей, ограничения скорости и статистика - это общие обязанности, которые API Gateway берут на себя от имени пула API-сервисов.

API-сервис получает удаленный запрос и отвечает на него. Но на самом деле все не так просто. При размещении крупномасштабных API учитываются различные вопросы:

✅ Использование системы ограничения скорости и службы аутентификации для защиты ваших API от злоупотреблений и чрезмерного использования.
✅ Внедрение инструментов аналитики и мониторинга, чтобы знать, как используются ваши API.
✅ Интеграции с платежными системами, если API монетизированы.
✅ Если используется микросервисная архитектура, для одного запроса может потребоваться вызов сотен различных сервисов.
✅ Клиенты всегда будут желать получения доступа ко всем вашим сервисам в одном месте, даже если вы со временем добавите новые API-сервисы или поставите на утрату другие.

В целом это работает так:

1. API gateway получает HTTP-запрос от клиента.
2. При получении он сначала проверяет запрос на корректность.
3. Далее проверяет запрос на предмет аутентификации/авторизации (у identity provider - поставщика идентификации).
4. Затем к запросу применяются правила ограничения скорости.
5. API gateway находит соответствующий backend сервис и маршрутизирует на него запрос.

Кроме того, API gateway может обрабатывать сбои сервисов (circuit breaker), а также выполнять логирование, кэширование и мониторинг.