Создавайте приложения так, чтобы они могли работать без пользовательского интерфейса или базы данных. Это позволит запускать автоматизированные регрессионные тесты, продолжать работу при недоступности базы данных, а также связывать приложения друг с другом без какого-либо участия пользователя.
Делимся опытом создания робота-диспетчера на low-code платформе n8n для обработки большого потока заказов. В статье рассказываем, как использовали Redis для очередей и динамической конфигурации, показываем реальные workflow и код, а также делимся, как боролись с утечками памяти и гонкой состояний. Будет полезно разработчикам, аналитикам и тимлидам, которые смотрят в сторону low-code для решения реальных бизнес-задач.
Команда Go for Devs подготовила перевод статьи о новом экспериментальном API для работы с JSON в Go. Спустя почти 15 лет после появления encoding/json в стандартной библиотеке разработчики столкнулись с его ограничениями. В версии Go 1.25 появился экспериментальный encoding/json/v2 — он решает старые проблемы, добавляет потоковую обработку и повышает производительность.
Многие частные инвесторы ведут свои портфели в Excel: это удобно, бесплатно и всё — на вашем компьютере. Но у Excel есть слабое место: он не умеет напрямую «разговаривать» с современными сайтами. Если нужно автоматически подтянуть котировку с конкретной страницы в интернете, встроенные веб‑функции часто не справляются: они не умеют обходить современные защиты.
В этой статье я покажу простой и надёжный способ заставить Excel получать котировки практически с любого сайта — на примере курса USD/RUB с investing.com. Идея не требует глубоких технических знаний: вместо того чтобы пытаться что-то делать со страницей в Excel, мы используем на своём компьютере небольшой скрипт‑посредник. Excel просто запрашивает у него одно число, а посредник уже «ходит» на сайт, берёт данные, при необходимости обрабатывает их и возвращает в понятном для Excel виде.
Приведённый Python‑скрипт (набор инструкций для этого «посредника») — это учебный пример: он предназначен исключительно для демонстрации принципа работы с API и веб‑технологиями. Я не призываю и не рекомендую использовать его для обхода правил каких‑либо сайтов.
Все исходные файлы проекта доступны в репозитории на GitHub.
В современном мире цифровых сервисов и микросервисной архитектуры, предоставление внешнего API становится критически важной задачей для любого бизнеса.
Хорошо спроектированный и надежный API — это ворота, через которые ваши данные и функциональность взаимодействуют с внешним миром: мобильными приложениями, веб‑сайтами, партнерскими сервисами и даже внутренними клиентами.
Команда Go for Devs подготовила перевод статьи о том, как превратить SQL в полноценный API прямо в Go. Автор показывает, как можно безопасно принимать WHERE-условия в виде SQL-подзапросов, валидировать их и использовать для запросов к базе. Просто, элегантно и почти без лишнего кода.
Основная часть работы современных разработчиков ПО1 связана с API: публичными интерфейсами для общения с программой, например, API Twilio. Я потратил кучу времени на работу с API как их разработчик и пользователь. Я писал публичные API для сторонних разработчиков, приватные API для внутреннего использования (или для потребления одной страницей фронтенда), API REST и GraphQL и даже несетевые интерфейсы, например, для инструментов командной строки.
Думаю, большинство рекомендаций по проектированию API слишком уж уходит в тонкости. Разработчики отвлекаются на обсуждения того, что же такое «реальный» REST, правильно ли использовать HATEOAS и так далее. В этом посте я попытаюсь рассказать всё, что знаю о проектировании хороших API.
В наши дни в мире разработки программного обеспечения, где взаимодействие между различными сервисами и системами является одним из самых важных моментов, глубокое понимание жизненного цикла API (Application Programming Interface) играет ведущую роль в успешном создании, поддержке и продвижении цифровых продуктов.
Жизненный цикл API охватывает весь путь от идеи и проектирования до вывода API из эксплуатации. С одной стороны, как правило, для многих специалистов достаточным для повседневной работы является знание не более шести-семи основных этапов жизненного цикла. С другой стороны, на практике жизненный цикл API может включать до десяти и более этапов, каждый из которых критически важен, ведь эффективное управление жизненным циклом API напрямую влияет на стабильность, производительность и безопасность всей системы.
В данной публикации я хотел бы рассказать про самые важные стадии жизненного цикла API, а также по каждому этапу добавить интересные статистические данные, проведя анализ основных международных отчётов, таких как Postman State of Api , NordicAPIs и многих других.
OpenAI сделала важный шаг для рынка голосовых интерфейсов: Realtime API официально вышел из бета-версии и теперь доступен всем разработчикам. Вместе с этим компания представила модель gpt-realtime, которая объединяет распознавание речи, генерацию текста и синтез голоса в одном API. Важно и то, что использование стало заметно дешевле, а цены на аудио-токены снижены на 20%.
Привет, Хабр! Меня зовут Евгений Лукин, я CPO продукта MWS OctAPI — это интеграционная платформа, которую мы создали для задач МТС, но теперь предлагаем как продукт на рынке.
Интеграционные платформы… кажется, что это что-то скучное и уже давно commodity — шины данных, kafka — вот это вот всё, что тут может быть интересного?
Да, но нет.
Фича для мобилки, которая должна работать на более ранних версиях.
Как подойти к реализации и преодолеть ограничения?
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Это третья статья из цикла «Проектирование GraphQL API».
В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.
В публикации поделюсь подробной инструкцией по разработке и запуску своего ИИ‑агента на Typescript с использованием MCP, который будет извлекать и выполнять команды, сказанные обычными словами и сможет опрашивать необходимую информацию через диалог с пользователем.
Привет, Хабр! Меня зовут Ваня, и я AQA-инженер. Как и многие из вас, я занимаюсь обучением будущих покорителей Postman и Pytest. И, как многие из вас, я столкнулся с проблемой: все существующие тестовые API — невыносимо скучные.
Todo-листы, интернет-магазины с товарами Item 1, Item 2, API для управления книгами... Серьезно? После пятого GET /todos начинаешь сомневаться не только в своей карьере, но и в смысле бытия. Данные в них стерильны, как операционная, а сценарии предсказуемы, как сюжет российского сериала.
Моим ученикам было скучно. Мне было скучно. Я понял, что нужен свой API. С блэкджеком и... ну, вы поняли. С API, который будет не просто функциональным, но и забавным. Который захочется «потыкать» просто ради того, чтобы увидеть очередной перл в ответе сервера.
Так родился «Cynical Circle API» — API для тех, кто понял жизнь и устал от ванильных примеров.
(Так выглядит наша интерактивная документация. Уже интригует, не правда ли?)
Хабр, привет! Меня зовут Елена Петренко, я бизнес-аналитик по информационной безопасности в компании R-Vision.
В прошлой статье мы подробно рассматривали интеграцию SOAR-системы с АСОИ ФинЦЕРТ для автоматизации взаимодействия с регулятором. Сегодня я расскажу, почему интеграции в целом являются ключевым элементом эффективного управления ИБ, какие бывают способы интеграции систем и рассмотрю практические кейсы интеграции SOAR с другими популярными сервисами: Telegram и Kaspersky Security Center, а также поделюсь опытом работы с АСОИ ФинЦЕРТ в более широком контексте.
Моя повседневная работа с основном связана с языком Elm. Благодаря сочетанию функционального языка и архитектуры Elm, многие архитектурные решения в нём получаются практически незаметными (подробнее об этом я рассказываю в этом посте у меня в блоге). Вы получаете четкое разделение задач, а язык по умолчанию подталкивает вас к хорошему проектированию.
Но моя работа не ограничивается Elm. Я часто создаю функции, которые охватывают как фронтенд, так и бэкенд — пишу новые конечные точки, а иногда даже проектирую новые таблицы баз данных. Когда я выхожу за пределы мира Elm, я вспоминаю, что архитектура — это то, к чему я должен снова относиться сознательно.
Этот пост не о том, какой код идет в какой слой, и не о конкретных паттернах проектирования. Прежде всего, я хочу поговорить об обманчиво простом выборе: следует ли просто реализовать то, что вам нужно, или же лучше начать с создания абстракции?
Иногда JSON выглядит рабочим, но под капотом он полон сюрпризов: лишние уровни вложенности, запутанные поля и непонятные даты. Разбираем пример и доводим структуру до ума.
Если Вы когда-либо разрабатывали Telegram-бота, Вы наверняка знаете, что такое callback_data. Если нет, вкратце, это произвольная строка, которая привязывается к кнопкам в чате, при помощи которой на бэкенде Вы определяете, какая именно кнопка была нажата.
Когда Ваш бот масштабируется, скорее всего управление значениями callback_data превращается в «кашу». По крайней мере, так произошло у меня. Поэтому сегодня я хочу поделиться с Вами практикой по организации этой всей «каши» в красивый и органичный код.
Исходя из моего 14 летнего опыта, большинство мечтает найти волшебную таблетку, которая поможет им решать их рабочие задачи. Вместо того, чтобы выучить базовые и необходимые знания, чтобы не испытывать сложностей в работе.
Предлагаю сегодня посмотреть на живом примере и понять могут ли нейросети заменить аналитиков?
