I am working on an API that has a User resource to represent the current user and a User service that handles business logic for representations of this user.
I need to introduce an Organization resource that has Members, which are effectively Users within an organization.
I need to build a resource that is represented as /:organizationId/members that pulls a collection of Users that belong to an organization.
In my database, a user belongs to an organization if their id is in a row with the matching organization id in a join table. I can very easily query this and get all of the information I need.
However, I do not want my organization service to be querying any tables that have to deal with user data as I anticipate I will inevitably need to add a new column to the user data. I’d like all management of user data to occur within the User service.
One solution I had was to return a set of ids for users belonging to that organization, and then send that to the User service to get the user data, but then I lose the ability to effectively sort by name and limit the length of the query since that is handled by the SQL.
Is there a best practice for handling this type of problem?
2
In this case probably the best approach is to create a “membership” service. Organization, Users, and Membership.
Membership would have a GET to return all the members for an organization. This would return an array of member DTOs. Other operations may include Add/Remove membership (POST/DELETE). Also, if the joiner table had some properties perhaps an update (PATCH) membership. Other potential GETs would be show all organizations for a user in addition to get members for organization mentioned earlier.
By returning a different dto, you don’t have to return all the user or organization data, just a small proxy object. If you need the full org or user, just call those service gets to return those object(s) if needed.