Project static : a uw-frame review

steps-took.md

Summary

I took some time during research day to evaluate uw-frame as a maven project. Many times we have said "why is this a maven project, it is just static content". I took that good point, and ran with it. What if frame was just static content.

Steps Taken for Test

• I created https://github.com/timlevett/static-frame which is just uw-frame, without all the maven fluff.
• I then registered this app with bower under tim-uw-static-frame and tagged v1.0.0.
• After that I took uw-frame and created this branch https://github.com/timlevett/uw-frame/tree/tim-static-test which basically removes all the static content, and adds in some copy-resources in the pom.xml so that the static content is pulled in.

What does that do?

• To work on the frame static content you can just run http-server (documented here: https://github.com/timlevett/static-frame/blob/master/README.md). http-server is a node project that just runs a http server with the given directory as root.
• This opens doors to other developers, like WAMS and the like to dev stuff that isn't Java based. They can just pull in the bower component as we did.
• We could start writing node express.js based frame apps (like all the cool kids)

Why not do this?

Complexity increases. In order to make a change happen and see it reflected in angularjs-portal you would need to:

• make change in static-frame, commit and tag static-frame (there may be a way to get snapshots or something, not sure)
• do a mvn install on uw-frame with the new static-frame component
• do a mvn clean package on angularjs-portal

So what do you all think?

👍 👍 👍

But, in my view what's missing is an application manager. I.e., Tomcat is currently responsible for agglomerating all the individual apps together under one my.wisc.edu URL, assigning each a context, and routing requests accordingly. Static apps could be first class citizens, if not for needing to package into wars for deployment via Tomcat

I think a good lightweight solution would include a document store that maps a context, like "/weather", to a URL, like "http://1.2.3.4:5678/weather/1.0.0/", plus any associated metadata & miscellany, and then routes requests appropriately. This would also facilitate blue/green deployments with a single instance.

Apache would be enough for that requirement, but what would be really sexy is an API & UI where someone could submit an app, register a health check URL, proxy service endpoints, schedule cutovers, etc.

Paul, you just described the Discovery component of Spring Cloud, aka the Netflix OSS 'Eureka' service. It does precisely what you just described. While it's a java-centric service, the API is entirely REST based, and can (and is) used by non Java components. Not to divert this thread onto a side road, but if it interests anyone, here's the Eureka REST api: https://github.com/Netflix/eureka/wiki/Eureka-REST-operations.