Аутсорсим back-end для своего сервиса или сайта

Сидел я в офисе и никого не трогал, занимался своими делами, иногда отвлекался на интересные новости с разных сайтов и спокойно писал код своего проекта. В таком ритме и закончился бы рабочий день не зайди ко мне один товарищ и не спросив у меня, что я думаю по поводу SaaS решения для БД (он говорил про Mongo). Мы немного пообщались, нашли mongohq.com ^[1] и тут у меня родилось вполне четкое видение формата серверной части (для веб-проекта и не только) которая совершенно не нагружает твой сервер и ты можешь сконцентрироваться исключительно на разработке пользовательского функционала.
Небольшая ремарочка — все описанное дальше — не более чем идея и касается проектов по большей части работающих на стороне клиента, однако я постараюсь рассказать, как это можно исмпользовать и на обычных сайтах.

В чем собственно залючается идея

Как правило, из проекта в проект кочует множество повторяющегося кода, как для серверной части в целом, так и для БД в частности, это уже порядком надоело и хочется чего-то нового.
Давайте представим, что есть некий сервис, для удобства назовем его «конструктор приложения» или просто «конструктор», где разработчик может создать описание серверной части своего проекта в виде модели базы данных и контроллеров доступа.
Конструктор позволяет указать уровень доступа и список допустимых операций (CRUD) для каждого типа данных.
Мне кажется с этим проблем нет и таких конструкторов уже масса (кто использует — поделитесь ссылками, посмотрим вместе), но вот есть одна загвоздка — я (надеюсь не один такой) последние лет 5 программирую в основном на стороне клиента (JavaScript) и мне было бы весьма удобно иметь такой конструктор, который после крнфигурирования даст мне возможность обращаться через Ajax (WebSocket) к серверной части по адресу типа api.myhost.com ^[2] (это если настроить алиас) или на край api.somedomain.com/my_app_id/ ^[3] и тем самым получать данные об авторизации пользователя, взаимодействовать с данными от лица текущего авторизованного пользователя и не нагружать свой сервер для обработки и хронения данных.

Плюсы и минусы

+ можно вообще отказаться от чего либо кроме статики (nginx) на своем сервере и иметь огромный профит по нагрузке на сервер
+ можно совершенно спокойно использовать api как на сайте, так и из любого desktop или mobile приложения
+ писать только ту часть приложения которая касается пользователя и не напрягаться с серверной частью

— низкий функционал работы с данными на первоначальном этапе (CRUD only), что вполне можно в последствии усовершенствовать и предоставить более гибкий функционал
— не подойдет «уникальным» проектам со сложной серверной частью, собственно в таких случаях аутсорс не самый лучший вариант вообще

Простейший пример — блог

1 Заходим на сайт конструктора, регистрируем новое приложение и получаем ссылку на API.
2 Создаем три уровня пользователей — админ, авторизованный пользователь и аноним.
3 Регистрируем тип данных posts с полями заголовок, анонс, текст и метки.
4 Назначаем права доступа к данным типа Post для каждой категории пользователей.

В итоге у нас формируется описание интерфейса (API) примерно следующего содержания:
Адрес сущности api.somedomain.com/my_app_id/user/ ^[4]
Доступные методы
api.somedomain.com/my_app_id/post/ ^[5]
Доступные методы
и т.д.

При этом всю работу по авторизации/регистрации и прочего связанного с пользователем конструктор берет на себя.

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

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

Сейчас существует масса решений подобного рода, но основная загвоздка — отсутствие возможности работать посредством Ajax вызовов и отстутствие удобной автоматической работы с пользователем (регистрация/авторизация и контроль доступа).

PS Зарание извиняюсь за сумбурность и возможные ошибки, очень редко пишу тексты для людей.

Автор: tsmar

Источник ^[6]