Please give me some suggestions for secondary development.

[zhanchen18]

I plan to perform secondary development, but I am unsure how to start. The content I may involve includes:

1. Adding object properties, such as extra information between users, for example, User A's remarks about User B, which need to be stored on the server so that they can be retrieved from the server when switching devices;
2. Calculating mutual friends between User A and User B and other additional APIs.

I have already read through this document（https://turms-im.github.io/docs/server/development/redevelopment.html#about-secondary-development）

Maybe i need edit code in turms\turms-service？

Please let me know if there are any specific guidelines or suggestions to help me get started with these changes.

[JamesChenX]

This is a good question, and I will write a doc on how developers can use custom properties on entities (i.e. MongoDB collections used by Turms) this weekend.

The question involves many existing and new features:

1. Adding object properties

Currently, Turms has already supported allowing developers and users to specify and retrieve custom public (visible for all users) properties/attributes (e.g. im.turms.server.common.domain.user.po.User#userDefinedAttributes) on User and Group without the need to modify any source code. For details, please wait for the new doc that will be published this weekend.

2. for example, User A's remarks about User B

If you want the feature Personal/Private Notes, I can add the feature recently if you need and you don't have to fork Turms to just add this small feature.

This feature should be easy to implement and has logic similar to im.turms.service.domain.user.po.UserRelationship#name.

3. Calculating mutual friends between User A and User B.

This is also a common feature, and should be easy to implement based on im.turms.service.domain.user.po.UserRelationship, but need to take some effort on designing related admin/client APIs and server properties.

If you are not in a hurry, you can wait for me to implement the feature in December.

---

I am busy with developing turms-chat-demo (a complete client application that users can use out of the box) and trying to publish a prototype in November, which means I have very limited effort on these new features.
So you can either try to implement them by yourselves and submit a PR so that we can push them more quickly, or wait for me to become available in December.

[zhanchen18]

Thank you very much for your detailed response. However, I have a series of features to develop and can’t completely wait for you to implement them. My main concern is about a section in "Collection Schema Design":

Take the "query groups joined by a user" feature as an example. The GroupMember collection in Turms is used to manage the relationship between groups and users. This collection is designed to shard data based on group IDs by default. Therefore, if you need to find group-related data according to group IDs in a distributed database server, it is very easy for the database (targeted queries). However, conversely, if you need to find the groups that a certain user has joined based on their user ID without creating a new auxiliary collection, it becomes extremely inefficient (scatter gather queries). Because the database cannot locate the relevant group data based on the user ID, it will send the query request to all database servers, causing a large number of invalid and redundant requests, with only a small proportion of valid requests, ultimately resulting in a lower effective throughput of the database cluster than a single database.
I am concerned that my implementation may lead to the problem mentioned in this passage.
For example,
I also need to implement a feature to find common groups between user A and user B；
invite multiple users to a group simultaneously (currently, GroupInvitationService/createGroupInvitation can only invite one user at a time, and the client temporarily implements multiple invitations by using a for loop to send repeated requests).
There may be 30+ similar requirements