This is a very interesting article!
I was the one who wrote the first Discourse prototype that evolved into the code base it is today, so I have the advantage of remembering why I made most of those early decisions around the API.
At the time (4 years ago!) there simply weren’t any mature libraries to do this kind of thing from Javascript, or if they were they were not even close to my radar.
For performance reasons, the common advice at the time was to minimize requests by returning large object graphs that mapped to your views. One monolithic request was seen as better than several smaller requests. Performance is an advantage we definitely want, but there are obvious disadvantages to this as pointed out in the article.
You’ll notice it results in less specific mappings of resources. A TopicView is a resource we request to render a topic rather than simply a Topic. We do this so that we can include a bunch of extra stuff we know we’ll need to render the topic.
Having said all that, clearly the API approach has scaled well for us so far. Our app is performant and we’ve been able to re-use the REST API in quite a few surprising ways.
I am curious as to how a GraphQL implementation would look, both from a server and client side standpoint. My gut feeling is it would be quite a lot of code and it would not be realistic to replace our current REST APIs any time soon. On the other hand, Discourse has already evolved quite a bit (CoffeeScript -> ES5 -> ES6, Ajax calls -> Promises -> Store, Rails 3 -> 4, etc) and I am always up for slowly updating to new and better ways of doing things when they can be demonstrated.
I eagerly await more articles in the series to see the path it takes. Thanks to @sashko for the excellent write up.