Итак, суть в том. Что уже есть сервис который успешно работает.
Сейчас стоит задача разработать лендинги(скорее даже виджеты), для чатбота Telegram.
В дальнейшем планируется создать новую версию Личного кабинета SPA (смотрим в сторону ангуляра), где также будут использоваться эти самые виджеты.
Но вернемся к тому что нужно разработать виджеты, и задача в том чтобы придумать оптимальный подход к разработке.
Приоритеты у заказчика:
Скорость загрузки виджета.
Скорость разработки и внедрения.
1. вариант который мне предложили, это просто купить шаблон на Themforest для админки, и на его основе делать верстку отдельных виджетов. Но этот вариант мне не особо по душе, т.к. у нас будет в приоритете скорость загрузки, эти шаблоны используют кучу разных библиотек, которые будет необходимо грузить каждый раз когда пользователь telegram будет посылать очередной запрос боту, Так этот вариант наложит многие ограничения. Плюсы этого варианта только в том что будет уже много разных готовых компонентов.
2. Взять за основу css фремворк к примеру bootsrap или fundation, и уже самим верстать компоненты которые будут использоваться в виджетах, это уже даст больший простор для оптимизации скорости, и позволит самим решать когда и какие дополнительные библиотеки нам использовать.
3. Вариант который на мой взгляд будет самым лучшим, это взять и самим написать css фреймворк заточеный под наши нужды. Это предоставит нам возможность иметь общую структуру стилей которые мы можем использовать в SPA, и при том иметь отдельные изолирование компоненты, которые можно будет отдельно загружать при этом исключая стили библиотеки и т.д. которые будут использовать другие виджеты. И самое главное это позволит свести к минимуму вес загружаемого контента, минимум js, минимум css. Минус только в том, что порог вхождения новых разработчиков будет ниже чем первых двух вариантах. А также займет дополнительное время на написание сборщика под этот проект, и написание документации.
Итак вопрос в том, что может кто-то даст совет, или подскажет еще какой либо вариант, возможно я что-то упускаю, т.к. для меня это первый такой необычный проект.
А не просто сайт где все понятно и просто. Для меня 1 вариант был бы хорошим если бы нам нужно было просто разработать SPA. Но ребята хотят сделать виджеты, и при этом они хотят чтобы мы потом с минимальными потерями могли быстро их внедрять в SPA.
И сейчас я вижу это так, что при первом варианте пользователь условно будет грузить каждый раз ~2mb не нужного хлама.
Во втором : 1mb
В третьем: 0.3-5mb
P.s. Чатбот должен присылать ссылку, которая открывается в браузере.
А в чем тут собственно проблема? Возьмите для бутстрэпа скачайте тэмплэйт админки, как понимаю вам нужен дэшбоард - их миллиард. Бутстрэп можно скомпилировать оставив только нужные компоненты. в 3 случае мне кажется вы очень долго будете тестировать фронтэнд
смотрите, да потом нужен будет дашборд (я и писал про них это как раз 1 вариант). Сейчас отдельные компоненты. Понятно что можно взять и выпилить для конкретного компонента все не нужно. но тогда это будут независимые дубликаты которые. которые по отдельности надо будет править. то есть у нас будет отдельный компонент. И будет дашборд со всеми. я предвижу что будут проблемы с их совмещением, и поддержкой. Будет крайне неудобно работать в таком режиме. а в 3 варианте, я смогу организовать так что у нас будет общая система сборки на том же Gulp, которая будет хранить общую структуру и параллельно будет сохранять отдельно виджеты с видами и зависимостями. то есть при первом варианте будет больше проблем потом, при 3м варианте больше времени на начальном этапе.
Раз уж речь идет о SPA, то вы явно будете переписывать/дорабатывать бекенд для работы через API, а значит ничего не мешает написать клиенты на чем угодно что уже знают ваши разработчики. Естественно в идеале выбирать один инструментарий для использования во всех клиентах(веб/мобильный/десктоп). Из популярных сейчас вариантов можно посмотреть на ReactJS/ReactNative, но стоит учитывать что для вашей задачи это может быть просто оверкил.
Для оформления как раз лучше второй вариант, то есть готовая популярная css-библиотека, для которой просто написать свои темы.
Переживать о размере библиотек в SPA точно не стоит: первая загрузка будет достаточно долгой(не забудьте сделать индикацию), но потом все будет браться из кеша, да и страница обновляться ведь не будет, все данные будут подгружаться по надобности и рендерится уже на клиенте.
Что касается чат-бота: не совсем понял о чем вы переживаете - вы же пользователю будете отдавать текстовую ссылку. Ну а при заходе пользователя на сайт вполне разумно сразу же детектить платформу клиента(например средствами nginx) и редиректить на соответствующую версию: легкую мобильную или полноценную или вообще на родной клиент в сторе, только лучше сразу предусмотрите возможность ручной установки нужной версии пользователем.
Спасибо за ответ. По поводу веса в SPA я не переживаю. Смотрите. Само приложение предназначено для работы с финансами, счетами. И как раз SPA. сейчас уходит на второй план, т.к. уже пока имеется приложение для работы. И сейчас нужно написать лендинги которые будут доступны через бота в телеграмм. И как я это вижу. Например я хочу быстро увидеть график расходов за какой-то период. С бекендом там все норм. За это можно не волноваться. Мне дают JSON, и все я кручу и веру как хочу. Вопрос в другом. Пользователь должен получить график расходов за период а также иметь возможность менять период. График например будет геннерироваться на клиенте через какой нибудь chart.js. И больше никакого функционала.
И вот я могу например сейчас взять за основную готовые варианты, и для каждого такого виджета выпиливать все лишнее. Но они будут будут слишком самостоятельными, и фактически при разработке SPA нужно будет пилить по новой отдельно все эти же компоненты.
А если использовать 3 вариант, я смог сделать так, что у нас будут отдельные лендинги, без всех лишних зависимостей, под каждый частный случай, но при этом они в dev версии будут частью SPA.
А если мы забиваем на все и пилим SPA, и бот будет отправлять постоянно на него я думаю это не очень хорошая идея. т.к. телеграм открывает окно браузера не отдельно, а внутри себя. Поэтому насчет кеширования если честно не знаю, возможно ли его использовать.
Я почему то считаю, очень важно, максимально минимизировать все, что если контент сумарно будет весить 400 кб вместо 2-3000 кб, будет очень существенно.
Дмитрий Горбач: Ну значит все значительно проще, если вы собираетесь SPA делать на ангуляре так и пишите свои виджеты прямо под него, а на лендинги подгружайте минимально необходимую сборку ангуляра чтобы виджеты заработали и применяйте нужные стили. Тогда у вас не будет ни дублирования кода, ни лишней работы вообще.
На счет Телеграма я все же не понимаю о каком внутреннем браузере речь? - О превьюшках страниц при отправке ссылки? Просто у меня на андроиде все ссылки он открывает в системном браузере, а в чате только небольшие превью в виде заголовка и картинки.
FeNUMe: Не, я так понимаю, он использует системный браузер. только он открывает окно внутри приложения, а не отельным приложением. Вроде так. Насчет ангуляра понял. А что насчет стилей, делать по первому варианту? или все таки писать основу самим?
Дмитрий Горбач: Как по мне зависит от того насколько сложное у виджетов будет оформление. Но опять же учитывая что в SPA вы явно будете использовать какой-то готовый фреймворк со своими темами(как вариант купленными на тех же Themforest и тд), то я не вижу ни малейшего смысла не использовать его же для оформления виджетов и на лендингах. Просто в SPA будете подключать полную css-тему, а для лендингов вынесете оформление виджетов отдельно и подключите маленький файл(естественно поверх минимизированой версии основного фреймворка).
Это как минимум обеспечит унификацию разработки, единообразие интерфейсов, качественную кроссбраузерность. При выкатке на продакшен можно будет базовые библиотеки подключить из крупных CDN типа гугла/яндекса, чтобы они грузились с ближайшего к клиенту датацентра, а не с вашего сервера. Только обязательно указывайте конкретную версию, чтобы апдейты ничего вам не сломали.
Простой
Простой