The post has been translated automatically. Original language: Russian
During integration development, a simple problem often arises: an external service has to send a webhook, and your backend is located on a local machine, behind a NAT or firewall.
At first glance, this is a small thing. But it is often the beginning of a long debugging process.
Hello. My name is Yuri Melnikov. I am a developer with more than ten years of experience and have worked on various backend and integration tasks in companies in Kazakhstan and beyond.
When working with external services, one of the first difficulties is receiving incoming requests. For example, you are setting up integration with CRM, payment system, Telegram bot or no-code platform. The service should send a webhook, but your backend is running locally on the laptop.
The laptop can be at home, in the office or in a cafe. It can be hidden behind a NAT, restricted by a firewall, or connected to a network without a static IP address. Port forwarding in such a situation does not always help: it may not be possible in an office network, and at home or on a public network you may not have control over the router at all.
Even if there is an external IP address, there remains one more problem: many services require HTTPS. This means that simply forwarding the port is no longer enough. You need a public domain, a web server and a valid TLS certificate.
It's a pretty difficult path for the task of “just getting a test query”, isn't it?
I have encountered this problem quite often and at some point decided to make a tool for myself that will be visible from the Internet, have a public address and HTTPS, but at the same time be able to deliver incoming requests to my local backend as if they came directly to it.
This is how Adal appeared, a service for delivering and debugging webhooks.
At first it was a small utility for forwarding requests to a local machine. Then the project grew: Adal began to save incoming requests, show them in the dashboard, deliver them after the connection was restored, support resending and help figure out what exactly came from an external service.
Adal is currently in a public beta version. It can be used for local development, integration testing, incoming request inspection, and delivery of webhooks to a local backend or external URL.
If you are a developer, CTO, DevOps engineer, or work with API integrations, I will be glad to receive feedback, comments, and ideas on service development.
The project's website: https://adal.cloud
Во время разработки интеграций часто возникает простая проблема: внешний сервис должен отправить webhook, а ваш backend находится на локальной машине, за NAT или firewall.
На первый взгляд это мелочь. Но именно с неё часто начинается долгая отладка.
Здравствуйте. Меня зовут Юрий Мельников. Я разработчик с более чем десятилетним опытом и работал над разными backend- и integration-задачами в компаниях Казахстана и за его пределами.
В работе с внешними сервисами одна из первых сложностей — это получение входящих запросов. Например, вы настраиваете интеграцию с CRM, платёжной системой, Telegram-ботом или no-code платформой. Сервис должен отправить webhook, но ваш backend запущен локально на ноутбуке.
Ноутбук может быть дома, в офисе или в кафе. Он может быть спрятан за NAT, ограничен firewall или подключён к сети без статического IP-адреса. Проброс портов в такой ситуации не всегда помогает: в офисной сети это может быть невозможно, а дома или в публичной сети у вас может вообще не быть контроля над роутером.
Даже если внешний IP-адрес есть, остаётся ещё одна проблема: многие сервисы требуют HTTPS. Значит, простого проброса порта уже недостаточно. Нужен публичный домен, web-сервер и действующий TLS-сертификат.
Довольно сложный путь для задачи “просто получить тестовый запрос”, не так ли?
С этой проблемой я сталкивался достаточно часто и в какой-то момент решил сделать для себя инструмент, который будет виден из интернета, иметь публичный адрес и HTTPS, но при этом сможет доставлять входящие запросы на мой локальный backend так, словно они пришли прямо на него.
Так появился Adal — сервис для доставки и отладки webhooks.
Сначала это была небольшая утилита для пересылки запросов на локальную машину. Затем проект вырос: Adal начал сохранять входящие запросы, показывать их в dashboard, доставлять их после восстановления соединения, поддерживать повторную отправку и помогать разбираться, что именно пришло от внешнего сервиса.
Сейчас Adal находится в публичной beta-версии. Его можно использовать для локальной разработки, тестирования интеграций, инспекции входящих запросов и доставки webhooks на локальный backend или внешний URL.
Если вы разработчик, CTO, DevOps-инженер или работаете с API-интеграциями, я буду рад обратной связи, замечаниям и идеям по развитию сервиса.
Сайт проекта: https://adal.cloud
Share
