일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 훈수 가능
- 블로그 뉴비
- 드림핵
- 코딩테스트
- Redux
- 오블완
- 고고학 최고의 발견
- redux state값 유지
- 부산 맛집 OPEN API
- expo
- level3
- 새로고침
- python
- react-router-dom
- Dreamhack
- 티스토리챌린지
- web-view
- React
- API 활용 신청
- 공공데이터 포털
- apk 빌드
- 창업 300
- url 랜더링
- 꿀팁 환영
- 보안
- php-1
- 사업계획서
- 프로그래머스
- 개발
- Today
- Total
목록개발/개발 고찰 (8)
1223v
고민의 시작 프로젝트을 진행하면서, 다른 사람들이 구현한 기능에는 간단한 지식만으로 알고 넘어간 부분이 있었다.하지만, 팀원이 구현한 코드 일지라도 우리 서비스에 대한 문제 해결 방식을 설명하기 위해 팀원이 구현한 해결 방법은 설명할 수 있어야 한다고 생각한다.번외로 만약 내가 구현했다면 어떻게 해결할 것인가? 라는 질문이 왔을때, 명확하게 대답하지 못하는 내 자신을 보고 아는것과 본 것에 대한 명확한 구분선을 지어야 겠다고 생각했다. 왜 이 고민이 필요해?💡 Race Condition 문제에서 MYSQL의 낙관적 락과 비관적 락으로 해결 했을때 어떤 장단점이 있는가? Redis 도입 시, 관리포인트 문제를 고려하지 않을 수 없다.만약, mysql로 쿠폰 발급을 한다면 어떻게 해결할 수 있을까? ..
고민의 시작우리 프로젝트는 MYSQL RT 저장 방식 ⇒ Redis RT 저장 방식으로 변경했다.그렇다면 고려해야하는 것이 redis가 다운되었을 경우의 복구 전략이다..💡 Redis 를 도입했을때 관리 포인트가 늘게 되는데 관리포인트가 느는 부분이 바로 redis가 다운 되었을 때에 대한 대처이다,,왜 이 고민이 필요해?현재 redis를 도입하는 대부분의 프로젝트들이 로그인에서 RT를 저장하는 부분일 것이다.사용자 ⇒ 로그인 시도 ⇒ at/rt 발급 ⇒ rt redis에 저장 ⇒ at/rt 반환 ⇒ 로그인 성공보통 토큰을 사용한 로그인은 위와 같은 과정을 따르는데,사용자 ⇒ 로그인 시도 ⇒ at/rt 발급 ⇒rt redis에 저장⇒at/rt 반환 ⇒ 로그인 성공redis가 다운된다면 다음 과정마저, ..
고민의 시작레디베리 점주의 주문접수 창이다.우리는 기본적으로 준 실시간성으로 데이터를 가져가기 위해서 폴링으로 데이터를 가져가고 있었다.그런데 어느날 학교 축제 주점의 결제 시스템으로 도입되게 되었고, 폴링에 따른 사용자도 늘어남에 따라서 CPU 사용량도 점점 올라가고 있는 상황이었다.또한, 축제가 끝난 뒤 기존으로 돌아와도 커피 스마트오더 특성상 점심시간 때, 혹은 2~3시에 주문이 피크였고, 그 이후에는 주문 수 적거나 아예 안들어오는 경우도 존재했다.💡 1. 주문이 없는 중에도 polling으로 계속 서버에 요청을 날리고 있음. 2. 사장님이 늘기 시작하면 polling에 따른 CPU 사용량과 네트워크 대역폭이 늘어남해결 가능한 방법론해당 글에서는 실시간 서버 푸시 요청, 응답에 대한 방법론 이야..

