1

We have an application that fetches user data from an Azure tenant via MS Graph. We need to distinguish between guests and regular members.

Guests come back with Usernames that look like this:

johndoe_agreatdomain.org#EXT#@mydomain.onmicrosoft.com

In our web application that actually displays this information, we need to transform that username to be a little more user friendly. So we change it to look like:

johndoe@mydomain.onmicrosoft.com

The question is where / who is responsible for this transformation. I'm trying to come up with a list of questions / factors that should be considered before making the call. And more than just an answer to this specific question, I'm looking for the broad principles / strokes that will apply in general.

The overall process would look like this:

a) pull data from MS Graph. This happens as a cron job on a daily basis. But we use their delta api so it's just a handful of records each time the job runs. The first time is the only time we will pull across the wire all 300,000 records.

b) save to local db (with / without a user friendly version of the username in the table)

c) expose methods in an API allows for reports about Guests (aka many records going across the wire at a time)

d) expose methods that allow look ups on specific users.

So far these are the questions I've been mulling over:

  • how many records are we talking about? 300,000.
  • how often are these reports run? If it's really often then instead of transforming each time, it's smarter to save in the database.
  • how expensive is the transformation? Doesn't seem to be expensive at all. We just strip out everything between "_" and "@"

I'm tempted to say the database should be client agnostic and just save the data as we get it from graph. And .. we shouldn't "care" about front end display requirements. But the counter argument is that if this is the way the front end will "search" for users and talk to the back end about users, this isn't just a front end problem.

How do we calculate how expensive these transformation are? What would be a good approach?

Last comment.
If we did it dynamically i would likely add a view model in the application layer for this specific domain context. Or I was also thinking about implementing a specific response object in the API layer that does the transformation just before passing it along. If we did it in the database, I would just add another column to the table to be the user-friendly version of username.

Any comments would be appreciated.

dot
  • 531
  • 4
  • 12
  • 1
    Possibly related/useful: [What is an Anti-Corruption layer, and how is it used?](https://softwareengineering.stackexchange.com/questions/184464/what-is-an-anti-corruption-layer-and-how-is-it-used) (Seems to be along similar lines to your idea of putting the translation into the code which handles the API). I don't see any serious issues around putting it into the database however. – Ben Cottrell May 12 '23 at 21:32
  • If you are simply removing _...@ then why not do it on the view layer? the front end will still know the full (real) username for communication? – Ewan May 14 '23 at 17:24
  • wont the guest be confused if you change their username? how will they log in? – Ewan May 14 '23 at 17:24
  • why dont you validate the username when they enter it and say, "no you cant make a username like that" – Ewan May 14 '23 at 17:25
  • @Ewan we don't create it that way. It's a microsoft Azure thing. – dot May 15 '23 at 14:27

1 Answers1

1

I don't think this is a formatting question but a domain question.

Your database needs to hold and model data appropriate to your business domain (disregarding the staging of sources).

It's hard to tell without knowing your business but my initial instinct is to parse out the username to be a first class data item and store it. Again, this is not about formatting, more about creating a complete and usable data model.

Your APIs reflect your domain model not your raw data.

LoztInSpace
  • 1,149
  • 6
  • 8