The Survey API Server

In order to focus the logic of building a resilient server-side rendered web application using Nuxt features, we have created a Node.js server to provide an API for authentication, storing, and retrieving surveys.

The Nuxt project will interact with the Node.js server via the API endpoints it provides. However, the interaction between the Nuxt web application and the Node.js server will be a server-to-server interaction instead of a client-to-server interaction. This server-to-server interaction implies that all communication (requests) to the Node.js stand-alone server will have to go through the Nuxt server.

The benefits of using a server-to-server interaction include:

• Security: Unlike code on the server, client-side code is visible to everyone. Therefore, interacting directly with a third-party API might be a security risk because of the exposure of private credentials, such as SECRET_KEYS that authenticates the application request with the API provider. It is usually recommended to have third-party API interactions on the server.

• Validation: Performing API interactions on the server-side enables better data checks and validation. Server-side code can perform thorough validation checks on the data received from the client before making requests to the third-party API. This could help save cost in some cases where the provider charges by the requests made to the API endpoint.

• Caching: In cases where multiple clients are requesting the same data, server-side code can be configured to cache certain responses. This, in turn, leads to a reduction in traffic to the third-party API and possibly saves some costs in cases where the provider charges by the requests. Caching the request on the server would also lead to a decrease in the response time on the client.

• Cross-origin resource sharing (CORS): Modern browsers enforce the same-origin policy which prevents web applications from making requests outside their current domain. Some of the solutions to this problem require access to the configuration of the third-party API. Most of the time, this would not be possible. In such situations, routing the request through a server on the same domain as the web application would be a feasible solution.