Проектирование API *

Реализация динамических типов на GraphQL выглядит довольно естественно. Однако, есть определенные сложности.

В настоящее время объектно-ориентированные базы данных (ООБД) не имеют достаточно большого распространения в повседневном использовании, да и более того, не настолько популярны как реляционные базы данных, которые не один десяток лет уже активно поддерживаются различными сообществами и имеют долгую историю применения.

В данной статье рассматривается реализация ООБД в контексте разработки системы, состоящей из микросервисов, на примере Perst и Db4o. Также будет рассмотрена отдельная реализация с документно-ориентированной базой данных MongoDB, работа с которой имеет много общего с ООБД.

Целью данной статьи является рассмотрение практического применения ООБД и решения проблем совместимости с помощью микросервисной архитектуры.

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

Я не профессиональный программист и не претендую, поэтому решил сделать все довольно просто.

Привет! В одном из недавних постов ребята из Додо разбирали устройство интернет‑платежей и в самом конце текста задались десятком вопросов по теме. Меня зовут Антон, я IT‑менеджер в продукте Эквайринга, и мне удалось собрать знающих ребят в QIWI, чтобы довольно подробно ответить на эти вопросы.

Предложение пообщаться

Я думаю, что немного сомневаться в своих решениях и ресёрчить новые возможности просто необходимо на постоянной основе. У меня накопилась целая куча вопросов относительно интернет‑платежей, ответы на которые я пока для себя не нашёл.

@aurokk

Что получилось — под катом.

# Шаблон backend сервера на Golang — часть 5 — оптимизация Worker pool

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

Представленный Worker pool поддерживает работу с двумя типами задач

• "Короткие" — не контролируется предельный timeout выполнения и их нельзя прервать
• "Длинные" — контролируется предельный timeout выполнения и их можно прервать

Накладные расходы Worker pool на добавление в очередь, контроль очереди, запуск обработки task, контроль времени выполнения task:

• Для "коротких" task — от 300 ns/op, 0 B/op, 0 allocs/op
• Для "длинных" task — от 1400 ns/op, 16 B/op, 1 allocs/op

Для task, которые должны выполняться быстрее 200 ns/op представленный Worker pool использовать не эффективно

Собираются следующие метрики prometheus:

• wp_worker_process_count_vec — количество worker в работе
• wp_task_process_duration_ms_by_name — гистограмма длительности выполнения task в ms с группировкой по task.name
• wp_task_queue_buffer_len_vec — текущая длина канала-очереди task — показывает заполненность канала
• wp_add_task_wait_count_vec — количество задач, ожидающих попадания в очередь

Ссылка на репозиторий проекта.

Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).

Ссылки на предыдущие части:

• Первая часть шаблона была посвящена HTTP серверу.
• Вторая часть шаблона была посвящена прототипированию REST API.
• Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
• Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.

Apache NlpCraft - библиотека с открытым исходным кодом, предназначенная для интеграции языкового интерфейса с пользовательскими приложениями. Новая версия 1.0.0 привнесла в проект наиболее существенные изменения за все время его существования. 

Основные идеи развития библиотеки были изложены в данной заметке, вкратце напомню их суть:

1. Предельное упрощение, отказ от всех вспомогательных enterprise возможностей, предельно точная фокусировка продукта.

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

Привет, Хабр! Мы крупная производственная компания с 50К+ сотрудников, и в 2019 году поняли, что нам нужно мобильное приложение. Срок реализации 5 месяцев. Какой стек вы бы выбрали при такой скорости? Мы выбрали нативные Kotlin и Swift. Поначалу запилили всего 6 сервисов (новости, зарплатный лист, отпуска, блоги, регистрацию опасностей, выдачу СИЗ), и даже при том, что нанесли минимальную пользу, приложение очень зашло, количество пользователей начало расти лавинообразно. И тут мы поняли, что серверная часть на node.js + PostgreSQL создана без всякой мысли о развитии и масштабировании, решала исключительно локальные задачи. Все было на неоптимальной монолитной архитектуре, развивать и поддерживать которую просто нельзя.

