Простой ответ - да, это возможно. Сложный ответ - да, но вы, вероятно, не захотите

Как дизайнер, владелец бизнеса или любой другой человек, не занимающийся программированием, Webflow является чрезвычайно мощным инструментом для создания статических маркетинговых веб-сайтов. Однако, если вы использовали Webflow достаточно долго, вы, вероятно, захотели, чтобы он позволил вам выйти за рамки создания простого веб-сайта.

В реальном мире нам часто нужны веб-приложения, а не веб-сайты. Мы можем создавать цифровые продукты с зонами членства, возможностью предоставлять клиентам персонализированный контент или другими функциями, выходящими за рамки возможностей Webflow.

Я провел несколько лет в окопах, используя Webflow для создания различных веб-сайтов и веб-приложений. За это время я обнаружил, что отвечаю на одни и те же вопросы клиентам и коллегам-разработчикам о жизнеспособности Webflow как «правильного» инструмента разработки.

В этой статье я основываюсь на моем реальном опыте, чтобы представить мои выводы с использованием Webflow в качестве интерфейсной среды, его CMS в качестве базы данных и чтобы вы могли принимать обоснованные решения по вашему следующему проекту.

1. Как Webflow можно использовать как интерфейсный инструмент для создания веб-приложений?

TL; DR: Вы можете взломать его и заставить работать. Но это раздражает, не масштабируется, и в конечном итоге вам почти всегда будет лучше использовать инструменты, созданные для работы. Если вы создаете «настоящее» приложение, используйте «реальный» фреймворк.

Веб-сайты, создаваемые Webflow, являются просто статическими активами. В отличие от Wordpress, у вас нет доступа к какому-либо серверному коду. Это означает, что для использования Webflow в качестве интерфейсной среды вам придется написать много JavaScript (или jQuery, если это вам нравится).

Видите ли, единственный способ взаимодействия с вашим сайтом - это управлять DOM напрямую, используя скрипты (которые Webflow позволяет вам добавлять на ваш сайт). Это отличается от подхода современной интерфейсной инфраструктуры, который использует виртуальные модели DOM и абстрагирует нас от реальных элементов HTML.

Некоторое время назад я сделал серию видео, в которой показана настройка аутентификации пользователя на сайте Webflow с помощью Firebase. Изученные здесь принципы могут быть применены для достижения гораздо большего, чем показано в видеороликах - таким образом вполне возможно создать веб-приложение.

Однако я не верю, что Webflow подходит для любого серьезного приложения. Вот почему.

1.1 В Webflow нет понятия ветвления

TL; DR: В «правильных» приложениях, как правило, вы никогда не работаете непосредственно с живым исходным кодом. При использовании Webflow в качестве интерфейсной среды нет жизнеспособного способа не работать непосредственно на вашем действующем сайте.

«Настоящие» приложения имеют исходный код, который находится в репозитории (например, GitHub). Этот исходный код обычно имеет разные ветки, которые позволяют разработчикам управлять контролем версий.

Обычно «главная» ветвь содержит исходный код, который запускает текущую действующую версию приложения. Разработчики часто работают в других ветвях или дочерних ветвях «разработки», где они создают новые функции или вносят обновления.

Затем они тестируются и попадают в главную ветку. Этот процесс гарантирует, что непроверенные изменения не сломают работающее приложение.

В Webflow нет понятия ветвления. Это делает использование его в качестве интерфейсной среды рискованным, поскольку все изменения должны вноситься непосредственно в действующую версию вашего сайта.

Вы можете в некоторой степени обойти это, дублируя свой сайт Webflow для создания версий, но это обременительно и обходится дорого, поскольку вам часто нужно покупать новый план хостинга (Webflow не позволяет переносить платный хостинг с одного сайта на другой. ).

1.2 Вы должны управлять DOM напрямую, и это зависит от идентификаторов, установленных в конструкторе Webflow.

TL; DR: чтобы скрипты взаимодействовали с элементами интерфейса, им потребуются идентификаторы, чтобы ссылаться на них. Они устанавливаются в конструкторе Webflow, и их очень легко случайно сломать, что в свою очередь приведет к поломке вашего приложения.

