This uses a very simple, easy-to-use (but non-optimized) implementation where we keep
distinct properties per each use-case (i.e. regular, beta, or "new feature").
Adding many more of those (UserData, UserDataExtended etc) will make it messy.
For cleanliness and peace-of-mind, the number of these variants should anyway stay
as low as possible, though we do demonstrate that we can support both innovation AND
stability at the same time.
Set the user's data based on response from RandomUser.
This is the new underlying service that we are driving beta users to.
NOTE: This implementation is currently only for developers of this new feature!
The "fake user".
This uses a very simple, easy-to-use (but non-optimized) implementation where we keep distinct properties per each use-case (i.e. regular, beta, or "new feature").
Adding many more of those (
UserData,UserDataExtendedetc) will make it messy. For cleanliness and peace-of-mind, the number of these variants should anyway stay as low as possible, though we do demonstrate that we can support both innovation AND stability at the same time.