Likes -- information needed

[kubazuch]

What does @Java-DZGS/frontend need from @Java-DZGS/backend in regards to product/ingreedient liking?

Probably some endpoint to POST likes/dislikes? Do you guys also want such thing:

when user is logged in and makes product list get request, the backend also returns information whether this product is liked or not

or do you want to do it some other way?

[andrmdmd]

Yes, the info should be present in products list when user is logged in. Additionaly, we can either provide it in the response to get product details call, or do it in a separate call (eg. isLiked endpoint). We would also want to get full lists of liked/disliked ingreedients for user profile.

So, to summarize, endpoints connected to like feature:

• products list (isLiked field)
• product details or as isLiked endpoint
• post/delete endpoints for product
• post/delete endpoints for ingredient
• liked ingreedients list endpoint
• disliked ingreedients list endpoint

The last two endpoints could be connected together or stay apart (and possibly paged, but we should talk about the need for it).

[GitQueenZofia]

I have a plan for this endpoint and I would like to hear your opinion. I think we should separate this task into two:

1. Products likes (we already have products endpoint)
2. Ingredients likes (we don't have ingredients endpoint yet)

I think we should have tables users_products (we have this table in database), users_liked_ingredients, user_disliked_ingredients (we have table users_allergens, should we use it or change its name?) to store user_id and product_id/ingredient_id when it's liked/disliked by this user. I think with these tables it would be easy to add isLiked field to products list or isLiked endpoint. Which one do you think is better? I think the first solution is better, because when frontend wants to show products list it has to make a call to isLiked endpoint many times so I think we should add isLiked field it when we return products list. I can't wait to hear what you think. Have a good day everyone :)

[kubazuch]

Yes I agree. The tables you propose are a good choice. I see this as such:
User gets new fields, example for liked ingredients:

@ManyToMany
@JoinTable(
        name = "users_liked_ingredients",
        joinColumns = @JoinColumn(...),
        inverseJoinColumns = @JoinColumn(...)
) 
private Set<Ingredient> likedIngredients;

For liked products we can't do such thing, as products and users are in different DBMSes.

private Set<Long> likedProducts;

At the same time we should add field such as likedBy with user id to the product document, for efficiency. We can get authenticated user's id by:

User user = userService.getUserByUsername(authService.getCurrentUsername());
long userId = user.id;

When we get page of products we can check if userId is in products likedBy Set/List/... . Then on product page fetch we can replace the likedBy Set/List/... by isLiked boolean in DTO.

When user likes/dislikes some product, we should add/remove the user id from this product's likedBy and simultaneously add/remove the product id to user's likedProducts.

Why do we need the likedProducts list then? Well, if we wanted to show a list of products liked by some user, we would have to rely on mongodb for checking ALL products whether they have some user in their likedBy list. I suspect this would be very slow. With the likedProducts list we can just tell mongo "Hey, give me products with those ids" which I suspect will be super fast 🏃‍♂️ If you have some comments or questions or sth tell me 😺