Share models between several monoliths

Question

I want to build an app that will have have several monoliths. My question (similar to this one) is, how do I centralize User model between these apps, i.e. how to deal with user management/authorization/authentication without duplicating code. For some context, I'm using code driven development with Django.

This is what I came up with:

===========       =======================       ===============
== App 1 == <---> = Shared API with DRF = <---> ==== App 2 ====
===========       =======================       ===============
= barcode =       = * Users             =       = web app for =
= scanner =       = * Roles             =       = shopping    =
= android =       = * Privilages        =       ===============
===========       = * User data         =
                  =======================
                             ^
===============              |
==== App 3 ==== <-------------
===============
= web app for =
= retailers   =
= to upload   =
= goods       =
===============

Is this good architecture when several applications need to share same users? Is there an alternative? For example, how would one extend this model to accept users that login, for example, using oAuth with Google account or similar? Is it possible to do this without using microservice architecture? Also, is it better to use GraphQL (to share User data as an Object) or REST for the API?

Answer 1

The real challenge here is how not to duplicate logic.

You need a single source of truth for what a user is, and what they can do. I've worked on systems before that accomplished this with a separate web app and web API, called something like the "Admin web app" or "user admin web app".

The other applications used a class library separate from the User Admin web application that only contained the logic to call the User Admin application and enforce permissions. This gives you a basic breakdown of "service provider" versus "consumer".

This architecture gives you the following components:

• User Admin web API (service provider for Computers, also called upon by User Admin web app)
• User class library (integrates Consumer and Service Provider web API)
• Web app 1 (consumer, uses User class library to enforce permissions)
• Web app 2 (consumer, uses User class library to enforce permissions)
• Web app 3 (consumer, uses User class library to enforce permissions)
• User Admin web app (service provider for Humans, probably also uses User class library to enforce permissions)

You'll have some code duplication between the Service Provider and User class library components, but it will be minimal. The main separation is read-only (consumers, User class library) versus read-write (User Admin web API, which should be called by User Admin web app).