Decoupling Discourse views from backend


(Itamar Syn Hershko) #1

So we were looking at implementing a backend for discourse using a technology other than Ruby (and we are aware of the various discussions made on the topic in the past).

We were pretty sure Discourse relies heavily on REST APIs and as such this change would be relatively easy - basically just ship the statics somehow to the client and then have them talk with our non-Ruby API clone.

However we could have not been more wrong. Discourse seems to be completely view-based and not rely on REST at all.

Are there plans to detach the client bits from the server bits in such a way that would allow implementing more backends? to us, Discourse is more of a client-side and UI magic.

Thanks for all your hard work


(Mittineague) #2

Whew boy, that sounds like a task. :sweat:

I guess Discourse is open source, so theoretically any backend that serves JSON to Ember might be comparable.

But I’m thinking by the time everything was converted to, say, Python or whatever it might be easier to just start from scratch.


(Itamar Syn Hershko) #3

This is the thing, Discourse is compiling Ruby views and not rendering JSON using Ember. See discourse/show.html.erb at master · discourse/discourse · GitHub for example


(Kane York) #4

That’s the no-JS view. It’s simple HTML view logic, could be done in any language, as long as it’s on the server.


(Régis Hanol) #5

Only when you’re asking for html. Try asking it json and see what’s coming out of the backend :wink:


(Robin Ward) #6

You are drastically underestimating the amount of work this would take. Consider that our test suite has thousands of tests for the Ruby side of the application. You’ve got to re-create all that logic yourself. It took us years to get to this point.

Having said that, as was pointed out, views from the server side are very simple and (with a couple of exceptions) mainly used to bootstrap the application. The vast majority of the app is indeed a REST API.