(ver.스프링부트 3.x , 스프링 시큐리티 6) 문제 인식Spring Security를 통해 세션방식 로그인 개발 진행 중, 로그인 시도 시 정상적으로 인증정보를 바인딩하고 있으나, 페이지 이동 시 인증정보가 없어지는 것을 발견했습니다.이에 해결과정과 코드를 공유하고자 합니다. 기존 코드의 문제점은 다음으로 추측했었습니다.SecurityContextPersistenceFilter란? SecurityContextPersistenceFilter SecurityContextPersistenceFilter는 Spring Security에서 매우 중요한 필터 중 하나로, HTTP 요청이 들어올 때 SecurityContext를 세션에서 복원하고, 요청이 완료되면 SecurityContext를 세션에 저장..
문제 인식통번역 플랫폼 개발 진행 중, 음원과 녹음 동시 작업 실행 시, 녹음의 품질이 저하되는 것을 발견했습니다.이에 해결과정과 코드를 공유하고자 합니다. 기존 코드의 문제점은 다음으로 추측했었습니다. 문제점 종합1. recorderDestination와 audioContext가 컴포넌트가 리렌더링될 때마다 새로 생성됨audioContext와 recorderDestination이 컴포넌트가 리렌더링될 때마다 새로 생성됩니다. React 컴포넌트는 상태 변화로 인해 여러 번 리렌더링될 수 있는데, 이때마다 새로운 AudioContext와 MediaStreamDestination이 생성되어 기존의 오디오 스트림이 무효화되거나 상태를 유지하지 못할 수 있습니다. 2. 비동기 처리 문제navigator.m..
고민의 시작 🌟🌟🌟보통 대학생 프로젝트를 진행하면, 개발 - 기획 - 디자인 - 마케팅의 영역이 명확하게 분리되어 있지 않고, 기한에 맞춰 데드라인 개발을 하는 경우가 많을거다. 그래서, 규모가 작은 프로젝트는 테스트를 작성하지 않고 진행하는 경우가 많고 이로 인해 모든 서비스가 의존하고 절차지향적 코드가 되며, 이후 유지보수가 힘들어지는 코드가 된다.또한, 모든 비즈니스 로직에서 발생하는 에러들이 서버를 돌리고 QA과정에서 발견되며, 이를 수정할 때 역시 단위별로 테스트할 수 있는 것이 아닌 유기적으로 연결되어있는 코드를 하나씩 따라가 보며 수정해야한다….필자는 이러한 문제를 서비스가 완성되고 리펙토링하면서 이것이 과연 객체지향적이라 할 수 있는가? 라는 의문이 들게 되었고, 테스트 코드를 작성해..

고민의 시작대학생분들이 IT 스타트업을 창업해 서비스를 구현한다고 하면, 회원제는 필수로 구현하게 될 것이다. 하지만, 고민에 빠지게 되는 것은 큰 IT 기업은 대부분 세션 방식을 쓰는데 왜 세션을 사용하는 거지? 토큰 방식은 왜? 근데, 그럼 뭐써? 라는 고민을 한 번쯤은 해봤을 것이다.필자도 로그인 파트를 진행하면서 세션과 토큰 중 추후를 위해 어느 방식이 좋은 것인가에 대해 고민하게 되었고, 직접 사용해본 경험을 토대로 세션과 Token의 필요성, 장,단점 그래서 레디베리는 왜 이 방식을 선택했는지 추후 문제는 없는지를 이야기 해보고자 한다. 왜 인증에서 상태가 필요해?Stateless인 HTTP 특성으로 사용자를 특정할 수 있는 어떠한 수단이 필요하다.이를 위해, 세션 혹은 토큰을 사용해 서버와..

우선 리프레시 토큰이롼?Access Token의 유효기간을 짧게하여 보안도 높이고, 편의성도 챙기는 방법이다.로그인을 완료하면, 유효기간이 짧은 Access Token과 유효기간이 긴 Refresh Token을 발급해준다.Access Token은 기존에 사용하던 JWT 토큰이라고 생각하면 되고, Refresh Token은 Access Token이 만료되었을 때, 새로 발급해주는 토큰이라고 생각하면 된다. 기존 방식기존의 점주사이드와 유저사이드의 refreshtoken은 유저쪽에 한개의 컬럼을 만들어 조회되는 방식이였다.문제는 리프레시 토큰 개념을 활용하려면, 불가피하게 서버측에서 토큰 정보를 저장할 수 있는 곳이 필요했다…당시에는 RT의 보관을 MVP 개발 기간이 짧아 그냥 Mysql에 저장했었다.하지..