9072cb5c99 | ||
---|---|---|
.github | ||
.mvn/wrapper | ||
.vscode | ||
deploy/docker | ||
start-client | ||
start-site | ||
start-site-verification | ||
.dockerignore | ||
.editorconfig | ||
.gitignore | ||
Dockerfile | ||
LICENSE.txt | ||
README.md | ||
USING.adoc | ||
mvnw | ||
mvnw.cmd | ||
pom.xml | ||
using-web-ui.png |
README.md
Steeltoe InitializrWeb
Steeltoe Initializr UI reference implementation
About
This implementation largely steals from the Spring Initializr Client. The primary differences between the 2 implementations are branding and domain metadata. Branding differences include reference URLs, color schemes, and logos. Domain metadata include metadata differences such as "Java version" vs ".NET Framework" and "Spring Boot" vs "Steeltoe."
Deploying
There are 2 endpoints that the Web UI uses to 1) populate its UI, and 2) generate projects:
/api/config/projectMetadata
/api/project
For local development, these endpoints are implemented in the development webpack configuration in start-client/webpack.dev.js.
In a remote deployment, those endpoints are implemented by the Initializr API. The deployment should be frontended by an HTTP router that forwards requests to these 2 endpoints to the API server. A sample Kubernetes ingress configuration:
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: initializr-ingress
namespace: initializr
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: my.initializr
http:
paths:
- path: /(.*)
backend:
serviceName: initializr-web
servicePort: 80
- path: /(api/.*)
backend:
serviceName: initializr-api
servicePort: 80