Consider combining the API's of Portal, OpenAPI and perhaps the Admin Service into one OpenAPI service

[kezhenxu94]

Taken from the wiki

Problems:

• The OpenAPI service is integrated into the Apollo Potal, thus it's not HA, (or we may need to deploy multiple Portal web-apps and configure a load balancing server).
• The OpenAPI only covers a small subset API's of the Apollo Portal API, and increasing the coverage brings duplicated code (they require the same functionalities so they share the same code snippet to interact with the Admin Service, right?). related issues to ask for more Open API's: 求答 openapi 接口疑问？ #2069 Apollo REST接口咨询 #1648 openapi 是否考虑支持对app内集群的创建操作 #1759
• Users may want to implement their own Portal, even a mobile app Portal (such as Apollo REST接口咨询 #1648 (comment))
• Authorization and authentication should be done twice, one for the Portal and one for the OpenAPI

I'm thinking whether we can combine the API's of the Portal, OpenAPI and the AdminService into one OpenAPI (because they all require the same thing, manipulating configs), then the Portal UI and the users' third-party clients interact with this OpenAPI, authorization is also done there. I think this may also reduce the complexity of deployment (#1424 )

It's just a bold thought, what do you think @nobodyiam , are there other concenrs? If I've missed anything, please point it out, thanks :)

feel free to close it if it's out of scope :)

[nobodyiam]

This is a bold thought to provide a real open api layer and treat portal as a standalone ui component. With this abstraction, it should be very easy to customize or even provide a fresh new ui.

However, this may involve a lot of refactoring work. Also adding one more component may bring extra effort in deployment and maintenance.

For the 4 problems described above,

1. This might not be a problem since adding a open api service will have the same issue
2. This involves some development work but it is not larger than refactoring the whole portal with a new open api service
3. This makes sense, though I think it may be rare to write a fresh new portal
4. Portal and OpenAPI now already have 2 difference authentication and authorization model