3 ms·

We have state in two places and have to talk to 3 servers (frontend Angular/Node, java middleware and databases behind that) to serve a page, with JS running co

We have state in two places and have to talk to 3 servers (frontend Angular/Node, java middleware and databases behind that) to serve a page, with JS running continually on the browser to monitor changes in variables etc.. Isn't the idea that you have a server that serves static or nearly static html to the browser? And maintains the state on the server itself. We can't easily do what the LISP guys call memoization, which would be a huge win for performance by keeping properly cached values on the server, for example.

kragen 5y ago
> Isn't the idea that you have a server that serves static or nearly static html to the browser? And maintains the state on the server itself. Which idea? The idea of REST? Stateless servers are one of the core elements of REST https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...: > We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. > This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures [133]. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests. > Like most architectural choices, the stateless constraint reflects a design trade-off. The disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, placing the application state on the client-side reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.

kragen 5y ago

> Isn't the idea that you have a server that serves static or nearly static html to the browser? And maintains the state on the server itself. Which idea? The idea of REST? Stateless servers are one of the core elements of REST https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...: > We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. > This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures [133]. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests. > Like most architectural choices, the stateless constraint reflects a design trade-off. The disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, placing the application state on the client-side reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.