2.2 KiB
Path-based Routing
If you are using the frontend, the frontend and backend need to share cookies. The backend, in particular, sets a cookie, and the frontend needs to read it. As such, you cannot run the frontend and backend on different subdomains, like this:
- frontend.example.com
- backend.example.com
Instead, we often run them like this:
- example.com for the frontend
- api.example.com for the backend
This works since the backend can set a cookie for the entire domain, and the frontend can read it.
Another alternative that works well is to run them on the same host but with different paths, like this:
- spiff.example.com for the frontend
- spiff.example.com/api for the backend
To accomplish this path-based routing scenario, set environment variables like this in the frontend:
SPIFFWORKFLOW_FRONTEND_RUNTIME_CONFIG_APP_ROUTING_STRATEGY=path_based
And in the backend, you may need to set:
SPIFFWORKFLOW_BACKEND_URL_FOR_FRONTEND=https://spiff.example.com
SPIFFWORKFLOW_BACKEND_URL=https://spiff.example.com/api
# if you happen to be using the internal openid server. do not do this in production.
SPIFFWORKFLOW_BACKEND_OPEN_ID_SERVER_URL=https://spiff.example.com/api/openid
# if you can manage, use in-cluster DNS for connector. you may need a different host or port.
SPIFFWORKFLOW_BACKEND_CONNECTOR_PROXY_URL=http://spiffworkflow-connector:8004
The backend does not support paths like /api/v1.0/status
, but instead wants /v1.0/status
.
As such, a proxy in the frontend or backend will need to remove the /api
part of the path before handing the request to the backend.
If you are hitting the backend at a URL like spiff.example.com/api and not rewriting the path to remove the /api prefix, you can inform the backend about this situation by setting this environment variable:
SPIFFWORKFLOW_BACKEND_WSGI_PATH_PREFIX=/api
This will be used as the WSGI SCRIPT_NAME
, which essentially removes the prefix before handing the URL to the app for routing, but also allows URLs generated by the app to return things like /api/v1.0/status.
WSGI is a standard for serving Python apps, and there are implementations like Gunicorn, Green Unicorn, uWSGI, mod_wsgi, CherryPy, etc.