Developers May 23, 2020

Why is adding teams to your app later considered so difficult?

Ben P @mostlyError

"If you build teams into your app from the get go, you'll save yourself a lot of trouble" ... or something to that effect. Can anyone with some experience in that particular fire shed some light on why a lot of developers seem to feel this way?

  1. 2

    Any good resources for the less IT inclined? I am currently struggling with how to design a new MVP on AWS Amplify/Appsync/DynamoDB with 1. super user/admin privileges to handle all service requests across all client/customer accounts, 2. isolated client/customer access to review work and set up their own tasks to send to my company, 3. client' staff access to do the same. It's multi-tenant but with my need to be able to work across AWS privileges. For numerous reasons, this is the best framework for me so please don't say switch to django or rails or other.
    Hope I am being clear.

  2. 1

    Without thinking about teams up front, it's common to create a datamodel where database records are owned by your User entities. Then, once you add teams or groups or whatever it gets super difficult to divorce those User entities from direct ownership. In some cases, that's simply because you don't know which resources should move to which teams. The more common and, in my opinion, more painful problem is now you have two entities, Users and Teams, that can own your resources and instead of creating an abstraction for that distinction, you end up with conditionals everywhere doing one thing for Teams and another thing for Users.

  3. 1

    I would say it depends on the unique architecture of the app — some will just have an extra layer of grouping on top and call it a day, for some others it will require some more work 😁

  4. 1

    A good developer should be able to design the system to support teams in the future without needing a full rewrite of the code or time consuming migration. The important thing is that the initial system is designed to be extensible in order to support what you may want later on.

    One example where this was not done was in an app I worked on for a client. All the data was tied to individual users and organized as such (think database table keys, backend files organized under user directories, etc.). The client later wanted teams of users to own and share the data. This would have required migrating the database data/file data and rewriting the application logic that interacted with the data. There's other challenges too like access control and collaborative workflows that you need to worry about when teams are introduced.

Recommended Posts