Существует ли облачная БД с REST API и простой аутентификацией?
Мне нужна очень простая вещь: возможность записи в БД по REST из моего мобильного приложения.
Угрохал очень много времени на поиск и проверку облачных БД, но пока так и не нашел нормального варианта.
Буду благодарен, если подскажете что-то из своего опыта.
Попробовал разные варианты - AWS, Firebase, cloud.mail.ru, Elastic, restdb.io
Основной критерий: простота аутентификации в БД, лучше всего на основе API Key, и простота использования самого API.
У монстров (AWS, Firebase, mail.ru) облачные сервисы очень навёрнуты и для простого обращения по REST требуется чуть ли не отдельное приложение написать + я так и не увидел возможности использования API Key.
Elastic - нормальный вариант в плане аутентификации, но у него очень уже сложный API. Нужно перекопать чуть ли не весь интернет, чтобы понять как сделать простой INSERT.
Restdb.io оказался лучшим вариантов в плане простоты интерфейса и удобства работы. Подключился очень быстро.
Но оказалось, что сервис не настолько надежен как хотелось бы (бывает, что ложится и долго не поднимается).
Если Вы знаете хороший вариант БД с простой аутентификацией и REST API, буду Вам очень благодарен за подсказку
Иван Шумов, не вижу ни каких проблем в адаптации упомянутого сервиса под ваше ключевое слово SAAS. БД позволяет Вам получить всю информацию о структуре данных. Вся информация о получаемых параметрах Вам тоже доступна. Остается только придумать правила (описание) преобразования (бизнес логику) получаемых параметров из одного "вида" в "другой". Это можно сделать несколькими способами. Выбирайте любой.
Привязка программной модели к модели данных (JPA), на мой взгляд, очень плохое решение. Как только Вы это осознаете, для Вас Spring, Hibernate и прочие подобные реализации становятся "программным мусором". Отказ от JPA дает Вам свободу модификации вашей системы при возникновении новых требований.
Кстати, отлично подходит для подобной реализации XSLT.
vl65, иииии *барабанная дробь* это так не работает. когда мы говорим про SAAS мы начинаем сталкиваться с совершенно другими проблемами: масштабирование, изоляция, нагрузка, объемы хранения данных, репликация, отказоустойчивость и еще много чего. Кроме того есть различные кейсы использования баз данных и может понадобиться разная фильтрация + потребуется аутентификация и авторизация + мы не должны забывать что есть сетевые издержки и такая вещь будет работать заведомо медленно. +мониторинг +Operation. И это я только слегка оцарапал поверхность этого айсберга)
Я не говорю что это невозможно. Просто это реально тяжелая задача с очень небольшой целевой аудиторией. Такие сервисы себе позволяют, в основном, такие гиганты как GCP, AWS, да и у них, в основном, это все работает внутри облака и они не рекомендуют использовать их вне (Firebase не в счет, он Client-side specific и не совсем база данных и не REST)
Иван Шумов, Работает! Именно по такому принципу построена (и по другому ее просто создать нельзя) высоконагруженная корпоративная система параллельных вычислений - распределенная, с множеством источников данных, с множеством узлов, территориально расположенная во множестве ЦОД. Подключение новых источников данных, подключение новых узлов - ни каких проблем не вызывает. Модификация системы - элементарно. Мониторинг присутствует. Авторизация и аутентификация - присутствуют. Система автоматического выхода из сбойных ситуаций присутствует. Режим разноверсионности ПО на разных узлах - присутствует (система сохраняет свою работоспособность при обновлении территориально разбросанных узлов)
Авторизация аутентификация это совершенно другая задача. Мониторинг совершенно другая задача. И прочие функции. Не надо валить разные задачи в кучу. Не разгребете!
vl65, SAAS включает себя полную автономность и полный цикл обслуживания, pricing модель, обратную связь, документацию и поддержку. И обеспечивается это для людей, а не для роботов. То что в SAAS бывают интеграции это нормально, но не обязательно) Очень часто SAAS путают с BAAS
К@inoise, Каждый узел - "многослойный пирог". В нем есть все, в том числе он может обслуживать и пользовательские запросы в автономном состоянии. Каждый узел при запуске пытается соединиться со всеми другими узлами и когда это связь устанавливается возможности узла по обслуживанию пользовательских запросов расширяются.
Иван Шумов, Клиент - понятие относительное и в общем случае обозначает инициатора запроса, обращения, потребителя услуги и т.д. "Многослойный пирог" - содержит в себе и "слой" клиента и "слой" сервиса. Система, которую я привел в качестве примера, оперативная система управления почти реального времени (есть некоторые задержки в сборе информации). В ней есть все, автоматическое планирование, прогнозирование, ситуационное моделирование и прочие " Business representative", если угодно, позволяющие принимать оперативному персоналу управленческие решения.
Можно эту систему перенастроить на совершенно другую предметную область? Можно. Что для этого нужно сделать. В основном заменить слой XSLT.
Простой
Средний
