Consuming REST services: client or server

Question

I am working on a new project in which we are currently deciding which technologies and frameworks we will be using. The application will eventually be cross platform. Therefore, for the server side, we will be using a REST api written in Java Spring.

We are now deciding on which technology we will be using for the front end web application.

The options are as following:

1. Using a front end javascript framework (we'd probably use ember js). Pages would be rendered purely in javascript, all REST requests would be sent from within Ember

2. Using a PHP server framework (Laravel). All REST calls would be made from within Laravel. Server side page rendering

My question: which approach is the best one? And why? If we would go for option 2 (using laravel to make the requests), wouldn't it be overkill to use Laravel as we would only be using it to generate views and make the calls to the REST api's? (all logic comes from the REST API) What bothers me in option 1 is that the rendering will be done client side, which will impact the initial loading time. The application will be widely used, also by users with low-end hardware.

Any input is welcome!If you have other suggestions or better options, please let me know!

Answer 1

As is often the case, it depends

With a pure JS framework

• you push a lot of processing to the clients. That means your webserver for the client application will only be serving static files that can be cached.
• your clients have to be able to handle that processing and need some amount of computing power
• your clients need to fully support all JS-features that your front-end framework uses and you are somewhat tied to the support that framework offers for older browsers. If your framework's newest version decides to drop support for some older IE version that your clients still rely on, you will be stuck with that.
• your REST API's endpoints needs to be accessible by all the clients which might be an issue

Having an intermediate layer means

• you put the processing power in your single server, which is something you can control and, if need be, add more resources to. For clients this is more difficult and sometimes impossible
• you have the ability to control the calls to the REST API and, for example, cache data so you don't need to hit the API every time
• you have more control over security as the endpoints for the REST API do not need to be public
• you have more fine-grained control over the rendered HTML and are not tied to the components provided by your framework. You could create a component that initially uses JS to build part of a view and when performance becomes an issue replace that by HTML generated from the server
• you need to run and maintain a server with some server-side programming language capability

The question is: which of these issues matter to you and which don't. If you have a requirement to support lower-end hardware I'd stay away from JS front-end frameworks. It's very hard to control performance that way and you are very limited in the optimisations you can perform.

Answer 2

I want to add a point to JDT from another perspective.

Theoretically, We have one server but many clients. So, If we put the business logic in server side then we do not have to redo it for every client. Because this is the actual point of an API. We use our API for web, Android, iOS and so on.

However, if some functionality vary from client to client then put it on the client side.