Q: Но это также означает, что мне придется поместить бизнес-логику в интерфейс, в веб-приложение Angular2, верно ?
Да. Если он не поддерживается сервером, бизнес должен быть реализован где-то.
После приобретения Google Firebase превратилась в платформу для разработчиков мобильных приложений, которые не могли позволить себе (или не нуждаются) развернуть свой собственный бэкэнд. Хотя большинство служб довольно трансверсальны: служба хранения, входа в систему, аналитики и сообщений, верно, что она также предоставляет облачные функции (своего рода лямбды), которые можно использовать для выполнения некоторых специфичных для бизнеса правил. Однако для корпоративных приложений или крупных приложений со сложным доменом и бизнес-логикой этот вид поддержки не работает.
Так что, как вы можете догадаться, Firebase не освобождает нас от серверной части, предназначенной для размещения и выполнения бизнес-специфических операций.
Q: Так что, если я когда-нибудь в будущем захочу создать интерфейс мобильного приложения, мне придется дублировать код бизнес-логики?
Не обязательно. Если веб-приложение построено на Angular, кроссплатформенность, такая как NativeScript, может позволить вам повторно использовать веб-компоненты, библиотеки, утилиты, модели и т. Д. Я не углубился в тему, поэтому не могу гарантировать вам полную совместимость. Ключ лежит на TypeScript , и Angular, и NativeScript требуют от нас написания кода на TS.
Вопрос в том, где разместить Javascript для его распространения и управления версиями . Слово CDN .
Q: Я полагаю, что альтернативой может быть создание бэкэнда, содержащего бизнес-логику и использующего Firebase для хранения данных, но это кажется немного странным (я не могу просто использовать ORM или что-то прямо в своем бэкэнде для достижения того же самого результат без лишней работы?)
Некоторые соображения.
С одной стороны, хостинг, развертывание, управление и поддержка базы данных - это немаловажная вещь. Не говоря уже об управлении безопасностью, масштабируемостью, доступностью и т. Д. Таким образом, забота о поставщике БД интересна. Это не сумасшедшая идея в наши дни иметь нашу базу данных где-то в облаке. Конечно, я бы не стал предлагать это, если бы мы внедряли промежуточное программное обеспечение и серверные части для банка. Но это может иметь смысл для сеанса клиента, профилей пользователей, предпочтений и данных такого рода, которые обычно находятся на стороне клиента, или данных, которые нас не волнуют.
С другой стороны, наличие нашего бэк-энда полезно по простой причине - разъединение .
Вместо того чтобы связывать наших клиентов со всеми видами услуг, которыми мы не управляем и не контролируем, мы разворачиваем серверное приложение, откуда мы заботимся об этих вещах, чтобы нашим клиентам не приходилось беспокоиться о таких проблемах, как отключение или поломка служб меняется. Кроме того, мы выигрываем от простоты, потому что наш сервер действует как фасад.
В: Как люди обычно структурируют такие приложения, если они хотят использовать, например, Firebase?
Это сильно варьируется от проекта к проекту. Например, мы используем Firebase + back-end.
Firebase DB для обмена данными между устройствами-учетными записями-сессиями . Также как журнал изменений, когда наш сервер временно недоступен, клиенты отправляют операции записи в журнал, который синхронизируется позже.
Firebase Cloud Messages предоставляет нам восходящие / нисходящие push-уведомления и темы. Мы используем сервис для обмена сообщениями pub / sub.
Аналитика Firebase В основном для метрик.
Back-end для всего, что строго связано с бизнесом