This tool generates proxy code using the following inputs:
(1) an OpenAPI specification,
(2) a proxy template, and
(3) an input JSON message containing values for template variable substitution and other metadata such as the proxy name
From what I understand, youâre basically taking an OpenAPI spec and auto-generating proxy code using templates + JSON variables, especially for Apigee setups. That kind of automation can really save time, especially when teams are dealing with multiple APIs.
I faced something similar when I was working on API standardizationâmanual proxy setup was slowing everything down and small mistakes kept slipping in.
What worked for me was:
keeping templates super modular
validating OpenAPI spec strictly before generation
adding a fallback logging layer for debugging generated proxies
Not sure if it helps, but automation like this only becomes powerful when structure is consistent.
Are you planning to support multiple gateway formats or just Apigee for now?
Nathan,
Yes you got that, an OpenAPI spec and auto-generating proxy code using templates + JSON message with values to replace template variables.
This is the library being used for variable substitution https://handlebarsjs.com/.
When building template proxy, there are some commands from this library which are used as you can see in the examples.
The code does validate the OpenAPI spec , Code Snippet [SwaggerParser.validate(specfile);].
The common set of requirements for proxy code, the non-functional bits, security, validation, logging, routing, error handling, cors and so on
all can be shared flows, and added to the template. The examples included were very basic, a template with a error handling shared flow.
This was to your point about modularizing the code, and benefits therein.
Every time you notice a pattern in the APIProxy code, create a template. Almost 80-90 percent of all the APIProxy code is repetitive, or so we notice .
This is now , maybe when there are more orchestration/mashup type apis this may change, but this is what it is now on most of the projects Iâve worked.
About supporting this for other gateways (IBM APIConnect, Azure APIM) , this could work is my initial reaction, need to put more thought into it.
Also, all this is hosted in my personal GitHub repo, need some direction about moving this to a more community based repo and getting this published on npm.
Comparing to other tools
Did a quick compare of the tools available for Apigee Proxy generation. All of them are great , and have pluses & minuses.
Please note, all of this is just my opinion. I had to split this post as it doesnât allow for more than two links in a post
Go Gen
Supports other specs OpenAPI, GraphQL, AysncAPI and gRPC
Converts APIProxy/SharedFlow templates to yaml â developers are more used to the xml structure, some getting used to
Passes values to assign to template variable as key/value string
Need to learn the templating language , building template file slightly more complicated
To use policies developers need to update the openapi spec with vendor extension âx-google-apigee-policy:â
Policies must be supported by the tool , if a new built-in policy is made available ,the tool(openapi2apigee) code must be updated to support this new policy
Not sure how it support shared flows
Dino the master
Uses javascript for building out a template
Generate proxy from template and config file â doesnât use an OpenApi spec , this makes building the config file more work,
for example , needs to include all the operation paths in the config file whereas in the other tools these paths are provided in the OpenAPI spec