search

news-reply-sentiment-analysis / j2kb-news-reply-sentiment-analysis

Main repository about analysis reply sentiment project.
2 stars 0 forks source link

회원정보를 관리하기 위한 API 요청 #15

Open waltererz opened 3 years ago

waltererz commented 3 years ago

혹시 회원가입 관련 API를 개발하시는 분은 누구이신지 알 수 있을까요?

기본내용

제가 생각하는 테이블 기본 스키마는 아래와 같습니다.

users

NoSQL(MongoDB)을 사용한다면?

저는 개발자가 아니기 때문에 가장 효율적인 개발방법이 무엇인지는 잘 모르지만, 한 가지 건의드리고자 하는 것은 'SQL과 함께 MongoDB도 함께 사용하는 것이 어떠한가' 입니다. 기본적으로 MongoDB는 JSON 방식으로 데이터를 저장하기 때문에 아래와 같이 정형화되지 않은 내용들도 쉽게 저장할 수 있습니다.

{
  'uuid' => 'f266c2b3-2b8d-4849-92a8-0f0a52dabab1'
  'urls' => [
    'url1',
    'url2',
    'url3',
    ...
  ]
}

이미 요청된 적이 있는 URL을 다른 사람도 요청하는 경우에는 기존의 데이터를 쉽게 가져올 수 있습니다.

MongoDB에서는 아래와 같이 이미 요청된 적이 있는 URL을 필터링할 수 있습니다.

{urls: url}

SQL에서는 테이블이 정형화되어 있어 배열을 저장하려면 serialize를 해야하는 번거로움이 있는 것으로 알고 있습니다. 검색하는 것도 어렵구요. 데이터를 어떻게 데이터베이스에 저장할 것인지 한 번 논의해보면 좋을 것 같습니다.

API 상세

회원가입

PUT http://domain/api/users data email, password, firstname, lastname, social_account response { (true | false) }

로그인

POST http://domain/api/users data email, password, social_account response { (true | false) } etc 로그인을 성공한 경우 쿠키 생성

로그아웃

POST http://domain/api/users data null response { (true | false) } etc 쿠키 삭제

회원탈퇴

DELETE http://domain/api/users data uuid response { (true | false) }

회원정보 반환

GET http://domain/api/users/{uuid} response { uuid, email, firstname, lastname, last_logged }

xoxwgys56 commented 3 years ago

👍🏼 정말 보기 좋게 잘정리해주셔서 이해가 잘가네요. 감사합니다!

API 담당

아직 회원가입 API를 누가 담당할지에 대해 정해지지 않았습니다.

uuid

mongoDB

네 mongoDB를 같이 사용하는 것은 좋습니다. 하지만 근거가 좀 더 명확해지면 좋을 것 같습니다. "mongoDB를 사용해보면 좋을 것 같다" 혹은 "NoSQL이 우리 프로젝트에 더 적합한 것 같다" 등. 제 생각엔 도입하는 이유는 어떤 것이 되어도 괜찮다고 생각합니다.
하지만 말씀하신 내용으로는 도입했을 떄, 어떤 기능을 담당하게 하는지 좋을지 불명확해보입니다.

만약 monogDB 혹은 NoSQL을 경험해보시기 위해 도입하는 것이라면, 그것도 좋은 이유라고 생각합니다. 이 경우 필요한 케이스를 만들거나 찾아봐야할 것 같습니다.

또한 프로젝트에서 중요한 기능을 언급해주신 것에 감사드립니다.
말씀을 듣고 보니, 이와 관련된 기획이 정리될 필요가 보이네요. 이에 대해서 @SUMIN-WEE 님도 생각해봐주시기 부탁드립니다. :0

번외로 제가 로그인 기능이 정리되어야 한다고 생각하는 이유는 아래와 같습니다.

  1. SSO로 유저 정보를 받을 때, 어떤 정보를 저장할 것인가
  2. 만약 이메일을 가져올 수 있다면, 저장된 유저 정보를 비교해서 이미 등록된 유저인지 판별하는 것은 어떠한지
  3. 유저 정보를 저장한다는 것은 유저 사용기록도 저장한다는 것인지
  4. 이메일을 저장하는 방식이라면, 유저가 단순히 이메일과 비밀번호만 등록해도 가입할 수 있도록 해야하는 것인지 a. 이 경우, 유저가 입력한 이메일이 유효한지 확인하는 기능이 필요합니다.

저는 이러한 이유로 로그인 기능이 정리될 필요가 있다고 생각합니다.
할 일이 생기기 시작하니, 프로젝트가 서서히 굴러간다는 느낌을 받게 되네요 :) 너무 기쁩니다!
다시 한번 @waltererz 님께 감사드립니다! 👍🏼 👍🏼 👍🏼

xoxwgys56 commented 3 years ago

you are programmer

제가 깜박하고 언급드리지 않은 사항이 있는데요.
본인이 개발자가 아니라고 말씀해주셨지만, 제 생각엔 이미 멋진 개발자이십니다. 함께 프로젝트를 진행하게 되어 기쁩니다! :)

