Я вижу, что API довольно обширные, но прежде чем я углублюсь в это направление, хотел бы узнать, возможно ли создать собственное приложение на Flutter исключительно с использованием API, поддерживаемых Discourse?
В настоящее время мы используем XenForo и планируем сначала перейти на Discourse, а затем начать работу над пользовательским опытом кастомного приложения.
Есть ли ещё что-то, о чём стоит знать?
Планируете ли вы использовать веб-представление?
Если нет:
Привет, Роберт,
Нет, мы не планируем использовать веб-вью. Это противоречило бы цели создания индивидуального пользовательского опыта.
Дублирование работы неизбежно и приемлемо.
Что вы имеете в виду под несовместимостью с компонентной темой и экосистемой плагинов? Вы имеете в виду, что плагины не будут предоставлять API, и поэтому их нельзя будет использовать в кастомном мобильном приложении? Компоненты тем специфичны для фронтенд-фреймворка, поэтому, понятно, что компоненты Ember нельзя использовать во Flutter.
Я читал эту ветку перед тем, как написать здесь. Обсуждение ушло в спор о PWA против нативных приложений, и автор оригинального сообщения так и не вернулся.
Мой вопрос не касается конкретно Flutter, хотя я упомянул его в заголовке.
Суть вопроса в следующем: учитывая обширный список доступных API, возможно ли создать полностью функциональный пользовательский интерфейс с их помощью? Или существуют какие-то пробелы, которые не позволят этого сделать?
Элементы фронтенда этих компонентов (компоненты тем на 100% относятся к фронтенду) написаны на EmberJS и используют JavaScript API платформы Discourse.
Вы практически наверняка лишитесь всех этих возможностей кастомизации.
Нет, но без изменений на стороне фронтенда это будет практически бесполезно.
Смотрите мой пост:
(Тема указана выше)
В целом, это, конечно, увлекательный проект, но с экономической и даже технической точки зрения он совершенно не имеет смысла.
Если вы хотите разместить приложение в магазинах, есть гораздо более подходящий вариант.
Да, это вполне возможно, так как Discourse — это просто приложение Ember поверх Rails API.
Я считаю, что это ужасная идея, ведь вы просто дублируете тысячи часов работы. Тем не менее, у меня был клиент, который поступил именно так, и он, похоже, остался доволен. Я давно не получал от него вестей; не знаю, почему.
Плюс такого подхода в том, что в любой момент вы можете просто решить переключиться на фронтенд Discourse. Редакция: Или, возможно, использовать Discourse после миграции, а затем так и не довести своё приложение до состояния, когда переход на него станет оправданным, или позволить пользователям выбирать предпочитаемый ими фронтенд.
Спасибо, Джей, твой ответ — именно то, что я искал. На самом деле я мог бы использовать фронтенд Discourse для своих продвинутых пользователей и создать минималистичное мобильное приложение для привлечения случайных пользователей, которые хотят участвовать, но не хотят быть перегруженными. Ты знаешь тех, кто любит использовать Reddit и Facebook.
О боже, я вернулся в Discourse спустя годы, и эволюция здесь просто невероятная. Очень рад.
В моём сообществе 75 тысяч участников и 2,5 миллиона сообщений, так что для миграции потребуется определённая работа. Это моя первая текущая цель.
У нас есть несколько тем, с которыми можно поэкспериментировать, и они могут занять меньше времени, чем «создание фронтенда Discourse на Flutter с нуля».
Вы можете установить эти темы на свой сайт, и пользователи смогут выбрать их для себя.
Я был бы рад, если бы меня опровергли на реальном примере независимого фронтенда. Также прошу поправить меня, если я допускаю неточности в том, что здесь говорю! 
Просто на мой взгляд, при обсуждении этой темы часто возникает заблуждение следующего рода: у Discourse есть API и независимый слой фронтенда, так почему бы не попробовать использовать там другой фронтенд?
То заблуждение, которое я вижу, заключается в следующем:
Спасибо, это, вероятно, то, что я бы обнаружил, если бы копнул глубже. Жаль, если вся статистика запускается и вычисляется на фронтенде, а не, скажем, через очереди на бэкенде. Тогда до headless-архитектуры ещё далеко.
Хм… Не уверен, что так можно сказать?
Лайки подсчитываются на бэкенде, количество постов и тем тоже на бэкенде…
Думаю, время чтения определяется фронтенд-кодом, но это неудивительно…
Да, я изменю на «отслеживание чтения»… Но это всё ещё моя точка зрения: многие расширенные функции основаны на отслеживании чтения.
Мне это кажется просто темой.
Не тратьте деньги на полностью нативное приложение.
Согласен. Есть несколько компонентов, которые уже могут взять на себя основную работу:
Да, судя по полезным ответам здесь, мы сначала попробуем продвинуться как можно дальше, используя саму тему. Приоритет номер один — миграция со всеми нашими текущими настройками, включая оживлённый рынок и систему рейтингов торговых операций.
Хорошо, ещё один вопрос. Могут ли пользователи подписываться на категории, чтобы видеть в своих лентах только обсуждения из этих категорий? Это одна из идей, которую я имел в виду, работая с API.
Есть ли способ показывать рекомендуемый контент в ленте на основе оценки и релевантности для пользователя?
Я бы выделил это в отдельную тему, если бы был на вашем месте.
Обратите внимание, что в Discourse «поток» (thread) = «тема» (Topic).
Существовал запрос на эту функцию:
