Как сделать админку? (несколько приложений в связке)
Пожалуй главным преимуществом FlutterFlow (в сравнении с другими конструкторами) я бы назвал независимую базу данных. То есть разработчики, которые пилят FF и разработчики, которые работают над Firebase - это разные команды, которые не факт, что вообще друг с другом знакомы.
Это приводит к тому, что мы можем запустить несколько FlutterFlow проектов на одной базе данных Firebase! И скажу по своему опыту, 70% коммерческих заказов этого требуют.
Как это выглядит на практике?
Приходит к вам клиент и говорит - “Хочу сделать приложение для своей турбазы” (ну вот такие сегодня примеры)) То есть в приложении клиенты смогут, например, брать лыжи напрокат, забронировать экскурсию, заказать доставку в номер и тд. “Сколько это будет стоить?” - обычно это следующий вопрос, после такого краткого описания.
“Подождите, давайте уточним пару моментов” – обычное продолжение разговора с моей стороны. – «Ассортимент экскурсий и цены на них всегда постоянны, мы просто в приложение их зашьем? А как ваши работники будут отслеживать, кто какие лыжи взял и когда должен вернуть? А вот клиент заказал доставку в номер - кто этот заказ получает и кто должен его обработать? А если жалоба есть, то кому писать?»
Клиент в такой момент, как правило, начинает импровизировать: “ну на лыжи вот у нас терминал есть, на заказах Светочка сидит, а экскурсии у нас просто в брошюрах распечатаны”.
– Не, так не пойдет. Если уж давать клиентам приложение, то и все остальные процессы на этом приложении должны быть завязаны. Поэтому, Иван Иванович, нужно делать еще приложение для сотрудников, чтобы через него можно было управлять ассортиментом экскурсий, реагировать на жалобы, получать заказы и тд. Согласны?
То есть за приложение для клиентов мы называли цену Х, но приложения то получается два...
Итоговая цена: 2Х. Работаем? 😎
Заигрался я с прямой речью =))
Короче, таких кейсов ☝️ на практике очень много, ведь любому приложению нужна поддержка.
Для этих целей разрабатывают отдельный функционал “для сотрудников”, или “для администратора” (та самая админка). У некоторых заказчиков (те самые процентов 30%) все уже есть и они вам дадут просто API, но большинство закажет у вас разработку этих модулей.
Идем дальше - а как разработать эту админку?
На любом конструкторе сделать это можно “в лоб”, то есть в рамках одного приложения. Например, если у вас у пользователь - “клиент”, то ему показывается экран клиента, если пользователь “админ”, то показываются экраны с дашбордами, графиками и всем прочим. Но такое решение (держать несколько совершенно разных ролей в одном приложении) нежелательно. Причины:
1️⃣ Сложно поддерживать (вам, как разработчику) такой проект. Экранов, разных редиректов, условий, проверок, что “не админ”, там слишком много.
2️⃣ Решение само по себе костыльное. (Уважаемые сотрудники! Скачайте приложение для клиентов, нажмите на замочек в левом верхнем углу экрана, введите эти логины и пароли, чтобы попасть в приложение. Мы сэкономили и сделали через жопу, просим прощения). А если ваш сотрудник тоже пользуется вашим приложением (как клиент), то ему еще и перелогиниваться постоянно придется - вот радость то.
3️⃣ Легко сломать. Так как приложение одно, то дорабатывая функционал сотрудников, например, можно нечаянно задеть функционал клиентов.
И это базовый сценарий, когда в приложении 2 роли (клиент и админ). А если будет больше?))
Поэтому, хорошим решением будет просто создать отдельное приложение на той же базе данных. Во FlutterFlow делается элементарно: создаете проект в FF (например, приложение клиента), подключаете к Firebase, затем создаете новый проект в FF (например, админка) и так же привязываете к ТОМУ ЖЕ Firebase (в проекте клиента, в разделе firebase перед этим нужно нажать Remove). Все!
У вас два независимых проекта, но которые смотрят на общую базу.
Стоить ваша работа будет тоже дороже (чисто психологически), чем если бы вы сделали разделение в рамках одного приложения. 2 приложения (или приложение + сайт) – это ведь уже почти своя IT-компания =)
Пожалуй главным преимуществом FlutterFlow (в сравнении с другими конструкторами) я бы назвал независимую базу данных. То есть разработчики, которые пилят FF и разработчики, которые работают над Firebase - это разные команды, которые не факт, что вообще друг с другом знакомы.
Это приводит к тому, что мы можем запустить несколько FlutterFlow проектов на одной базе данных Firebase! И скажу по своему опыту, 70% коммерческих заказов этого требуют.
Как это выглядит на практике?
Приходит к вам клиент и говорит - “Хочу сделать приложение для своей турбазы” (ну вот такие сегодня примеры)) То есть в приложении клиенты смогут, например, брать лыжи напрокат, забронировать экскурсию, заказать доставку в номер и тд. “Сколько это будет стоить?” - обычно это следующий вопрос, после такого краткого описания.
“Подождите, давайте уточним пару моментов” – обычное продолжение разговора с моей стороны. – «Ассортимент экскурсий и цены на них всегда постоянны, мы просто в приложение их зашьем? А как ваши работники будут отслеживать, кто какие лыжи взял и когда должен вернуть? А вот клиент заказал доставку в номер - кто этот заказ получает и кто должен его обработать? А если жалоба есть, то кому писать?»
Клиент в такой момент, как правило, начинает импровизировать: “ну на лыжи вот у нас терминал есть, на заказах Светочка сидит, а экскурсии у нас просто в брошюрах распечатаны”.
– Не, так не пойдет. Если уж давать клиентам приложение, то и все остальные процессы на этом приложении должны быть завязаны. Поэтому, Иван Иванович, нужно делать еще приложение для сотрудников, чтобы через него можно было управлять ассортиментом экскурсий, реагировать на жалобы, получать заказы и тд. Согласны?
То есть за приложение для клиентов мы называли цену Х, но приложения то получается два...
Итоговая цена: 2Х. Работаем? 😎
Заигрался я с прямой речью =))
Короче, таких кейсов ☝️ на практике очень много, ведь любому приложению нужна поддержка.
Для этих целей разрабатывают отдельный функционал “для сотрудников”, или “для администратора” (та самая админка). У некоторых заказчиков (те самые процентов 30%) все уже есть и они вам дадут просто API, но большинство закажет у вас разработку этих модулей.
Идем дальше - а как разработать эту админку?
На любом конструкторе сделать это можно “в лоб”, то есть в рамках одного приложения. Например, если у вас у пользователь - “клиент”, то ему показывается экран клиента, если пользователь “админ”, то показываются экраны с дашбордами, графиками и всем прочим. Но такое решение (держать несколько совершенно разных ролей в одном приложении) нежелательно. Причины:
1️⃣ Сложно поддерживать (вам, как разработчику) такой проект. Экранов, разных редиректов, условий, проверок, что “не админ”, там слишком много.
2️⃣ Решение само по себе костыльное. (Уважаемые сотрудники! Скачайте приложение для клиентов, нажмите на замочек в левом верхнем углу экрана, введите эти логины и пароли, чтобы попасть в приложение. Мы сэкономили и сделали через жопу, просим прощения). А если ваш сотрудник тоже пользуется вашим приложением (как клиент), то ему еще и перелогиниваться постоянно придется - вот радость то.
3️⃣ Легко сломать. Так как приложение одно, то дорабатывая функционал сотрудников, например, можно нечаянно задеть функционал клиентов.
И это базовый сценарий, когда в приложении 2 роли (клиент и админ). А если будет больше?))
Поэтому, хорошим решением будет просто создать отдельное приложение на той же базе данных. Во FlutterFlow делается элементарно: создаете проект в FF (например, приложение клиента), подключаете к Firebase, затем создаете новый проект в FF (например, админка) и так же привязываете к ТОМУ ЖЕ Firebase (в проекте клиента, в разделе firebase перед этим нужно нажать Remove). Все!
У вас два независимых проекта, но которые смотрят на общую базу.
Стоить ваша работа будет тоже дороже (чисто психологически), чем если бы вы сделали разделение в рамках одного приложения. 2 приложения (или приложение + сайт) – это ведь уже почти своя IT-компания =)