Чтобы взаимодействовать с элементами HTML, которые создает Webflow, вам понадобятся идентификаторы для ссылки.

Webflow позволяет вам устанавливать HTML-идентификаторы для элементов, на которые можно ссылаться с помощью document.getElementById('id') в ваших скриптах.

Вы также можете использовать селекторы имен классов, но в любом случае дизайнер может случайно натолкнуться на них во время работы над сайтом в Webflow. Это нарушит ссылки ваших скриптов на элементы, что, в свою очередь, нарушит работу вашего приложения.

Другой вариант - использовать селекторы атрибутов данных. Webflow позволяет вам установить их, что безопаснее, поскольку вероятность того, что кто-то их случайно удалит, гораздо ниже.

Но он по-прежнему небезопасен - и тот факт, что любой, у кого есть доступ к конструктору Webflow, может случайно и очень легко сломать ваше приложение, вызывает серьезную озабоченность.

1.3. Невозможно правильно протестировать интерфейс

TL; DR: в «правильных» приложениях вы можете протестировать компоненты внешнего интерфейса и убедиться, что они выглядят так, как должны, в разных состояниях (например, загрузка страницы, загрузка страницы завершена). В Webflow этого сделать нельзя.

По мере роста вашего приложения вы, вероятно, захотите автоматизировать рабочие процессы тестирования. Использование Webflow в качестве интерфейсного инструмента делает это очень трудным, поскольку у вас нет доступа к вашим интерфейсным компонентам. Кроме того, вы не можете передавать реквизиты компонентам.

Конечно, можно взломать решение вместе с большим количеством сценариев и безголовым браузером. В какой-то степени это работает, но это не чисто и плохо масштабируется.

1.4. Вы не можете получить данные CMS прямо на интерфейсе пользователя.

TL; DR: ваше приложение будет медленно загружаться, если вы не создадите более сложные решения для синхронизации данных Webflow CMS с каким-либо местом, которое имеет больше функций.

Фильтрация и запрос данных - это требование большинства веб-приложений.

Итак, давайте представим ситуацию, когда у вас есть 200 сотрудников в коллекции Webflow CMS. На странице вашего веб-сайта вы хотите отобразить этих участников и разрешить пользователю веб-сайта выполнять поиск или фильтровать по категории, чтобы отображать соответствующих сотрудников.

В настоящее время Webflow позволяет размещать коллекцию CMS на странице и фильтровать ее содержимое только в представлении дизайнера или редактора CMS. Когда страница веб-сайта загружается, ваш пользователь не может выполнять фильтрацию. Они застряли в зависимости от того, какие параметры фильтрации вы установили перед публикацией сайта.

Итак, если вы хотите, чтобы ваши пользователи могли фильтровать или искать прямо на странице, вам нужно изменить код.

Для этого вы можете загрузить все 200 элементов CMS на страницу, а затем использовать настраиваемые CSS и JS для создания собственных функций фильтрации и поиска.

Но что, если у каждого элемента есть изображение - вы хотите загрузить 200 из них сразу? Конечно, вы можете настроить отложенную загрузку и другие обходные пути, но все быстро начинает запутываться.

Другой вариант - загружать данные CMS в режиме реального времени, когда ваш пользователь выполняет фильтрацию или поисковые запросы.

Проблема здесь в том, что вы не можете сделать это прямо из внешнего интерфейса. Вам нужно будет создать свой собственный серверный интерфейс, к которому ваш внешний интерфейс будет обращаться с запросами, который, в свою очередь, подключается к API CMS Webflow для получения данных перед их возвратом во внешний интерфейс.

Этот подход медленный, и у Webflow CMS API есть свои проблемы (которые будут рассмотрены в следующем разделе).

Динамическая фильтрация или запрос данных на сайте Webflow затруднены, если эти данные находятся в CMS Webflow.

