결제 프로세스
우리는 결제 솔루션인 아임포트를 활용해서 테스트 결제를 해볼 것!
실결제를 위해서는 카드사 승인이 필요함!
준비물 : ppt(결제과정, 테스트계정) / (도박, 경매, 직적입력x)
결제기능은 시간이 아주 오래 걸린다! 서비스 오픈 일정을 잘 고려해야함
내정보에 있는 가맹점 정보 확인
자기 계정일 때 pg설정 테스트모드 on 해두기
실명이 필요할 경우 본인인증 서비스 활용 - 다날 등
웹훅노티피케이션 - 무통장입금 결과를 아임포트에서 백엔드로 보내줌
우리가 백엔드로 mutation 해줘야 할 부분!
스크립트가 시행되며 윈도우 안에 제이쿼리 및 아임포트 기능을 다운받아준다
그래서 결제 페이지에서만 나오는 IMP (다른페이지에는 window안에 IMP가 없음)
그 IMP안에 있는 request pay기능을 실행하게 된다.
imp_uid 중요
모바일 크롬창에서는 아예 다른 페이지로 넘어가버린다. 이상황에서 결제하면 rsp를 받아올 수가 없다. 그래서 백엔드에서는 웹 훅 노티피케이션을 통해 무통장 입금처럼 로직을 처리해야한다. 프론트에서는 결제를 완료했을 때 이동해야 할(돌아올) 페이지를 만들어야 함 (옵션)
결제 완료 후 결제 시간을 넘겨줄 때 프론트에서 시간 생성 xx
사용자마다 시간 다를 수 있음
백엔드에서 세계 표준시 (UTC)로 시간 저장
프론트는 화면에 각 국가의 표준시로 변환하여서 보여준다
정기결제?
🌼 event를 발생시키는 2가지 방법
1) 사용자가 이벤트를 발생 (클릭, 변경 등을 했을 때)
2) 특정시간이 되면 자동으로 이벤트 발생 => 크론탭(리눅스 내장 기능) => 특정 날짜, 시간 + 기능(api실행, 특정 코드/스크립트 등)을 등록
setTimeout과 event-loop
시간이 오래걸리는 작업(setTimeout)을 기다리지 않고 background로 보낸다
실제 실행되어야 할 함수를 태스크큐 -> 콜스택 순으로 보낸다
그 사이 콜스택에 있는 것들이 먼저 실행
이벤트 루프에서 일하는 일꾼 1명
(single event-loop-thread)
thread (프로그램 안에서 실행시키는 일꾼) vs process(프로그램)
일반적인 다른 언어들은
Multi-Thread
시간이 오래걸리는 작업들이 병목현상이 일어나지 않게
그럼 작업 속도가 빠를까?
일하는 cpu 저장 하는 memory
작업을 조금씩 나눠서 하는 것이기 때문에 동시에 처리하는 것 처럼 보일뿐...
cpu가 많으면 동시에 처리하는게 맞음
일하고 넘어가기 위한 저장 (context-switching) 다시 돌아와서 일하고 -> 저장 ...
병목 지점이 없다면 시간 총량은 단일 쓰레드가 더 빠르다
;ㅑㅔ]ㅐㅕ[\ㄷ굣3890-=
