Closed alexlovelltroy closed 8 months ago
While experimenting with Krakend-CE, I discovered the yawning chasm of a limitation in the CE version, which is that Krakend cannot route arbitrary nesting levels to a backend (see https://www.krakend.io/docs/endpoints/#endpoints-with-multiple-nesting-levels). You have to upgrade to the Enterprise version, which allows wildcard expansion of nesting levels, or if you want to stick with CE, you must manually write out every single endpoint at every level of nesting in the Krakend config file.
Given that we want to keep the API surface area small for SI, I don't see this as a problem, but one of many things that may push us to alternatives in the future and/or to obtain a license for this software if we want to use it that way.
Closing this issue based on the addition of Krakend-CE in https://github.com/OpenCHAMI/deployment-recipes/commit/7f1455d323f7c45a09bd53114a65e900af4d11a3
In CSM, microservices operate within a mesh that can route and mangle HTTP Requests. Ochami doesn't have a unifying API Gateway when deployed outside of Kubernetes.
The set of APIs that the Supercomputer Institute students will need to understand across the microservices aren't particularly user friendly. We have an opportunity to use an API Gateway like Krakend-CE to improve the user experience without changing the underlying microservices. It also gives us a convenient choke point at which to apply security policies and protect the individual microservices from malformed and unsuitable requests.
Some experiments in this direction can be found at https://github.com/OpenCHAMI/lanl-demo-sc23/tree/alt-kraken-test