I'm currently evaluating using the API Developer Portal in our organization and I was curious as to why the hardware requirements are so high? We would primarily be using the Developer Portal for generating documentation of the available services that we have published on the CA API Gateway. Additionally, if we were to follow the recommendation of a 3 node architecture would each node be considered a compute node and need to have those hardware resources available?
Outside of using the API Developer portal are their any other options for generating swagger like documentation for the services published on the Gateway? This seems like an expensive appliance to operate and maintain if all we need is documentation for our services published on the Gateway.
I agree that the requirements for Portal are quite high particularly when it sounds like your main use-case is more documentation-related rather than using the Portal for API access management, analytical data and reporting, etc. I can definitely understand your concern on that front.
So with that said, I have forwarded this on to some of our Portal team members to see if we can offer up a more detailed response that will answer all of your questions.
I'll try to follow-up on this tomorrow. Feel free to reach out to me directly if you haven't heard anything from anyone at CA by Wednesday.
Thank you for your question.
Let me try to answer some of your question from experience.
The 4.x portal uses quite a bit of resources because it is built around a number of docker containers. This makes it very scalable and flexible, but also means it requires much more resources for a small setup.
We typically install all on a single node for the type of use you describe. In my personal opinion, there is no need to have multiple nodes unless it is a very heavily used portal or you require high availability.
If it's only for making the swagger file available, I think you could do that as part of publishing the swagger based service on the gateway. If I remember correctly this is part of the template generated by the swagger wizard. But I don't have an environment available to check this right now. But in that case you would not have the full documentation like the portal would make available.
So I think in your case I would go for a single node deployment of the portal.
Hope that helps.
I could be misunderstanding what you have suggested but I have looked into the publishing of the swagger based services on the gateway. While this is a nice feature I don't know if this accomplishes what we are trying to do. We don't have any issues publishing our backend services on the Gateway.
The challenge we are currently facing is we would like to be able to generate documentation based on the services that we have published on the Gateway. Our internal development teams already have access to the Swagger pages for our backend APIs but we would like to be able to provide documentation for the services that are published on our API Gateway for clients that are not part of our internal development teams and will be making all requests to our backend APIs via the API Gateway. In many cases our clients will not have access to the Swagger pages and we would not want them to have access to them as the routes defined on the swagger page will probably be different than what we have available on the Gateway.
As of right now we don't have an easy way to show clients what services we currently have published on our Gateway without standing up the CA API Developer Portal or manually documenting what services are available on the Gateway which is far from ideal.
I agree that in your case the portal would be the way to go. If you want to give an external overview of the services which are available and the documentation which goes with it, that is exactly what the portal was made for. You will just need to have an edited swagger file for those services with the correct external routes defined in them. This is what the portal will need to generate the documentation pages.
As mentioned before I would probably just run a single server for the portal in your case.
I agree with Michiel - the Portal is the way to go for your use-case by the sounds of it, even if the requirements are considered to be on the high side. I'm fairly certain most of the memory requirement is for the analytics functionality. Not sure of a way around that in a supported manner yet though, unfortunately.