Я собираюсь начать разработку одностраничного веб-приложения, которое очень упростит многопользовательскую систему документации. Внешний интерфейс, вероятно, будет использовать Angular2.
У проекта короткий срок, поэтому я искал «горячие клавиши», т.е. использовал различные готовые сервисы вместо того, чтобы реализовывать все с нуля.
Мне понадобится какой-то бэкэнд для хранения данных приложения. Я осмотрелся и нашел Firebase, который, похоже, отнимает часть работы по созданию отдельного бэкенда и API для взаимодействия с внешним интерфейсом.
Но это также означает, что мне придется поместить бизнес-логику в интерфейс, в веб-приложение Angular2, верно?
Так что, если я когда-нибудь в будущем захочу сделать внешний интерфейс мобильного приложения, мне придется дублировать код бизнес-логики?
Я полагаю, что альтернативой может быть создание бэкэнда, содержащего бизнес-логику и использующего Firebase для хранения данных, но это выглядит немного странно (я не могу просто использовать ORM или что-то прямо в своем бэкэнде для достижения того же результата без много больше работы?)
Как люди обычно структурируют такие приложения, если они хотят использовать, например, Firebase?
источник
Ответы:
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 для всего, что строго связано с бизнесом
источник
Краткий ответ: не используйте бизнес-логику.
Длинный ответ: Вы описываете приложение, которое кажется достаточно маленьким, чтобы не иметь отдельной бизнес-логики; сначала оцените, действительно ли у вас есть такая бизнес-логика; много бизнес-логики может быть уменьшено дизайном данных, и немного - уровнем представления. Многие небольшие системы в основном CRUD и не имеют реальной бизнес-логики; Много раз я видел два или три слоя классов, которые являются просто сквозными объектами, оставляя место для будущего, которое никогда не наступит.
Вы можете начать с API прямо из Firebase, а затем ввести дополнительный уровень для бизнес-логики, когда обнаружите, что в этом есть реальная потребность, если вы достаточно хорошо разработали свой контракт, чтобы служба сохраняла стабильную подпись, в то время как реализация может измениться.
источник
см. /programming/54994228/how-to-minimise-firebase-function-latency
Cloud Firestore является основным и единственным соединением между интерфейсом и сервером. Конечно, некоторая логика может присутствовать во внешнем интерфейсе, но для обеспечения безопасности, как правило, это может быть только для пользы пользователя в автономном режиме. Вы должны реализовать безопасность в самих коллекциях Cloud Firestore, обеспечивая безопасность для ролей или чего угодно.
Затем используйте функции Cloud, которые вызываются из триггера Cloud Firestore.
Вы НЕ ДОЛЖНЫ вызывать облачную функцию из интерфейсного приложения.
источник