waltererz commented 3 years ago

@xoxwgys56 감사합니다. ㅎㅎ

이메일 중복여부 확인과 이메일 검증은 간단하게 가능할 것 같습니다. 이메일 중복여부 확인을 위해 API가 하나 더 필요하겠네요.

아마 아래와 같은 결과를 생각하시는 것 같은데 맞을까요?

Screenshot_20210803-234920_Chrome.png

Screenshot_20210803-234931_Chrome.png

Screenshot_20210803-234941_Chrome.png

waltererz commented 3 years ago

@xoxwgys56

한 가지 사례로 설명해보겠습니다.

  1. 유저A가 뉴스A에 대한 여론을 분석하고 싶어 요청함
  2. 알고리즘에 따라 여론 분석 후 결과 저장, 화면에 출력
  3. 유저B도 뉴스A에 대한 여론 분석 요청함
  4. 이미 분석된 뉴스이므로 저장된 결과를 출력

신규로 등록된 뉴스라면 새로운 댓글이 계속 등록되기 때문에 여론 추이도 바뀌겠지만, 오래된 뉴스는 그렇지 않을 겁니다.

그러므로 여론분석 결과는 특정 테이블이 잘 정리해두고, 사용자가 URL을 요청하는 경우 이미 분석된 URL인지 확인하는 절차가 필요하다고 생각합니다.

그리고 사용자별로 분석했던 URL 목록을 저장해야 하는데, 나중에 가장 많이 분석된 URL이라든지 분석된 URL 순위 등을 추출해낼 때 mongoDB를 사용했을 경우 효율적이라고 생각했습니다.

SQL의 경우에는 별도의 테이블(ex: urls)에 요청되는 모든 URL을 사용자와 함께 저장하거나, 사용자별 테이블(ex: user1_urls, user2_urls, ...)을 생성해야 하는데 mongoDB를 사용한다면 이 문제를 간단하게 해결할 수 있다고 봅니다.

위에서도 작성했듯이 mongoDB에서는 배열을 통째로 저장할 수 있고, 아이템을 추가하거나 필터링을 통해 검색하는 것이 가능하기 때문입니다.

프로세스를 그려보면

  1. 사용자가 URL 분석 요청
  2. 분석결과 테이블에서 이미 완료된 결과를 찾음
  3. 만약 이전 결과가 없으면 새롭게 URL 분석
  4. 분석 결과를 테이블에 저장하고, mongoDB 사용자 컬렉션 중 해당하는 사용자 문서에 URL 배열 아이템 추가
  5. 결과 출력

아래의 작업을 할 때 mongoDB가 유용하게 사용될 수 있습니다.

xoxwgys56 commented 3 years ago

@waltererz

조회 API

네 위의 코멘트에서 언급해주신 내용이 맞습니다. 말씀하신 것처럼 조회 API가 필요하겠네요.

데이터 수집

아래의 코멘트에서 언급해주신 내용에 대해 공감합니다. 말씀해주신 내용은 캐시와 같은 기능을 하는 것을 말씀하신다고 이해했습니다.

우선 아래의 내용이 정리되야 합니다.

  1. 오래된 뉴스의 기준
  2. 오래된 뉴스의 경우 데이터를 한번만 수집할 것인지. 혹은 주기적으로 수집한다면, 단위가 어떻게 되는지
  3. 혹은 사용자의 요청이 발생한 경우에만 수집할 것인지

또한 말씀해주신 내용으로 아래와 같은 추론을 했습니다.

제 생각

제 개인적인 의견은 데이터를 저장하는 것은 좋으나, 그것을 캐시로 이용하는 것은 사용자가 원하지 않는 결과를 반환할 수 있다고 생각했습니다. 예를 들어 아래와 같은 경우가 존재할 수 있습니다.

이러한 경우, 사용자는 원하지 않는 결과를 받을 수 있다고 생각합니다.
그러므로 제 생각에는 우선 데이터를 수집하고 반환하는 구조를 만들고, 내부 혹은 외부에서 확인할 수 있는 지표를 만드는 것이 필요하다고 생각합니다. 어떤 사람들이 이전에 수집된 데이터를 다시 수집하려고 했는지 등에 대한 통계가 필요합니다.
이를 기반으로 결정하는 것이 더 좋다고 생각합니다. (제 개인적인 의견입니다 ~~.)

별도로

말씀해주신 것을 보고 생각이 난 아이디어가 있는데요. 다른 사용자가 검색한 기록과 유사한 키워드 혹은 기사를 검색하면, 이전에 검색된 결과를 보여주는 것이 꽤나 의미가 있을 것 같네요.
그리고 말씀해주신대로, monogDB를 쓰는 것은 괜찮을거 같습니다. 다만 RDB와 혼합해서 사용하면 검색시간을 줄일 수 있을거 같은 느낌적인 느낌이 드네요. RDB를 key-value DB로 쓰는 것도 방법이겠습니다. 실제 데이터는 mongoDB에 넣고요.

다시 한번 좋은 의견 감사드립니다.