Architecting multiple codebases calling our public API + private API for first-party applications

Question

Currently, we have the issue where we have two codebases (API & Website) calling the same database (along with some duplicate business logic) and we want to streamline this so all requests are routed via our API. We have a public REST API, and we have a website. Some functionality of the website is achievable through the public API, but some will need to come from a private API that only our secure backend can access.

Our website will be re-created as an embedded web app that can be put anywhere and calls our public API's (think a lightweight react/vue project). However, for the official web app running under our domain we will need extra special privileges, such as doing specific admin-related tasks that only we should be able to do (thus requiring a private API). This has led me to create the architecture below:

This architecture achieves the following:

• Single source of truth (our API) that talks to the database.
• Only the Web App under our domain has any concept of the private API, and even if the code was inspected requests would be opaque as they are just be routed to a secure backend.
• Allows us to roll out future first-party projects that can use the same secure backend.

Is this a good approach? Are there some big pitfalls I'm missing? Also I plan on making the Official Web App & the Secure Backend two separate code bases as ideally we would like to swap out the official web app (frontend) with some other arbitrary first-class project and expect it to operate in a similar fashion. It should also be noted the private API will be part of the same codebase as the public API, just with private endpoints exposed so it can access a lot of the business rules it needs to.

Thanks. (Also please excuse my incorrect use of GCP icons).

Answer 1

A Game of Questions

Gotta love Architecture, it is fractal.

From what I can piece together your "Official" Web App is actually two pieces.

1. A Web Page (which executes within the user's browser)
2. A Public API (which your web-app uses to do stuff)

Additionally you have a Published Public API used by the wild west which isn't used by your Web App.

And at least some of the functionality is similar enough between the two that it might be reasonable to reuse it.

Private API
     |
     V
Secure Server-----------------------> Published API
     |                                       |
     V                                       V
Server Side Web APP API                Third Parties
     |
     V
Client Side Web App

A pretty diagram, a mess of an implementation.

---

First I would cut out the nonsense about your "official" web app.

Any code that is run on not your computer is code not under your control, it is no more trustable than those third-party web apps. Particularly given that any suitably motivated party doesn't even need your official web app in order to dispatch http requests to your server. Even a stream based http/2 communication is not immune (though it does require more sophistication).

Now you could claim that a webserver generating static/dynamic web-pages from a local API isn't exposing an API. Except it is, the API is just more obtuse as the API is the web page itself. Send the right request, and get the response back in html as opposed to json/xml. Security through Obscurity isn't secure.

What this boils down to is that both the Public and Official API's are both Public. The difference is whether or not you Publish it with associated usage information.

That changes the diagram again.

Private API
     |
     V
Secure Server-------------------+
     |                          |
     V                          V 
Web App/Page Server        Public API
     |    ^                     ^
     |    |                     |
     |    +---------------------+-------+
     V    V                             V
Client Side Web App             Third Party Clients

But this is conflating concerns. The secure server is where the API/WebServer live, while everything else is about the service. Either we need to drop that out of this perspective, or actually include the other important physical locations.

Dropping it out

 Private API
     |
     V
 Public API-----------------------+----------------------------+
     |                            |                            |
     V                            V                            V
Web App/Page Server------>Client Side Web App          Third Party Clients

Adding it in

===Backend Servers================|==========Licensed Services=======
                                  |
                                  |
        Internal API's            |       Third-Party Serivce API's
             ^                    |                   ^
             |                    |                   |
=============|===========Secure Bastion Server========|=============
             |             *Probably in DMZ           |
             |                                        |
             +---------------------------------+      |
                                               |      |
                                               V      V
        Web App/Page Server                   Public API
             |       ^                            ^
             |       |                            |
             |       +----------------------------+
             |       |                            |
=============|=======|=======Client Machine=======|==================
             |       |                            |
             V       V                            V
         Client Side Web App              Third Party Clients

This would suggest having a single set of of encompassing API's. Even if that api is subdivided into separate micro-services, or a single monolithic service. Both can be made to work.

It also suggests that basing access on client would be foolish. However an account based authentication mechanism would give your users the power of choice. The ability to use your own web-app, or the ability to use a third-parties. That account provides them with access to ascribed services at their ascribed levels of service (should the client support it).

If you still wish to provide client specific functionality, consider a client certificate which is used to authenticate the client app itself and unlock client app specific functionality. This could be used to monetise those third-party offerings, should they desire some of the features available to the official app, they can pay for those to be enabled to them (regardless of the specific user).

You could even go further and extract your own web-app from the secure server, and distribute it through third-party channels. eg: geo-caching services.