Сидел я в офисе и никого не трогал, занимался своими делами, иногда отвлекался на интересные новости с разных сайтов и спокойно писал код своего проекта. В таком ритме и закончился бы рабочий день не зайди ко мне один товарищ и не спросив у меня, что я думаю по поводу SaaS решения для БД (он говорил про Mongo). Мы немного пообщались, нашли mongohq.com и тут у меня родилось вполне четкое видение формата серверной части (для веб-проекта и не только) которая совершенно не нагружает твой сервер и ты можешь сконцентрироваться исключительно на разработке пользовательского функционала.
Небольшая ремарочка — все описанное дальше — не более чем идея и касается проектов по большей части работающих на стороне клиента, однако я постараюсь рассказать, как это можно исмпользовать и на обычных сайтах.
В чем собственно залючается идея
Как правило, из проекта в проект кочует множество повторяющегося кода, как для серверной части в целом, так и для БД в частности, это уже порядком надоело и хочется чего-то нового.
Давайте представим, что есть некий сервис, для удобства назовем его «конструктор приложения» или просто «конструктор», где разработчик может создать описание серверной части своего проекта в виде модели базы данных и контроллеров доступа.
Конструктор позволяет указать уровень доступа и список допустимых операций (CRUD) для каждого типа данных.
Мне кажется с этим проблем нет и таких конструкторов уже масса (кто использует — поделитесь ссылками, посмотрим вместе), но вот есть одна загвоздка — я (надеюсь не один такой) последние лет 5 программирую в основном на стороне клиента (JavaScript) и мне было бы весьма удобно иметь такой конструктор, который после крнфигурирования даст мне возможность обращаться через Ajax (WebSocket) к серверной части по адресу типа api.myhost.com (это если настроить алиас) или на край api.somedomain.com/my_app_id/ и тем самым получать данные об авторизации пользователя, взаимодействовать с данными от лица текущего авторизованного пользователя и не нагружать свой сервер для обработки и хронения данных.
Плюсы и минусы
+ можно вообще отказаться от чего либо кроме статики (nginx) на своем сервере и иметь огромный профит по нагрузке на сервер
+ можно совершенно спокойно использовать api как на сайте, так и из любого desktop или mobile приложения
+ писать только ту часть приложения которая касается пользователя и не напрягаться с серверной частью
— низкий функционал работы с данными на первоначальном этапе (CRUD only), что вполне можно в последствии усовершенствовать и предоставить более гибкий функционал
— не подойдет «уникальным» проектам со сложной серверной частью, собственно в таких случаях аутсорс не самый лучший вариант вообще
Простейший пример — блог
1 Заходим на сайт конструктора, регистрируем новое приложение и получаем ссылку на API.
2 Создаем три уровня пользователей — админ, авторизованный пользователь и аноним.
3 Регистрируем тип данных posts с полями заголовок, анонс, текст и метки.
4 Назначаем права доступа к данным типа Post для каждой категории пользователей.
В итоге у нас формируется описание интерфейса (API) примерно следующего содержания:
Адрес сущности api.somedomain.com/my_app_id/user/
Доступные методы
api.somedomain.com/my_app_id/post/
Доступные методы
и т.д.
При этом всю работу по авторизации/регистрации и прочего связанного с пользователем конструктор берет на себя.
Получив данное описание мы можем на стороне клиента формировать нужные нам запросы к серверу и работать с данными в зависимости от уровня доступа текущего пользователя.
Еще раз хочу напомнить, что все описанное — просто идея сервиса, который лично мне был бы полезен.
Сейчас существует масса решений подобного рода, но основная загвоздка — отсутствие возможности работать посредством Ajax вызовов и отстутствие удобной автоматической работы с пользователем (регистрация/авторизация и контроль доступа).
PS Зарание извиняюсь за сумбурность и возможные ошибки, очень редко пишу тексты для людей.
Автор: tsmar
