백엔드 프론트 국내 좆소들은 국제화를 신경안써서

일방적으로하는데


국제화가 필요할경우 상업플랫폼인경우

본인인증 수단을 나눠야됨


1. 백엔드에서 이메일 또는 모바일 인증을 구현해야함


2. 프론트엔드에서는 이메일 또는 모바일인증과 국내 인증 모듈이필요함 ( 다날 nice같은)


프론트엔드에선 인증메소드를 호출한다한들 결국엔 이메일인증을 제외한

다날 , nice 모듈에서 인증처리를하고 그 데이터를 백엔드에 콜백치고 저장하든가 함

백엔드에서 할것 -  다날 , nice 같은경우엔 콜백 처리된 데이터 db에 넣음

그거에대한 엔티티 , 준비

이메일인증은 자체메일서버가없다는 전제하에 nodemailer같은 라이브러리 사용

redis 인증코드 저장 (  speakeasy 같은 암호화 선택사항)

프론트엔드에서 인증코드 받음 redis 조회 ( speackeasy 사용했다면 디코드)

이러한 요청에서 데이터에 DTO , 사용자 인증 허가 ( JWT 또는 세션)준비


프론트에서 할것 - 이메일 인증 폼 과 이메일 이메일 코드 검증 백엔드호출

                            모바일인증 - 해외번호인지 검증 후

                            해외번호라면 일반 모바일인증 사용 ( 백엔드호출)

                            일반 한국번호라면 danal 본인인증 ( 프론트엔드 ) 후 콜백 (백엔드 url )


이에 백엔드나 프론트에서는 뭐 가를거없이 둘다 일방적이고 매우 기본적인 사항들임 ( 못하면 나가뒤져라 )


하지만 여기서 진짜 갈림 UI UX를 중요시한다면 프론트가 진짜 힘들어짐

예를든다면 국제화된 플랫폼이있다는 전제하에

위와같은 국내 인증자와 , 일반 국제회원이있다면

각각 맞는 서비스를 보여줘야되고 ( 프론트 ) 제공해줘야됨 ( 백엔드)


백엔드에서는 만약 회원별로 나눠진 서비스를 제공하기위해선 앞에 인증하기전에 이미 이 사람은

국제회원 또는 국내회원 이라고 나눠졌을꺼임. ( danal , nice 본인인증)

만약 같은 국내 또는 국제 서비스이지만 분명 달라야하는 경우가있음.

그에 따른 로직들을 모듈화해서 조립하고 , 프론트의 매게변수나 JWT를 디코드하여 이사람이 국내,외 회원인걸 단순하게 구별할수있음.

필요하다면 DB조회

그런다음 그 해당되는 서비스를 실행하게하면됨.

어느정도 고도화가 됨


프론트 애미시발 if문 남발함. 만약 대쉬보드같은 페이지가있고. 한 컴포넌트에 아래같은 조건이 걸려져있음.

예를들면 국제 회원에게는 select에는 무수한 옵션들이있고 input으로 맵핑을하여 서칭이 가능하도록 해야됨.

하지만 국내회원에게는 리스트가 해당이 안되거나 단일 항목만 있을 확률이높음

이때는 대시보드에서 이 컴포넌트를 빼버리거나 하는 그런 방법이있지만 하더라도

전체적인 UI에 어색함이 생김. 처방전은 if문 사용이겠지.

이 컴포넌트만 그런게아니라 다른 컴포넌트에도 if문사용해서 사용자별로 같은 형태의 서비스지만 지원하고. 안하는걸 구별해서

새로운 컴포넌트를 만들어서 사용하거나 변경해야함.


ㅇㅋ 여기까진 프백 그냥 단순 if문 처리하거나 스위치문 써서 어째저째하면됨.

크게크게 보면 같은맥략임.


근데 하면서 내가 제일 힘들어했던건


프론트 uiux임 .

부트스트랩 출신이라 테일윈드 사용하는건 솔직히 이미 적응하고 떡치고도 남앗다 생각듬.

그럼에도 불구하고 전 , 처리 , 후 과정을 3개로 나눠서

프론트에 입히는건 가혹한일임


(참고로 나 스벨트씀 ㅋ )
이러한 sendCode라는 함수에 I라는 문자열을 Type이라는 매게변수를 백엔드 보내는 예시임 ㅇㅇ


functio nsendCode(Type:string){
try{

axios.post('뭐대충 URL ' , {Type})
send=true
alert('success')
}
catch(e){alert(e)}
}
 <button class="ㅇㅇ" on:click ={sendCode('I')} disabled={send}}></button>  (전 )
만약 sendCode함수가 정상적으로 백엔드에 호출을하엿다면 send는 true가 됨.
그럼 이 버튼은 disabled이 됨. 또는 class를 추가해서 css변경하거나 ㅇㅇ 사용자가봤을때 아 전송이됬고  버튼이 비활성화 됬구나 라고 느낌 ( 처리 )


그럼 이제
{#if send}
<input type="text" placeholder='코드입력'/> 이러한 코드를 쓰거나 어째저째하면됨
{뭐..타이머 ? }
{/if}



alert <-- 이거 쓰는 사람도있겟지만 난 modal 커스텀해서 스토어에 상태 박고 사용함
그에따른 에러 , 성공 css도 다 달라야되고 그에 맞는 매게변수를 보내서 유연하게 사용해야됨.

지금까지 전반적으로 if문 사용하거나 상황별로 처리하는 방식은 프론트나 백엔드 매우 비슷함.
단순하고 ,
다만 프론트에서 UIUX를 중요시하다면 이런 좆같이 나누거나 저렇게 if문써야됨. 덤으로 alert 안쓰고싶으면 modal 새로 만들어서 쓰고 ㅇㅇ.
대부분 프론트 보면 이렇게까지 modal 커스텀이라던지 사용안하는게 대부분임.
그래서 백엔드 입장에서 프론트 병신ㅋㅋ 이라는 말이나옴
만약 프론트에서 이메일 검증식을 사용해보자
프론트에서 내가쓰는 이메일검증식임
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/
let email
  function validateEmail() {  isValidEmail = emailRegex.test(email)   }

<input type="text" class="form-control" placeholder="{i18n.t('email_placeholder'}  bind:value={email} on:input={validateEmail} />
{#if !isValidEmail}      {isValidEmailMsg}     {/if}
input에 텍스트를 입력할때마다 validateEmail함수에서 emailRegex 이메일 검증을 실행함.
isValidEmail 에 맞으면 true , 틀리면 false

밑에 isValidEmail 불리언에따라 메시지를 나타냄.

왜 프론트에 검증식을 박냐 ??? 라고 할수있음
백엔드 사전에 불필요한 요청과
유저가 입력한 이메일에 대한 에러를 실시간을 보여주기 위함임. 렌더링은 클라이언트의 몫 하지만 스벨트라 ㄱㅊ

결론
백엔드 프론트 할꺼없이 다 힘들다
다만 프론트에서 UIUX관련 딥하게가면 좆같을수있다.
하지만 스벨트를 사용한다면 쉽고 빠르게 핵심만 잡는다면 해결할수있다.