API가 꽤 방대하다는 것을 알겠습니다. 하지만 이 방향으로 본격적으로 착수하기 전에, Discourse가 지원하는 API만으로 커스텀 Flutter 앱을 완전히 구축할 수 있는지 확인하고 싶었습니다.
현재 Xenforo를 사용 중이며, 먼저 Discourse로 이관한 후 커스텀 앱 사용자 경험을 개발할 계획입니다.
그 외 주의해야 할 점이 있을까요?
웹 뷰를 사용할 계획이신가요?
아니면:
- 프론트엔드 작업의 상당한 중복 발생 가능
- 유지보수 작업의 지속적인 중복 포함
- 테마 컴포넌트 및 플러그인 생태계와의 호환성 부족으로 해당 생태계를 활용할 수 없음.
로버트, 안녕.
웹뷰를 사용할 계획은 없어. 그렇게 하면 커스텀 사용자 경험의 본래 목적이 무의미해지거든.
작업의 중복은 당연하고 받아들일 수 있어.
테마 컴포넌트 및 플러그인 생태계와의 호환성 문제가 뭔지 구체적으로 설명해 줄 수 있어? 플러그인이 API를 노출하지 않아서 커스텀 모바일 앱에서 사용할 수 없다는 뜻이야? 테마 컴포넌트는 프론트엔드 프레임워크에 특화되어 있으니, 엠퍼 컴포넌트를 플러터에서 사용할 수 없다는 건 충분히 이해가 돼.
여기에 게시하기 전에 해당 스레드를 읽었습니다. 그 스레드는 PWA와 네이티브 앱에 대한 논쟁으로 흘러갔고, 원 게시자는 돌아오지 않았습니다.
제 질문은 제목에서 언급했듯이 Flutter에 대해 구체적으로 묻는 것이 아닙니다.
실제로 묻고 싶은 것은, 광범위한 API 목록이 공개되어 있으므로 이를 사용하여 완전히 기능적인 커스텀 프론트엔드를 만들 수 있는지가 아닙니다. 아니면 그렇게 할 수 없게 만드는 어떤 결함이 있는 것인가요?
이들의 프론트엔드 요소(테마 컴포넌트는 100% 프론트엔드입니다)는 EmberJS로 작성되어 있으며 Discourse의 JavaScript API를 사용합니다.
이로 인해 거의 확실히 이러한 모든 커스터마이징에서 소외될 것입니다.
아니요, 하지만 프론트엔드 변경 사항이 없으면 거의 쓸모가 없습니다.
제 게시글을 참고해 주세요:
(주제는 위에 링크되어 있습니다)
기본적으로 프로젝트로서는 분명 재미있겠지만, 경제적으로도, 기술적으로도 큰 의미가 없습니다.
앱 스토어에 배포하려는 경우 훨씬 더 나은 옵션이 있습니다.
네, 완전히 가능합니다. discourse는 rails api 위에 구축된 ember 앱이니까요.
솔직히 나쁜 아이디어라고 생각합니다. 수천 시간의 작업을 단순히 중복하게 될 테니까요. 하지만 그렇게 한 클라이언트가 있었는데, 그들은 꽤 만족해했습니다. 오랫동안 연락이 없었기 때문에 그 이유는 모르겠습니다.
이 접근법의 좋은 점은 언제든 discourse 프론트엔드로 전환하기로 결정할 수 있다는 것입니다. 수정: 또는, 이주 후에 discourse를 사용하다가, 결국 앱을 discourse로 옮길 만큼 충분히 좋게 만들지 못하거나, 사용자가 선호하는 프론트엔드를 선택할 수 있도록 하는 것도 방법입니다.
제이, 답변 정말 감사합니다. 제가 찾고 있던 바로 그 내용이었어요. 사실, 파워유저들을 위해 디스코스의 프론트엔드를 사용하고, 과부하를 느끼지 않고 가볍게 참여하고 싶은 캐주얼 유저들을 끌어모으기 위해 미니멀한 모바일 앱을 만들 수 있겠다는 생각이 들었습니다. 바로 리디트나 페이스북을 좋아하는 그런 분들 말이에요.
오, 몇 년 만에 디스코스에 다시 돌아왔는데, 여기의 발전이 정말 놀라울 정도입니다. 기대가 큽니다.
제 커뮤니티에는 75,000명의 멤버와 250만 개의 게시물이 있어서 이관하는 데 꽤 많은 노력이 필요할 것 같습니다. 그게 제가 당면한 첫 번째 목표입니다.
"플러터로 디스커스 프론트엔드를 처음부터 직접 만들자"는 것보다 시간 낭비가 덜 될 수 있는 몇 가지 테마가 있습니다.
이러한 테마를 사이트에 설치하면 사용자가 직접 선택하여 사용할 수 있습니다.
독립된 프론트엔드의 실제 사례를 들어 제 주장을 반박해 주셨으면 합니다. 여기서 제가 언급한 내용이 부정확한 부분이 있다면 지적해 주셔도 좋습니다! 
제 생각에는 이 주제가 나올 때마다 실제로 오해가 있는 것 같습니다. 즉, Discourse에는 API와 독립적인 프론트엔드 레이어가 있으므로 왜 다른 프론트엔드를 시도하지 않느냐는 식의 오해입니다.
제가 보는 오해는 다음과 같습니다.
- 규모 면에서 실제 인터페이스 요소와 뷰의 수가 제대로 평가되지 않습니다. 토픽 목록과 토픽 뷰만 있는 것이 아니라, 처음에는 부차적으로 보일 수 있지만 결국 디자인해야 할 훨씬 많은 요소들이 있습니다. 사용자 페이지만 보더라도 모든 다른 뷰를 재현하거나 대체 구조를 마련해야 합니다.
- 개념적으로, Discourse의 프론트엔드는 단순히 프레젠테이션만을 담당하는 것이 아니라 매우 기능적인 레이어입니다. 모든 읽음 추적(Read tracking)은 Ember에 기반하며, 이를 없애면 Discourse의 많은 정교한 기능이 작동하지 않게 됩니다. 프론트엔드에서 사용자 추적을 재현하고 백엔드와 정교하게 연결하지 않으면, 신뢰 수준(Trust levels), 배지(Badges), 알림(Nudges), 읽음 상태(Read states) 등을 포기해야 하며, 결과적으로 사용자들이 읽기, 게시, 좋아요만 할 수 있는 매우 기본적인 앱이 됩니다. Discourse 위에서 그런 간단한 앱을 만드는 것보다, 더 단순한 기반 위에서 그 앱을 만드는 것이 훨씬 쉬울 것입니다.
감사합니다. 더 깊이 파고들었다면 제가 직접 발견했을 가능성이 높은 문제인 것 같습니다. 그런데 모든 통계가 백엔드에서 큐를 활용하는 대신 프론트엔드에서 트리거되고 계산된다면 정말 아쉬운 일이네요. 그렇게 되면 헤드리스(Headless) 아키텍처와는 거리가 멀어지니까요.
음… 그렇게 말할 수 있을지 확신할 수 없네요.
좋아요 수는 백엔드에서 집계되고, 게시글 및 주제(토픽) 수도 백엔드에서 처리되거든요…
읽기 시간은 프론트엔드 코드에 기반한다고 생각하지만, 그건 놀라운 일이 아니죠…
네, "읽기 추적"으로 변경하겠습니다. 하지만 여전히 제 주장은 유효합니다: 많은 고급 기능이 읽기 추적에 기반하고 있습니다.
내 생각에는 그냥 테마 같아.
완전히 네이티브인 앱에 돈을 낭비하지 마.
동의합니다. 이 작업을 위해 이미 상당한 역할을 할 수 있는 몇 가지 컴포넌트가 있습니다:
- 목록 뷰를 조정하려면 Topic Cards, Topic List Thumbnails 또는 Topic List Previews Theme Component
- 푸터 내비게이션을 위해 F NAV - Mobile Navigation Tabs
네, 여기 있는 도움 되는 답변들을 참고해서, 먼저 테마 자체를 최대한 활용할 수 있는 방향으로 진행해 보겠습니다. 최우선 순위는 현재 설정해 둔 모든 커스텀 설정을 유지하면서 이사를 가는 것이며, 여기에는 번화한 마켓플레이스와 거래 평점 시스템이 포함됩니다.
네, 다른 질문 하나 더 하겠습니다. 사용자가 카테고리를 구독하여 피드에서 해당 카테고리의 스레드만 볼 수 있나요? API를 구상할 때 염두에 뒀던 것 중 하나입니다.
사용자의 점수 및 관련성에 따라 피드에 추천 콘텐츠를 노출하는 방법이 있나요?
나라면 그 내용을 별도의 Topic으로 분리할 거야.
참고로 Discourse에서는 thread = Topic이야.
이 기능에 대한 요청이 있었어: