Things

Proposed Solution

Outline in enough detail for a team member to understand how you'll implement.

Please consider adding:

• context, concerns that need product/design/dev clarification
• examples for specific use cases, edge cases
• FE: logic, states, scenes, VIP, workers, ui, libraries, tools
• BE: logic, states, services, database changes, migrations, libraries, tools
• performance choices
• maintenance choices
• flowcharts, pictures, links 🙂
• what is in scope

Alternatives/Considerations

What other options have been considered? There are tradeoffs to choosing any path. Attempt to identify them here.

Please consider:

• implementation cost, both in term of code size, complexity and time
• the impact on maintenance, code readability
• integration of this feature with other existing and planned features
• cost of migrating existing codebase (is it a breaking change?)
• what is not in scope

The proposed changes are based on requested feature found in https://app.clubhouse.io/rila/story/7979/post-create-2-0

Requirement Outline

This is an outline on the proposed changes that will be made to the system in order to accommodate a new Post Upload flow. The idea is to allow users to Upload multiple photos with individual captions and metadata (known as a ListingMedia Post in the system) at the beginning of the flow. The User will then go on to select if they are contributing to an existing Listing or creating a new Listing in the system.

Things to Consider

1. What are the impacts to the existing System?
   • Our current system cannot accommodate a situation where a ListingMedia is created before a Listing so we will have to redesign the endpoints at content.
2. Can we re-use components of the existing System?
3. Can we clean up existing tech debt in the System?
4. How will this post create system grow in to the new feed architecture?

Proposed Changes

The majority of changes will take place on how ListingMedia will be handled throughout the system. It will follow the same Flow as the original architecture but there will now be Collections of multiple ListingMedia passed through the system instead of a single instance.

Changes to Content Service architecture:

Entity Changes

1. ListingMedia will be created before Listings are created.
   • We will need to make ListingId Foreign Key nullable as right now it blocks ListingMedia from being created without a value.

Add new endpoints to ListingMedia routes

1. Add new endpoint for Create ListingMedia that does not require a ListingId and will create unclaimed ListingMedia.
   • Create ListingMedia will no longer produce MQ messages as the ListingMedia is not completed until it has been linked to a Listing.
2. Add new endpoint for Removal of ListingMedia.
   • This is a hard delete from the system and can only happen if ListingMedia.ListingId == null

Add new endpoints to Listing routes

1. Add a new endpoint that creates a Listing and links a list of ListingMedia.Id's. POST listing/v2
   • Listings will no longer require all metadata to be input on creation. We will be expanding what can be set with the update endpoint.
2. Add a new endpoint for adding multiple ListingMedia to a Listing, that will link a list of ListingMedia.Id's to a Listing. PUT listing/v2/{ListingId}/media

File Url Changes

We will be creating a new file path for all content image and video url's that now match the following patterns.

/posts/{ListingMediaId}/image.jpg
/posts/{ListingMediaId}/image_thumb.jpg
/posts/{ListingMediaId}/image_src.jpg
/posts/{ListingMediaId}/video/*

Changes to Post Service architecture:

1. Create new handler in MqController that will handle BulkListingMediaMessage
   • This will follow closely to our existing message handler for individual post creation but will now take into account the IsDeliverable flag for each individual ListingMedia. Not all posts will be delivered to User's feeds.

Changes to Feed Service architecture:

1. Create new handler in MqController that will handle BulkPostsMessage
   • This will have similar changes to what the post service is experiencing where we are now just creating a handler to handle multiple posts at once. The feed should only deliver content that has the IsDeliverable == true condition.

Changes to the Shares architecture:

1. Create new handler in MqController that will handle BulkPostsMessage
   • This handlers will follow the same code logic as before but will be processing multiple post messages at once.

Changes to the Analytics architecture:

1. Create new handler in MqController that will handle BulkPostsMessage
   • This handlers will follow the same code logic as before but will be processing multiple post messages at once.
   • Something to Consider: Should we be kicking off a report message for every post that has been received as part of the BulkPostsMessage or should we push the bulk processing to the report MqController? If we report takes in a BulkReportMessage, it may require significant refactoring.
   • Only 1 ListingReportMessage will be sent for the entire batch of posts messages processed.
     • Unlike now where every PostMessage received by analytics generates a PostsReportMessage and a ListingReportMessage.

Test Cases

TODO - Fill in Test Cases

Diagrams

• Figure 1. Class Diagrams
• Figure 2. Flow Diagrams
• Figure 3. Activity Diagrams