Consolidating the web services

[esheehan-gsl]

I’ve been thinking about making a change to the application architecture. Instead of having separate UI and API services, I think we might combine those two services into one services that is a more traditional web application.

We’d just need to add some routes to the existing Flask application that rendered some HTML for the UI, and we’d need to copy over some of the JavaScript from the UI service. We’d be able to eliminate some of the JavaScript and some of the build complexity in the UI this way. Instead of having to have Svelte components that generate the page layout, that’s handled by the server. We use our existing web components for the charts, but instead of being managed by Svelte, the server would just write out HTML with the appropriate attributes to produce the charts — that’s some state management we wouldn’t need to handle client-side anymore.

Currently, we don’t support back/forward buttons in the browser (but we need to). To do so in a client-side application like we have now, this means we have to implement routing with the history API or pull in another dependency that does that for us. Letting the Flask app handle HTTP requests for UI would mean the browser’s usual behavior would provide back/forward navigation for us, with only the cost of a full page refresh.

If we see some undesirable performance side effects from the full page refresh, we could likely address some of those by providing some preload links in the head of each HTML document the server generates, and building a service worker to help cache data.

[esheehan-gsl]

I think the changes this would require for our infrastructure are just:

1. Remove the EC2 instance hosting the frontend (yay reducing costs!)
2. Making the Flask application accessible on port 80 at our URL (now that the frontend EC2 instance is gone)

[ian-noaa]

I think I'd be supportive of this. It'd reduce the amount of JS code we'd need to maintain which would be nice and would also make it easier to parse request logs in VLab if we need to. Being able to rely on Flask & the browser to handle back/forward buttons would be quite convenient.

It sounds like preload links and/or service workers would be good ways to increase responsiveness if needed.

On the infrastructure side:

1. We could look into removing the second EC2 instance. We're currently running into some memory limits on the worker nodes so are looking into increasing our instance sizes from t3.small to t3.medium. We're also investigating reserving instances through a compute savings plan for a full year. If we were locked into a CSP for a year we could look into scheduling 2 of the flask apps into the cluster and let our traffic load-balance between the two since the apps seem relatively stateless. Thankfully it's a low-stakes decision as either way we go, (locking in one or two EC2 instances) the costs are pretty low.
2. I believe VLab will need to point their load balancer at the flask application image so we probably wouldn't need to update anything on our application side which would be nice. Our containers currently all serve on port 80.

[esheehan-gsl]

I’m embarking on an experiment in a branch to see how much this actually improves the frontend.

[esheehan-gsl]

@ian-noaa This is looking pretty promising. I need to do some more rigorous benchmarks to see how this is improving performance, but I think this is going to be the way to go.

The big benefit is moving to a server-side rendering for the pages, which allows us to populate the controls for selecting variables and model runs immediately rather than loading some JavaScript, fetching the data, and then presenting the controls. The initial load time of the page feels much speedier now.

A thought occurred to me over the weekend, though. We could either

1. Consolidate the frontend and backend into the Flask app
2. Build a server-side app for the UI using Express (kind of like Flask for Node)

The advantages of option 1:

• Fewer services to manage
• No networking needed between API service and UI

The advantages of option 2:

• With a Node app, we could potentially use something like node-canvas to render PNG fallbacks for all of the charts on the server
• Easier to integrate tools for optimizing JS and CSS, since everything in the client app is Node

The PNG fallback has the potential to get a readable visualization on screen faster than waiting for our JavaScript to load. If the JavaScript fails for some reason, the charts are at least readable, if not filterable. I don’t know for sure that PNG fallbacks will provide visible results faster than the JS, though. This would require a lot more testing.

So if we go with either of these, we’ll need to make some changes to our AWS infrastructure. For option 1, we’ll need to remove the web server container and make sure the Python container is accessible from the internet. For option 2, we’ll need to replace the web server container with a Node container to run Express.

Since this is looking pretty promising, I wanted to know what you think about how hard it’s going to be to make a change like this, if you have a preference between option 1 or 2, and when do you think we’d be able to get this in place if we decide to make the change.

[esheehan-gsl]

I think I’m still leaning towards putting everything in the Flask app. We can deal with optimizing the frontend from Python as the need arises…

[esheehan-gsl]

On the other hand, I think we could replace the Nginx container with a node container and not have to change our infrastructure at all…