Sugestion and best way to Design API with multiple environments like UAT and Production

Not applicable

Hi

In my company we'll use Apigee and I'm in charge to understand and design the proxies, products and etc. I already read a lot of thing and docs, even did some tutorial but i could not get up the best solution for my company case.

Our current scenario without Apigee, we have 2 API endpoints, one for UAT and one for PRODUCTION (without APIGEE).

I was thinking in create 2 organization inside Apigee to distincts UAT and PROD.

This way every SPEC, Proxy API, Product and etc would be segregated without interfering each order. I guess this would be easier to give maintenance.

The cons about this approach is everything would be doubled, if tomorrow we create another environment we would need to have another Organization in Apigee.

But we would have a better granularidade of each developer of each App.

I saw another approach which we can change the target point based in some condition for each environment e etc but, this way the traffic, quota e etc would be all together for each Developer of each App and this doesn't like much easy to give maintenance to me.

Am i wrong?

What do you think guys?

If somebody has doc, link or another resource to share, i would appreciate.

0 1 408
1 REPLY 1

Hi @Rafael Obara,

you can fit this requirement using environments like by-default in free cloud version you can see test and dev environment. In same way when you go for licence version of APIGEE you can ask for multiple environment based on your requirement in same organization. lets say final environment would be uat and production and both can point to respective Back-end API's.

Additionally you can use Environment related features like TargetServer for configurable back-end api URL's based on environment.

APIGEE Best Practices

https://docs.apigee.com/api-platform/fundamentals/best-practices-api-proxy-design-and-development

Hope this will help you, Feel free to revert me back if you need more details specific to your requirement

Thanks,

Sartaj Singh Sisodiya