Joining table with table from external database/API

Question

For a prototype project I've created an Angular 2 application with simple CRUD functionality using Auth0 to handle authentication with a back-end containing a Web API (core), Service and Repository project.

I've chosen to use an Auth0 database to store all the user information (and not an internal custom table) because I didn't see a reason not to and I want to avoid unnecessary complexity.

At this point I need to show all the users in a HTML-table combined with information from my custom database, for example: some users are linked to a project, all users should be shown but only the linked-to-project users should have a button next to the name. For this I use the Auth0 Management API to retrieve all the users. Where would be the best place to join the user and project tables that both exist in different databases (users are only reachable using the external Auth0 Management API.

1. Repository: Retrieve all users from the Management API and all projects using SQL, then combine lists.
2. Web API: Retrieve all users from the Management API and all projects from the ProjectService, then combine lists.
3. Clientside: Retrieve all users from the Management API using Angular 2 and all projects from the ProjectController (internal API), then combine lists using javascript.
4. Come to an conclusion that I should merge the Auth0 database to my custom one.

Extra remark: If for example using the Repository to join tables would be the best solution, what should happen when users should be shown on a different page without the need for extra information. I assume that now it is best to call the Management API straight from the client resulting in a situation where the Management API calls are spread through whole the application.

Answer 1

I would exclude option 3. mostly because it seems easier to maintain the concept of a single API to the client application; the fact that your Web API endpoint for users further calls into the Auth0 Management API is an implementation detail.

Hiding this from the client applications also makes it easier to change in the future, although, I'm not a big fan of programming for what it might happen in the future. Nonetheless in this occasion hiding the Auth0 management API from the client application seems to make most sense even if that part of the system is unlikely to change.

I would also resist going with option 4. (even despite Auth0 supporting fully custom databases) because not having to manage user credentials and being able to delegate all the management of user passwords/accounts to Auth0 is a godsend. Additionally, this also nicely decouples the parts that of your system that are focused on boilerplate identity management versus the business focused parts.

I would go with any option (the simplest for me to implement) that would allow me to do the merging on the server-side and surface a normalized view of the users and projects to the client application in one go.

This allows for you to keep your options open, for example, you could later decide to sync user information (non-credentials stuff) from Auth0 to your database for performance reasons when obtaining users listings while still fully leveraging the Auth0 integrated database for central identity management.