Critique this Umbrella application Structure

I was bored today so I decided to create a little umbrella app generator for my future side projects. Basically it’s a web app with authentication and registration as most apps I build will have this functionality and I’m tired of writing that out every time.

Where I am looking for help is some feedback on how I have seperated the application components and if it can be improved.

Basically:

  • Auth: Handles creating user, checking pw
  • Main: Will be where all the apps business logic is (uses auth as dependency)
  • MainWeb: Web interface - also performs guardians jwt session storage

Anyway you can find the full project here: https://github.com/Harrisonl/tempumbrella

Thanks in advance!

2 Likes

There is nothing to say on your app because it was just created and has nothing inside. Except the only one thing - user is not the best model name for credentials(email and password inside). Probably you shouldn’t save any user related attributes like first name or city into “Auth -> credentials” model because they are not related to authentication / authorization at all.
Have fun :035:

1 Like

Looks good, any plans for splitting DB logic from Main apps?

Yeah that’s what I thought as well, but then I was looking at this sample umbrella application and they had it all there as well https://github.com/wojtekmach/acme_bank

Yeah that’s the plan but not really sure if I’ll have a dedicated DB app or have each app use the DB if needed. The only problem there is that they will all need a connection/pool. Like I said above I got the idea from this sample umbrella, but not sure if I will continue to follow it. I reckon I will pull it out into its own application and have all other apps interface to it. Do you have any examples of this?

So did I. But I have changed my mind after I added more types of authentication to my app(FB, Twitter etc) and removed auth stuff to a separate database. Both approaches should work fine until you will try to cut out authentication app from your monolith.
PS: Actually it doesn’t matter what is the name of that model, it can be User. But it’s better not to have user’s attributes there.

hmmm that sorta makes sense. What’s the benefit of moving auth to a different DB? Also what attributes would you have on the user/account in the auth app? Is you project public or a private repo? cheers for all your help though!

Our advice with Phoenix v1.3 will be to not break the applications apart if they depend on the same database. That’s because, if they depend on the same database, they are still coupled to each other via the data store, which is a big dependency. So I would keep them together to avoid a false sense of isolation when things are not actually isolated.

It is tricky to find the proper boundaries between applications. I have seen projects that decided to break apart into multiple umbrellas, without considering the boundaries, and it just ended-up being a scattered monolith.

5 Likes

Here is example about separating DB and connecting it trough services to controllers.

We use two databases to handle different services with one authentication DB.
Email, password, password reset token etc, all oauth related stuff coming from facebook or twitter. Of course they are not all in one row, one row for email, one for flickr etc. But with the same user id or whatever will link them with other app(s).
It’s really a question of coupling, like Jose said. I use Phoenix only for API app without any repo added and of course I can’t use joins just to fetch “current user” but I need to query both databases(or it can be two schemes, I guess, than you can use joins). But actually ets helps and save from tons of pings to database #2 and that works fine for us.

Hi @Harrisonl, looks like I’m a bit late to this thread but I’m considering doing something similar with an umbrella application and I see that you have deleted the GitHub repo. I’d love to know your thoughts and how they have changed over time.

Does it make sense to make Auth a separate application as part of an umbrella application? Or, does it make sense to just have a single Monolith Phoenix application? Or does it make sense to have a separate Auth application that can be used as a dependency (assuming that Auth application is custom built for your project’s needs)?