Стартап-идея и задача для Senior Web Developer: маркетплейс для SOA-приложений
Некоторая часть веб-приложений не пишется целиком, а использует уже существующие сторонние сервисы и их открытые интерфейсы обмена данными (API). Можно помочь разрабочикам собирать свои веб-пазлы с помощью каталога .
Хочу изложить тут. Вдруг кому пригодится. Сделаете сами — буду пользоваться. Пригласите меня архитектором — помогу всеми своими силами.
Хотел сделать интернет-сервис, который помогает другим интернет-сервисам обмениваться данными между собой, если они не относятся к одному проекту. Ну, например, если интернет-магазин хочет отправлять SMS-сообщения, но чтобы не опускаться на уровень протокола SMPP, а ограничиться веб-сервисами на HTTP, которые предоставляет провайдер связи. Пример API для отправки SMS.
Сервисов просто завались сколько. Это целая парадигма — приложения на базе Service Oriented Architecture (SOA). Некоторые хорошо известны и неплохо монетизируются, а некоторые пылятся в безызвестности. Пример список API для маркетинга.
Фишка проекта для веб-сайтов, которые используют сторонние API
1. Хорошая документация (пример Stripe) и средства отладки (пример Icons8) для всяких разных сервисов
2. Возможность использовать в приложениях на разных языках (аутсорсеры портируют на нужный язык, если ещё не поддерживается)
3. Обратная связь с владельцами сервисов при проблемах («Хей, твой API сдох!» или «А не добавить ли вам такую-то фишку?», в том числе мониторинг и тестирование в реальном времени)
4. Штат аутсорсеров для помощи в встраивании сервисов в клиентским сайты («Я не программист, как мне поставить на сайт виджет обратного звонка?»)
5. Тот же штат мог бы заняться перенастройкой клиентских сайтов, если сервис вдруг умер или найдён более дешёвый
Фишка для сервиса-провайдера API
1. Можно иметь форум для идей и предложений по улучшению сервисов. Опыт показывает, что у клиентов безграничная фантазия.
2. Если сервис поддерживает несколько версий своего ПО, то можно в реальном времени узнать, какая версия перестала использоваться. Позволит вывести из эксплуатации старые версии.
3. Можно связаться с теми, кто использует сервис устаревшей версии и предложить услуги аутсорсеров в помощь для перенастройки клиентских сайтов на новую версию
Фишка для аутсорсеров
1. Ещё один вид заработка, довольно быстро становится простой механической работой. Клиенты иногда и не догадываются, что поставить виджет обратного звонка занимает гораздо меньше часа, за который они платят.
Монетизация
1. Аутсорсеры, почасовая плата за доработки сайтов клиентов — процент с заработка аутсорсеров, как на Upwork
2. Составлении документации и тестовых стендов — плата с провайдеров API
3. Сбор за транзакции, за передачу данных между клиентом и сервисом — сбор с клиентских сайтов
4. Платные возможности типа вот мониторинга использования версий и тестирования — плата с провайдеров API
5. Клиентская поддержка без участия провайдера API
6. Хостинг для провайдера API на своих серверах
Три года пролежало в задачнике, не было ни сил самому сделать, ни способностей людей собрать. Удалил и забыл.
И ещё за это время появился сервис Mashape, частично воплотивший мою идею. А также RapidAPI , ProgrammableWeb , IFTTT, Datadog, и ещё много много много разных.
Что делать с идеей, если она больше не нужна?
На ней можно потренироваться проектировать большие системы. Давайте поиграем в архитекторов большого веб-проекта.
Вопрос первый: Предположим, по маркетинговым исследованиям было выяснено, что сервис, реализующий описанную идею маркеплейса для API, будет коммерчески эффективным. Что бы ты делал дальше? С чего бы начал реализацию?
Ответы оставляй тут в комментариях или присылай мне почтой. Все разберём, всё обсудим.
Изображение Network by Richard-Cederfjard.
