Need help understanding Phoenix Contexts

I’m a bit confused about what context really is after reading the Phoenix Context Guide. From the guide, it seems like Accounts context deals with everything related to users (registration, authentication, etc.). But aren’t those supposed to be its own contexts? So which of the following is the right way to define context?

Option 1

  • Accounts
    • register_user
    • login_user
    • update_user_profile
  • Merchants
    • register_merchant
    • update_merchant_profile

Option 2

  • Accounts
    • register_user
    • register_merchant
  • Authentication
    • login_user
  • Profiles
    • update_user_profile
    • update_merchant_profile

or maybe other options?

3 Likes

You’re right, depending on the structure of your application it might make sense to draw different lines between the contexts. Since it is just a question of how you want to organize your application, it doesn’t really matter as long as the way you split your contexts is reasonable and understandable.

In the example you give, I would also say: It depends.
It depends on what the individual functions do. I. e.: Are Merchants also Users? Does Merchant use a different schema than User? Answering those questions might help you decide which functions belong to the same context and which don’t.

2 Likes

If Merchants are not Users (two different schema), does it still make sense to use option 2? In my mind, an Account is an account on a given app. The account could be of type User or Merchant.

1 Like

Also check out these threads:

:023:

3 Likes

Since there will probably be additional Merchant functions in the future, Option 1 seems quite reasonable.
Since Users are also going to be their own thing, an additional Users context might also be a good idea.
And one more thing: Maybe consider renaming Users to Customers in order to be clearer when it comes to the wording.

1 Like

9 posts were split to a new topic: Off-topic posts about Contexts

it seems to me option 2 makes more sense because it will keep the context small. I am still unclear if we are suppose to keep our contexts from growing out of control with a huge amount of functions being placed in them? Anyone know the answer? @chrismccord

In rails i would abstract methods out of the model into small service objects, but I am still unclear what path we are recommended to take.

@sammkj - There is no “right” or “wrong” way to build your application. It ultimately comes down to whatever makes the most sense to you for your specific use case. You’re already on the right track by considering your application structure beforehand, a benefit of Phoenix’s contexts.

As to your question regarding the two options, the second option does look better. The contexts are simply a formality that encourage name-spacing and allow you to write decoupled code. By starting to develop with contexts in mind you’re setting yourself up for easier refactoring in the future. So, if you should choose option 1 or 2 today and in the future change your mind, you’ll be able to restructure the application without much hassle.

2 Likes

Nice talk