Get Mystery Box with random crypto!

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

Telegram арнасының логотипі itarchitecture — ИТ-архитектура И
Telegram арнасының логотипі itarchitecture — ИТ-архитектура
Арна мекенжайы: @itarchitecture
Санаттар: Технологиялар
Тіл: қазақ
Жазылушылар: 353
Арнадан сипаттама

Полезные ссылки и материалы по архитектуре предприятия, решений, данных, системной архитектуре, system design, archops. Администратор канала @itarchitect_kz https://www.linkedin.com/in/itarchitectkz www: https://itarchitect.kz

Ratings & Reviews

2.50

2 reviews

Reviews can be left only by registered users. All reviews are moderated by admins.

5 stars

0

4 stars

1

3 stars

0

2 stars

0

1 stars

1


Соңғы хабарлар 2

2022-12-14 15:56:34 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.
148 viewsedited  12:56
Ашу / Түсініктеме
2022-12-14 15:56:34 Лучшие практики в разработке 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. Единственным исключением является отправка и получение файлов между клиентом и сервером.
136 viewsedited  12:56
Ашу / Түсініктеме
2022-12-10 09:31:24 #podcast

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

https://pca.st/episode/ca8b66af-bda0-4c91-944d-41de71b90efb
176 views06:31
Ашу / Түсініктеме
2022-12-04 13:59:34
Что происходит, когда вы вводите URL-адрес в браузере? #перевод_для_канала_itarchitecture Процесс включает в себя браузер, операционную систему вашего компьютера, вашего интернет-провайдера, сервер, на котором вы размещаете сайт, и службы, работающие на…
242 views10:59
Ашу / Түсініктеме
2022-12-04 13:58:19 Что происходит, когда вы вводите 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-ресурс был получен в теле ответа.
200 views10:58
Ашу / Түсініктеме
2022-12-01 15:46:22 Про платформу 1С

#podcast

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

https://pca.st/episode/fdb19024-f56e-4855-a2d3-66921bbfd105
189 viewsedited  12:46
Ашу / Түсініктеме
2022-11-30 05:58:32
Когда использовать GraphQL, gRPC и REST? #перевод_для_канала_itarchitecture Когда дело доходит до разработки клиент-серверных приложений, разработчики могут выбирать из множества коммуникационных протоколов. Использование GraphQL, gRPC и REST довольно распространено…
201 views02:58
Ашу / Түсініктеме
2022-11-30 05:58:03 Когда использовать 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.
175 views02:58
Ашу / Түсініктеме
2022-11-25 07:21:39
Почему сначала надо разрабатывать (модульный) монолит? #перевод_для_канала_itarchitecture В последние годы мы наблюдаем значительное увеличение количества приложений, созданных с использованием микросервисной архитектуры. Основная причина, по которой мы…
217 views04:21
Ашу / Түсініктеме
2022-11-25 07:20:44 Почему сначала надо разрабатывать (модульный) монолит?

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

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

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

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

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

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

Как мы можем реализовать такую концепцию? Мы создаем отдельные модули, каждый из которых может иметь свою собственную архитектуру, и эти модули объединяются в один API Gateway (шлюз API). Это позволяет нам развертывать всю систему как монолит, но позволяет нам извлекать отдельные модули в сервисы, если это необходимо в будущем.
208 viewsedited  04:20
Ашу / Түсініктеме