Making single page apps more responsive while maintaining RESTfulness

Question

For a single-page app to be RESTful it needs access to API endpoints from which to retrieve its content. This mean's that you'll have, say, a API/user_information endpoint, and a API/article/ endpoint, and an API/comments endpoint and so on. For large applications these ajax calls will slow down rendering, especially over slow (mobile) connections. Ironically, this is not as much of a problem in the old-world of doing everything server-side, since the entire html is delivered in bulk upon the first request. Thus, sigle-page apps, which are supposed to be faster and more responsive than old-school server-rendered apps, may end up being considerably slower (admittedly, only if they require a large enough number of API calls).

The options, as far as I can see, seem to be: 1) Forget single-page apps, go back to doing everything server-side. 2) Consolidate all the API endpoints into fewer (possibly one) endpoint(s) so all content is retrieved with minimum latency. But now you're not longer RESTful.

These are both unsatisfying and sad. Is there a better solution?

PS: caching content in local storage seems to cause more problems than it solves because now you have to worry about invalidating client-side caches every time you push out fresh content.

Answer 1

I'm working now in a similar architecture as you commented, and I agree with you in your thoughts. What we are doing is to try to find a compromise between the both options you described, even if sometimes we are not always 100% RESTful.

I think it not always necessary to be 100% RESTful if your needs require it. Using the DTO pattern you can define the DTOs in a way that optimizes the performance of your application minimizing the number of calls, offering still reusability.