- I have figured out appwrite
- To create a two-way relationship, you mention the ID.
- If you wanna create an item AND the item yr trying to relate to it, then don’t mention the ID, instead, send over the object itself that is needed to create a document.
- For e.g: createdByUser: “123” vs createdByUser: UserModel(name: “Rami”)
- But when you’re fetching a document that has a relationship, you will receive the data itself, rather than the ID
- This complicates the process of having the same types for fetching and sending data. But it can be resolved by parsing the JSON and only sending the ID rather than sending the whole thing when creating that relationship.
- The maximum levels Appwrite can go in terms of relationships is three
- When Appwrite fetches the details of a document that has a two-way relationship with another document, that subdocument will not contain the data for the parent document because that would cause an infinite loop. So, Appwrite handles it by not adding that data.
- Users → MeetupRequest (User not added to the document) → MeetupApproval (User and MeetupRequest not added to the document)
- Refactor the backend so that we are updating the data while we are onboarding(if a relationship exists)
- I might just use the same table rather than having two different tables.
- send backend different Data
- Go backend needs to expect different data and return different data
- expect different data from the backend