По моему опыту, единственный жизнеспособный вариант - хранить данные сайта где-нибудь еще, например, в лучшей CMS (например, Contentful) или в более быстрой базе данных, к которой интерфейсная часть может подключаться напрямую (например, Firebase Firestore).

Однако это создает другой набор проблем, поскольку часто клиенты специально хотят использовать CMS Webflow, что означает, что вам необходимо настроить репликацию между CMS Webflow и другой базой данных, что само по себе усложняет работу.

2. Как Webflow CMS формирует базу данных для веб-приложения?

TL; DR: Плохо.

Как упоминалось выше, ваш интерфейс не может напрямую запрашивать CMS Webflow. Это означает, что вам нужно создать свой собственный сервер, чтобы обрабатывать взаимодействие с CMS API (а значит, больше времени и затрат), что само по себе имеет несколько проблем.

2.1 API CMS Webflow оставляет желать лучшего

TL; DR: при взаимодействии с данными CMS через API Webflow CMS вы, вероятно, столкнетесь с некоторыми неприятными ограничениями.

Webflow запустил свой CMS API в 2016 году, и с тех пор, похоже, не очень любил его. В их единственной официальной клиентской библиотеке есть несколько открытых проблем, на которые почти нет ответа от Webflow.

Я пришел к выводу, что опыт разработчиков не является предметом внимания Webflow, и это понятно, учитывая, что дизайнеры являются их основной аудиторией.

Тем не менее, в интересах объективной отчетности, вот самые большие проблемы, которые я обнаружил;

  • Нет поддержки для запроса данных CMS по строке.
  • Нет поддержки для запроса данных CMS по атрибуту или полю.
  • API возвращает максимум 100 элементов, и вам нужно написать свою собственную логику разбиения на страницы.
  • Ограничение скорости API относительно низкое, что означает, что вам нужно создавать механизмы отката и повтора на очень раннем этапе.
  • Вы можете управлять только данными элементов CMS, вы не можете изменять сами поля элементов CMS или изменять коллекции.
  • Библиотека JavaScript Webflow по-прежнему не поддерживает операции PATCH.
  • Задержка выше, чем у других решений (я вижу 15 мс для Contentful, 42 мс для Firebase Firestore и 240 мс для Webflow!)

3. Есть ли решение, которое позволяет дизайнерам использовать Webflow, но при этом имеет смысл для разработчиков?

Я думаю, что есть - и это тот случай, когда инструменты позволяют делать то, в чем они хороши. По прямому назначению Webflow он непревзойден. Это имеет смысл как инструмент для создания статического маркетингового веб-сайта.

Но хотя использование Webflow в качестве интерфейсной среды для веб-приложения возможно, существует так много недостатков, что (почти во всех случаях) его нельзя рекомендовать.

У ваших разработчиков будет разочаровывающий опыт, и ваше приложение просто не будет масштабироваться. Если вы создаете «настоящее» приложение, используйте «настоящий» интерфейсный фреймворк.

Решение, которое может порадовать как энтузиаста Webflow, так и разработчика, - это объединить «настоящее» приложение с Webflow.

Нет причин, по которым вы не можете использовать Webflow для создания маркетинговой части своего веб-сайта, а затем отображать свое приложение непосредственно на странице Webflow.

Такой подход означает, что незначительные изменения веб-сайта не должны проходить через дорогостоящие команды разработчиков, но ваше приложение может быть создано с использованием надежных фреймворков и процессов.

4. Так есть ли смысл использовать Webflow в качестве инструмента для создания веб-приложений?

Несмотря на вышеупомянутые проблемы, в некоторых ограниченных и конкретных ситуациях я думаю, что это имеет смысл;

  • Чтобы предоставить возможность обучения JavaScript / jQuery, не тратя слишком много времени непосредственно на HTML или CSS.
  • Чтобы создать прототип приложения с некоторыми реальными функциями, не неся затрат на полную разработку проекта.
  • Чтобы создать приложение с очень ограниченной функциональностью и которое вы не собираетесь масштабировать (подумайте о внутреннем бизнес-приложении).

Во всем остальном я так не думаю.