Frontman is an open-source API gateway written in Go that allows you to manage your microservices and expose them as a single API endpoint. It acts as a reverse proxy and handles requests from clients, routing them to the appropriate backend service.
With modern scalable organisations, it is highly desirable, yet frequently difficult, to have solid support canary support or blue/green management at the application gateway/APIM. But additionally, the ability to support multiple long term versions of an api backend.
I propose the ability to support hosting multiple versions of a given backend.
Example: todo-app
userA creates a new release, v1 and makes this available via frontman.
They then want to release another version, which in their release cycle is v2. This in theory, should be possible to easily deploy, yet group with the existing backend. Providing some level of cognitive relationship.
I also think it would be nice to hold support for deprecating api's, rather than simply leaving to the user. Naturally i think these should be optional abilities, and not a forced workflow, but it is something crucially missing.
deploy /v1/todo-app/
new version
deploy /v2/todo-app/
new version
deploy /v3/todo-app/
deprecate /v1/todo-app/
This could intertwine with the gateway policy of % split also..perhaps something like latest or similar... perhaps this crosses paths slightly with #50 ?
maybe there's multiple options.. its not uncommon to access different versions via headers Accept-version: 1.0 or even the slightly more complex version
not sure.. just spitballing ideas at this stage to provide conversation to groom something together. Naturally, frontman's winning metric is simplicity, but thinking simplicity can also be in the form of hard to reach features, in a simple to use manner.
With modern scalable organisations, it is highly desirable, yet frequently difficult, to have solid support canary support or blue/green management at the application gateway/APIM. But additionally, the ability to support multiple long term versions of an api backend.
I propose the ability to support hosting multiple versions of a given backend.
Example: todo-app
userA creates a new release,
v1and makes this available via frontman.They then want to release another version, which in their release cycle is v2. This in theory, should be possible to easily deploy, yet group with the existing backend. Providing some level of cognitive relationship.
I also think it would be nice to hold support for deprecating api's, rather than simply leaving to the user. Naturally i think these should be optional abilities, and not a forced workflow, but it is something crucially missing.
/v1/todo-app//v2/todo-app//v3/todo-app//v1/todo-app/This could intertwine with the gateway policy of % split also..perhaps something like
latestor similar... perhaps this crosses paths slightly with #50 ?maybe there's multiple options.. its not uncommon to access different versions via headers
Accept-version: 1.0or even the slightly more complex versionthe above perhaps could marry with #22
not sure.. just spitballing ideas at this stage to provide conversation to groom something together. Naturally, frontman's winning metric is simplicity, but thinking simplicity can also be in the form of hard to reach features, in a simple to use manner.