Practice : Composing Web Pages, Designing APIs, and Separating Domains With Reference to Previous Project : FE & BE different perspective

#Foreword

Before I begin, I want to ensure that I am not a professional programmer, This document will be my logging and practice to remind myself of my final project from bootcamp, and preparation for my another bootcamp proejct that is going to start on May. This document will outline Backend's side project initial design, The reason why I do this is because, Frankly speaking, I couldn't join to make ERD, API Design, overall architecture for this project initial set-up. At that time, I should've joined to make it with passion, sadly, My skills was so poor compared to my teammates, so it was so hard to figure out how it flows. I won't use the results of them, Instead, I will try to practice designing backend initial set-up with my own by referring to my final project. (I was about to refer to operating site, come to think of it, this way is more practical to gain practical knowledges for my next team projects.)

#To compose a specific web page, what do we need (Backend - ERD, API)

Normally : RFP (Request For Proposal) PM, UX/UI Design -> Backend ERD.

But, I will try to track of this in opposite way, Finished Product -> Analyze Function -> Seperate Domain / Table.

As I see it now, The finished result site is too big to post whole image, So This document handles approaches : "How to seperate Domain / Table for making ERD and How to design API."

See image below.

# Write down all functions that you can recognize (Don't think too much, just write down intuitively)

  1. 출발일 변경 : Change the start day

  2. 상품 소개 탭 : Product description tap (Tour information)

  3. 일정표 탭 : Schedule tap

  4. 등록된 리뷰 탭 : registered review tap

  5. Scroll image to the side

  6. Leave a review with counting star(register new review)

  7. Get back to previous page

  8. Add wishlist (click heart) : feature to save for later use

  9. 카테고리 탭(로컬, 문화/역사, 건강/웰니스, 자연) : Category tap(Local, Culture / history, Healthy/Wellness, Nature)

  10. 1:1 비교하기 : One to One Comparison

  11. 예약하기 : Reserve

-> Like above, I listed all functions that I can recognize, I am not sure this is all of functions as it is, but, When I want to analyze or extract crucial information, I had list them and then sepearte it to make it simple. When you feel complicated to resolve problems, we need to make it simple state, In doing so, We can approach one by one.

#Try to figure out which domain(DB Table) is suitable for each function.

  1. Change the start day -> Product table ??

  2. Product description tap (Tour information) -> Product table or Product description table (Separate table : Optional)

  3. Schedule tap -> Product description table or Product table (Separte table : Optional)

  4. Registered review tap -> Review table ??

  5. Scroll image to the side -> image ?????? -> UX or UI ??

  6. Leave a review with counting start(register new review)-> Review table

  7. Get back to previous page -> Page transition/Navigation -> UX or UI

  8. Add wishlist (click heart) -> Wishlist table

  9. Category tap(Local, Culture / history, Healthy/Wellness, Nature) -> Product description table or Category table(Separate table : Optional)

  10. One to One Comparison -> Product table ?? (Product vs Product -> comparison)

  11. Reserve -> Product?? Order?? -> Reservation probably means "Order" in tourism industry.

#Try to figure out which operation is suitable for each table and function among CRUD.

  1. Update Product : Change the start day

  2. Create Product ?????? : Product description tap (Tour information)

  3. Create Schedule ????? : Schedule tap

  4. Create Review????? : registered review tap

  5. ???? maybe responsible for FE, UX/UI : Scroll image to the side

  6. Create Review : Leave a review with counting start(register new review)

  7. ???? FE, UX/UI ? : Get back to previous page -> Page transition

  8. Create Wishlist : add wishlist (click heart)

  9. Create Category : Category tap(Local, Culture / history, Healthy/Wellness, Nature) -> Product description table or Category table (Optional)

  10. ?????????????????????

    I guess Business Logic in ProductService (Product to Product) : One to One Comparison

  11. Create Order : Reserve -> Product?? Order?? -> In this case, means Reservation can mean "Order" in tourism industry.

#Problem

: Product Description Tap, Schedule Tap, Review Tap

There're problems we should care about, When it comes to Product Description Tap, Schedule Tap and Review Tap, They are displaying data fetched from BE..... As I wrote down "Create ~~", I wasn't sure it's proper CRUD and API, Http Method......If so, to resolve this, What things do we need to consider and How to approach......?(I felt ambiguous when I think of this.)

Before resolving this, see below images first.

These images are data fetched from BE after FE requested for.

#Resolution

In the process of building a web application, both the front-end and back-end collaborate closely. Additionally, when composing web pages, the back-end relies on the front-end to create it. Therefore, I tried to approach these problems from the front-end perspective. What does the front-end consider while creating specific web pages?

(Product Description : 상품소개, Schedule : 일정표, Review : 리뷰 탭)

FE perspective.

  1. Specific buttons such as 상품소개, 일정표, 리뷰 (in this project), trigger requests to fetch data from the back-end

  2. Displaying data on the web page : Data fetched from the back-end is displayed on the web page using API calls

  3. HTTP method (URL _ API)

    :Product Description Tap : GET method -> /get/products/{id}

    :Schedule Tap : GET method -> /get/products/{id}/schedules

    :Review Tap : GET method -> /get/reviews/{id}

Thanks to this approach, I was able to remove "Create", which gives me a sense of "Registering something". I don't think I am totally wrong in this regard. If I had approached this problems only from the back-end perspective, I wouldn't have resolved them. (POST method)

As a result, the front-end fetches data from the back-end using API calls, and it is displayed on the web pages. In other words, Data fetched from the back-end is already in the back-end side, so we can conclude that we need to use "GET method" to compose the pages(as shown in the images above). Although the back-end provides APIs, the user of these APIs is the front-end. I think this is because we need to consider perspectives. (As you can see, POST method is fundamentally different from GET method.)

#Extract URL For API

  1. PUT -> /put/products/{id}/startdate

  2. GET -> /get/products/{id

  3. GET -> /get/products/{id}/schdules

  4. GET -> /get/reviews/{id}

  5. ???? scroll image to the side

  6. POST -> /post/review

  7. ???? get back to previous page

  8. POST /post/wishlist

  9. POST /post/category

  10. ?????????? : Logic in Product Serivce (Comparison)

    POST : /post/products/comparison

  11. POST : /post/order

Extract URL For API

  1. PUT -> /put/products/{id}/startdate: Updates the start date of a product with the given ID.

  2. GET -> /get/products/{id}: Retrieves details of a product with the given ID.

  3. GET -> /get/products/{id}/schedules: Retrieves schedules related to the product with the given ID.

  4. GET -> /get/reviews/{id}: Retrieves reviews related to the product with the given ID.

  5. ???? scroll image to the side

  6. POST -> /post/review: Adds a new review.

  7. ???? get back to previous page

  8. POST -> /post/wishlist: Adds a product to the wishlist.

  9. POST -> /post/category: Adds a category.

  10. ?????????? : Logic in Product Serivce (Comparison)

    POST -> /post/products/comparison: Compares multiple products based on specific criteria.

  11. POST -> /post/order: Places an order.

For the actions marked with "????", here are the suggested actions:

  • Scroll image to the side: This action is typically handled on the front-end side. There's no specific URL or HTTP method associated with it. It's more about implementing the functionality in the user interface.

  • Get back to the previous page: This is usually handled through browser functionality or client-side scripting. There's no direct URL or HTTP method associated with it.

  • Logic in Product Service (Comparison): If you're looking to compare products, : Product to Product , you might consider implementing this logic in the backend service (ProductService). You can create an endpoint for comparison, such as: