auth token handling in preparation for socketization about parabol

[jordanh]

I'm super-glad I pulled down your latest changes and stepped through the new Cashay-enabled/cached authentication. I think I actually have an informed opinion to share :)

I think it's safe to consider authentication as domain state, as the token is just data originated from a different backend.

I vote for (#1) Cashay (persist automatically using redux-persist)

Pros:

• Not wiring up another redundant datapath (i.e. fetch)
• As much state as possible in redux
• AuthEngine likely going to be owned by Cashay transport, right? Then keeping data close to Cashay just makes sense

Cons:

• Will have to consider carefully how token updates will be handled if we use refreshToken

Alternatively, I could see (#4) Fetch + put in redux (persist automatically using redux-persist) being a good option. Imagine:

• No matter where the token comes from (i.e. the Lock component or from our server performing refreshToken) we dispatch an action that updates the token in the client's redux store
• Reducers listen for this action and respond (hell, you could even extend Cashay's reducer to listen for this action to update all Transport tokens...)
• Serialization/persistence becomes a design choice for the implementor

Only thing is with #4, I think it'd still make sense for us to use our /graphql endpoint (outside of Cashay) just so we don't have to (gulp) add a new REST endpoint. We could do this cleanly be writing our own duck that thunks.

I'm fine with either!

[mattkrick]

really good input! Currently, 1 is closest to how we have it set up right now, but when i started writing local-only mutations solely for the AuthEngine, I started to question myself. It's a great option for us. 4 is an interesting one because we actually get the authToken from auth0, so we're already forced to used their REST backend. If we stick with auth0, we could directly call an action on an authToken reducer, so it'd feel more generic. But, if we get it from our GraphQL server, then no matter how you slice it, we'll either have to use cashay or we'll have 2 locations for the same token.

tl;dr:
4 for a simple auth0-specific pattern
1 for a more complicated, highly flexible, pattern

[jordanh]

Yeah, either 1 or 4. Be interesting to see what you end up going with!

[mattkrick]

4 is definitely cleaner for our immediate use. are you thinking about staying with auth0 for the life of the project?

[jordanh]

For now, there aren't any immediate plans to switch away. It depends on business needs.

[mattkrick]

hmm, then i say let's go for 4. Friendlier codebase, easier to understand.

[jordanh]

This will be closed by #82, correct?

[mattkrick]

yep, i think that's a good stopping point for the welcome-ui branch, will keep the Meeting schema & socketization separate.

[jordanh]

👍

[jordanh]

Merged to master in #82 .