3 ms·

As someone who has worked as part of a team on an Angular 9.x frontend with Spring Boot Java backend mediating between many other backend API based services...

As someone who has worked as part of a team on an Angular 9.x frontend with Spring Boot Java backend mediating between many other backend API based services... well, it's a huge mess, a resource hog in terms of disk, RAM and CPU, and far slower than it could be. Development is slow and cumbersome and the browser uses 48MBytes+ on the page for what is ultimately a slightly complicated CRUD app. Thr JSON APIs are secured by tokens and other mechanisms, so you can never query them directly without the Angular app. We have 800MB or more in node_modules with Node taking 100s of MB and the Java backend uses over 1GB of RAM in dev mode just to start up. It's an internal application available over the VPN. Even with high speed internet some API calls take 2 seconds to return and populate parts of the form in edit mode. A single unified backend server pumping out html would likely be both faster and easier to manage.

tunesmith 5y ago
Not sure how this is related to HATEOAS, but having one api backend to front several private services is a pretty common pattern. But as a data point, I can tell you that with us using a react frontend to talk to a nodejs graphql backend that also fronts private services, our nodejs graphql backend is usually below 300mb of ram. At any rate, it sounds like your spring boot app combined with your network topology is the constraint, good luck chipping away at it.
kragen 5y ago
Perhaps you posted this comment on the wrong thread, because it doesn't seem to pertain to the article at all.
- shrubble 5y ago
  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.
Cthulhu_ 5y ago
> A single unified backend server pumping out html would likely be both faster and easier to manage. That's probably an oversimplification, because where would this unified backend server get its data from? How much code and services would need to be rewritten and re-engineered to make this work? I mean, you know this tech better than I do, but don't make the mistake of thinking to just build something on top or alongside an existing problem, because it just paints over said problem instead of fixing it. I mean, anecdote time. I once worked at a big company. Some clever engineers (including me? but I had no say on the architecture) decided to build a microservice architecture on top of an infrastructure-as-code setup on AWS with a Demand for 99.99999% uptime from the top brass. However, the real processing in the end was done by some Java application built by people who weren't very good at software engineering (think: the answer to a stack overflow question "how to connect to a database in Java", copy / pasted five levels deep in an if / else tree). And that was just an abstraction layer on top of fuck knows what, all I ever heard was that it's a mainframe, something cobbled together from decades of takeovers and mergers of other companies in the same industry. It was layers on top of layers to try and make things manageable and fast, but in effect it made things less manageable and more complex and didn't solve the root cause, because nobody dared.
piaste 5y ago
> Thr JSON APIs are secured by tokens and other mechanisms, so you can never query them directly without the Angular app. What, you can't acquire auth tokens via API?

tunesmith 5y ago

Not sure how this is related to HATEOAS, but having one api backend to front several private services is a pretty common pattern. But as a data point, I can tell you that with us using a react frontend to talk to a nodejs graphql backend that also fronts private services, our nodejs graphql backend is usually below 300mb of ram. At any rate, it sounds like your spring boot app combined with your network topology is the constraint, good luck chipping away at it.

kragen 5y ago

Perhaps you posted this comment on the wrong thread, because it doesn't seem to pertain to the article at all.

shrubble 5y ago
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.

Cthulhu_ 5y ago

> A single unified backend server pumping out html would likely be both faster and easier to manage. That's probably an oversimplification, because where would this unified backend server get its data from? How much code and services would need to be rewritten and re-engineered to make this work? I mean, you know this tech better than I do, but don't make the mistake of thinking to just build something on top or alongside an existing problem, because it just paints over said problem instead of fixing it. I mean, anecdote time. I once worked at a big company. Some clever engineers (including me? but I had no say on the architecture) decided to build a microservice architecture on top of an infrastructure-as-code setup on AWS with a Demand for 99.99999% uptime from the top brass. However, the real processing in the end was done by some Java application built by people who weren't very good at software engineering (think: the answer to a stack overflow question "how to connect to a database in Java", copy / pasted five levels deep in an if / else tree). And that was just an abstraction layer on top of fuck knows what, all I ever heard was that it's a mainframe, something cobbled together from decades of takeovers and mergers of other companies in the same industry. It was layers on top of layers to try and make things manageable and fast, but in effect it made things less manageable and more complex and didn't solve the root cause, because nobody dared.

piaste 5y ago

> Thr JSON APIs are secured by tokens and other mechanisms, so you can never query them directly without the Angular app. What, you can't acquire auth tokens via API?