I see the APIs are quite extensive but before I dive into this direction, I wanted to know if it is possible to build a custom flutter app entirely using the APIs that discourse supports?
We are currently on xenforo and would be migrating to discourse first and then start working on the custom app user experience.
Anything else to we wary of?
Are you intending to use a web view?
If not:
Hi Robert,
Nope not planning on using the web view. That would defeat the purpose of a custom user experience.
Duplication of work is a given and acceptable.
What do you mean by incompatibility with the theme component and plugin ecosystem? Do you mean that plugins will not expose the APIs so therefore cannot be used on the custom mobile app. Theme component is specific to the front end framework so understandably ember components cannot be used on flutter.
I read that thread before posting this here. That thread went down the PWA vs native debate and the original poster never returned.
My query is not specifically about flutter anyway even though I have mentioned it in the title.
The query actually is, since there is an extensive list of APIs exposed, is it possible to create a fully functional custom front end using those. Or are there some gaps which would not allow us to do so.
The front end elements of these (Theme Components are 100% front end) are written in EmberJS and use the JavaScript API of Discourse
You will almost certainly cut yourself off from all those customisations.
No, but pretty useless without the front end changes.
See my post:
(The Topic is linked above)
Basically great fun for a project I’m sure but totally doesn’t make any economic nor much technical sense.
If you want to deploy on app stores there is a much better option
Yes, it’s totally possible, as discourse is just an ember app on top of the rails api.
I think it’s a terrible idea, as you’ll just be duplicating thousands of hours of work. That said, I had a client who did just that and they seemed happy with it. I haven’t heard from them in a long while; I don’t know why.
The good thing about the approach is that at any point you could just decide to switch to the discourse front end. Edit: Or, perhaps, use discourse after the migration and then never get your app good enough to warrant moving to it, or allow users to choose which front end they prefer.
Thanks Jay, your answer really is what I was looking for. In fact I could use the discourse front end for my power users and build a minimalist mobile app for attracting the casual users who would want to engage without getting overwhelmed. You know the ones who like using reddit and facebook.
Oh man I have come back to discourse after years and the evolution here is beyond amazing. Very excited.
My community has 75K members and 2.5 million posts so it would take some work to get migrated. That is my first goal as of now.
We do have some themes to play around with which may be less of a timesink than “build a Discourse frontend in flutter from scratch”
You may install these themes to your site and users can select them for themselves.
I’d like to be proven wrong with an actual example of an independent frontend. I’d also like to be corrected if anything I state here is not accurate! 
Just in my understanding there’s actually a misjudgement whenever this topic comes up, in the sense of: Discourse has an API and an independent frontend layer, so why not just try a different frontend there?
The misjudgement I see is that
Thank you, thats probably something I would have discovered as I would have dug deeper. Its a shame then if all the statistics are being triggered and computed in the front end instead of say using queues in the backend. Nowhere near headless then.
Thanks Natalie, I did look at the themes earlier and would say that FKB Pro is closer to what we would want.
See this concept UI for the mobile app.
Hmmmm … I’m not sure we can say that?
Likes are counted in the backend, Post & Topic counts are backend …
I think read time is based on front end code, but that’s not surprising …
Yes, I’ll change to “read tracking”… But it’s still my point: many advanced features are based on read tracking.
Looks just like a Theme to me.
Don’t waste your money on a fully native app.
Would agree with that. Some components that could already do the heavy lifting for this:
Yes going by the helpful responses here we will first attempt to go as far as we can with the theme itself. First priority is to migrate with all the customization that we have in place which includes a bustling marketplace and a trade rating system.
Ok another query. Can users subscribe to categories to see only threads from those categories in their feeds? That’s one thing I had in mind with the APIs.
Is there a way to surface recommended content in feed based on scoring and relevancy to a user?
I’d break that out into another Topic if I were you.
Note that on Discourse, thread = Topic
There was a feature request for this:
