4

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.

Sam
  • 171
  • 1
  • 5
  • 1
    _"Retrieve users by making a call to the Management API and join them using SQL with the project table."_ Does SQL allow joining a TABLE with something that is not a table (or view)? How do you join a table with data from an API call? – Tulains Córdova Dec 05 '16 at 14:56
  • I think this question can be improved for clarity. – Tulains Córdova Dec 05 '16 at 14:58
  • Any advice on improving it? All suggestions are appreciated. I edited the first possible solution (Repository) because of your first comment, I didn't think that one through. – Sam Dec 05 '16 at 16:01

1 Answers1

3

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.

João Angelo
  • 311
  • 1
  • 7
  • 1
    3 is bad, 4 is worse (seriously, Auth0 is wonderful). Keeping everything on the server side is a much better experience and encapsulates the fact that you're using an API call to Auth0, which at the answer suggests, might change to being a cached representation in the future. – mgw854 Dec 05 '16 at 16:20
  • Thanks both for the well explained answer/comment. I'm still doubting between option 1 and 2. On first thought option 1 (Repository) will be better if there is need to join internal and Management API tables or that the Management API result needs more complex manipulation and option 2 (Web API) will be beter if the Management API results are mostly used straightaway without the need of manipulating (ex: show all users). I guess this will be different for all projects. – Sam Dec 06 '16 at 08:11
  • 1
    That choice is more difficult to get it right when looking from the outside without knowing all the little details of a specific project; In the end you should go with the one you feel most comfortable and is less complex. Since it's on the server-side, even if you get it wrong at first it's easier to refactor. – João Angelo Dec 06 '16 at 08:39