Расскажу, как мы решили проблему.

Решил описать свой подход построения окружения на Typescript с Nest на бекенде, Nuxt (SPA) на фронтенде. Все заворачивается в один docker‑образ и запускается как standalone приложение c nginx, healthcheck»ами, тестами и ш…широкой сферой применения.

Это не рейтинг Forbes из разряда “кто больше зарабатывает на маркетплейсах”. Это срез рынка, в котором работаем и мы сами. Третий год подряд наша команда делает обзор сервисов внешней аналитики маркетплейсов. Для начинающих и опытных селлеров, поставщиков, маркетологов, аналитиков. Мы старались, чтобы статья, в первую очередь, оказалась полезна тем, кто еще ищет свой сервис внешней аналитики маркетплейсов, оптимальный по цене-качеству. Не исключено, что кто-то и вовсе не видит надобности в сервисах внешней аналитики и считает, что успешно продавать на маркетплейсах можно и без них. Можно. Но это, словно ходить по улице с закрытыми глазами. Большая вероятность, что не туда придете. Если вы все же чувствуете потребность, что для вывода нового товара, увеличения объемов продаж и выручки, масштабирования бизнеса, вам просто необходимо следить за чужими показателями и быть в курсе, что хорошо, а что плохо продается на маркетплейсах, тогда можете потестить сервис внешней аналитики. Какой? Выбирайте, какие критерии для вас особенно важны и делайте выводы.

Рынок API продолжает расширяться. За последние годы количество разработчиков, использующих такие интерфейсы, выросло на 61 %. Продолжается тенденция, которую мы наблюдали годами. Чтобы понять, куда мы движемся, давайте рассмотрим некоторые ключевые тренды API и их влияние на бизнес сегодня и его будущее.

Раскрываем 12 кейсов проектирования спецификации REST API из практики red_mad_robot, которые помогут сэкономить время для разработки. А также объясняем, почему стоит следовать подходу contract first — писать спецификацию прежде кода.

В связи с быстро меняющимися технологиями разработчикам предоставляются невероятные инструменты и технологии.

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

Давайте взглянем на некоторые полезные веб-API, которые могут помочь вам поднять ваш сайт до небес! (ну или около того)

Привет всем, я, Надежда Дудник, главный инженер по тестированию в СБЕРе, а ещё ментор по тестированию ПО.

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

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

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

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

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

При выполнении каждого запроса API нам необходимо и важно проверить:

Привет, Хабр!

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

Привет, Хабр! Меня зовут Тимофей, я Python Engineer с опытом в 3+ года.

Я бы не назвал данную статью полноценным роадмэпом в том понимании, в котором это слово обычно используют. В статье нет сроков изучения, отсутствует подробный план, затрагивающей все темы и подтемы. Да и зачем нужен еще один роадмэп «под копирку», когда в сети и так хватает качественных предложений.

Скорее, я хотел бы составить абстрактный план обучения, который сможет задать общий ориентир, а также будет коррелировать с роадмэпом вроде roadmap.sh. Кроме этого, я смогу дать несколько полезных советов из своего опыта, а также составлю списки полезных ресурсов для изучения языка, сопутствующих инструментов и технологий, которые в свое время помогли или же помогают мне самому.

Привет, Хабр! Меня зовут Анастасия Иванова, я технический писатель МТС Exolve. В этой статье я расскажу о том, какие проблемы возникают у разработчиков и бизнеса с настройкой коммуникаций, каков нынче рынок Telecom API, для каких задач мы создали новую платформу и чем она может помочь вам.

Защита от изменений API, которые могут повлиять на ваших клиентов, — одна из самых больших проблем при разработке HTTP API. Если вы вносите критические изменения, то создаете клиентам серьёзные проблемы. Стабильный API — ключ к удовлетворенности клиентов и, в конечном счете, к успеху в бизнесе.

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