Everything is Trade-Offs Everything is Trade-Offs

자동로그인은 앱 개발에 대중적으로 들어가는 기능 중 하나입니다. 현업에서는 신입에게 처음 내주는 흔한 과제이기도 하지만 인증·인가를 생각한다면 쉽게 구현할 수 있는 기능은 아닙니다. 그래서 이번에는 기본적이지만 많은 학습이 필요한 로그인과 토큰 관리에 대해 알아보도록 하겠습니다. ✓JWT 발행 조건 설정 with 소셜로그인 토큰은 인증이 성공되면 그 결과로 발행됩니다. 즉 성공적으로 로그인이 된다면 서버에서 토큰을 발급해주는 로직이 구축되야 하는 것이죠. 이전에 인증은 "유저가 서비스에 자신의 신원을 확인하고 증명하는 과정"이라고 설명했었습니다. 유저의 신원을 확인하기위해선 먼저 유저를 특정할 유니크한 값을 고민해야 합니다. 자체 회원가입만 있는 앱의 경우 유저가 입력한 ID를 식별값으로 쓰면 되기 때..

로그인을 구현하면서 인증과 인가에 대한 부분은 개인적으로도 학습하고, 개발 팀원들과 많이 토론했던 부분입니다. 그때 얻은 인사이트와 학습한 내용을 토대로 정리해보겠습니다. ✓ 인증(Authentication), 인가(Authorization) 우리는 배달의 민족을 사용하거나 네이버에 로그인할 때 등 어떠한 서비스를 이용하기 위해선 로그인 절차를 꼭 거쳐야 합니다. 로그인은 결국 인증(Authentication)을 하기 위한 행위입니다. 그렇다면 인증은 무엇을 의미하는 걸까요? 📌 인증 (Authentication) 유저가 서비스에 자신의 신원을 확인하고 증명하는 과정 서비스의 중요한 데이터나 리소스를 보호하고 불법적인 액세스로부터 방어할 수 있다. 인증된 유저는 서비스를 이용할 때, 리소스 및 기능에 대..

처음 flutter 개발을 시작하면 가장 먼저 접하는 것이 widget을 이용해 간단한 UI를 제작하는 것입니다. 학습을 하는 단계에서는 위젯을 간단하게 사용해서 화면을 만들지만, UI/UX디자이너와 협업을 하게 되면 요구되는 디자인에 맞게 거의 대부분의 위젯을 커스텀하는 작업이 필요합니다. UI를 구조를 잡기 전엔 제작한 위젯과 화면이 많아질수록 파일 간 이동할 일 있을 때, 방금 작업한 파일의 위치도 생각이 나지 않아 하나하나 파일을 눌러 코드를 보면서 찾았던 기억이 있습니다. 그때 스스로 학습한 것을 바탕으로 프로젝트에 개념을 적용했던 과정을 글로 남겨보도록 하겠습니다. ✓ Widget 플러터에서 위젯은 UI를 구성하는 기본 단위입니다. 위의 화면은 단순히 모든 위젯을 노란박스로 표시한 상태입니..

이전 글에서는 클라이언트단의 비즈니스 로직을 다루는 Application-Layer에 대해 말하면서 Result 패턴을 활용해 레이어 간의 독립성을 강화시키는 법 등을 소개했었습니다. 이번에는 사용자와 가장 근접해 있는 view, screen, widget 등을 다루는 Presentation-Layer에 대해 이야기를 나눠보겠습니다. 제 프로젝트를 기반으로 설명하는 거라 아키텍처와 무관한 내용이 포함될 수 있습니다. ❗️주의: 스스로 학습하며 구성한 프로젝트라 현직자 분들이 보시면 이상하게 느끼실 수 있습니다. "쟤는 저런 식으로 해봤구나" 정도로만 봐주시고 만약 틀린 부분을 발견하셨다면 피드백 남겨주시면 감사하겠습니다 해당 글은 이전 글에서 계속 이어집니다. 순서대로 보시고 싶은 분은 아래 글을 참고..

퍼블리싱만 하던 단계에선 상태관리가 무엇인지 신경 쓰지 않고 setState()를 남발하면서 만들었습니다. 하지만 api와 연동할 때쯤에 프로젝트가 난잡해져서 결국 눈물을 머금고 setState()를 걷어내다가 모든 UI를 갈아엎었던 뼈아픈 경험을 했죠. 이번에는 상태관리의 필요성을 몸으로 느꼈던 그때를 회상하며 글을 남겨보도록 하겠습니다. 모든 개발자들에게 클라이언트단이나 프론트를 처음 접하고 가장 재미를 느꼈던 부분을 하나 고르라고 한다면 인터페이스를 통해 실제로 조작되는 순간을 많이 꼽을 것 같습니다. 픽셀로 이루어진 화면이 내가 만져서 작동을 하는 모습을 보면 그만큼 신기한 게 없기때문이죠. 이처럼 간략하게 말하자면 상태관리는 사용자와 상호작용을 통해 데이터가 변경되는 과정을 관리하는 것을 의미합..

창업 아이템이 정해지고 나서 Flutter를 학습했기 때문에 프로젝트의 모든 과정이 새로웠다. 특히 아키텍처의 도입은 볼륨이 커질수록 생각만큼 매끄럽게 적용하기 어려웠습니다. 이때 제가 겪었던 시행착오들이 다음 개발의 인사이트가 될 수 있을 거라 기대하며 실제 프로젝트의 아키텍처, 폴더 구조를 정리하는 시간을 가져보겠습니다. ❗️주의: 스스로 학습하며 구성한 프로젝트라 현직자 분들이 보시면 이상하게 느끼 실수 있습니다. "쟤는 저런 식으로 해봤구나" 정도로만 봐주시고 만약 틀린 부분을 발견하셨다면 피드백 남겨주시면 감사하겠습니다 이전에 관심사에 대해 다뤘던 글에서 나는 'Layer-First'에 기반한 아키텍처및 프로젝트 구조를 구성했었다고 말했다. 아키텍처에는 정답이 없으며 '팀의 구조를 따라간다'라는..

레포지토리 패턴으로 구성된 리버팟 아키텍처로 프로젝트를 진행하다가 크게 아키텍처 구조를 갈아엎은 적이 있었다. 이유는 어떤 특정한 기준으로 아키텍처 구조를 잡았다가 볼륨이 커지면서 레어어간의 질서를 깨뜨리는 도메인들이 등장했기 때문이었다. 개발자라면 한 번쯤 깊게 고민해 봤을 법한 주제인 거 같아 실제 프로젝트를 하면서 느꼈던 것들을 글로 남겨보려고 한다. "해당 글의 내용은 프로젝트는 레포지토리 패턴으로 구성된 리버팟 아키텍처를 배경으로 하고 있습니다. 특정 아키텍처 패턴에 종속된 주제는 아니지만 리버팟 아키텍처에 대해 배경지식이 필요하다면 아래 글을 참고해 주세요" [Flutter] Repository pattern + Riverpod feat.안드레아 로그인 회원가입 등 구현에 대해 이야기하기 ..

이전 글에선 Data-Layer와 Domain-Layer를 실제 코드와 함께 정리했었습니다. 데이터 레이어와 도메인 레이어는 대부분 api 통신에 관한 코드들로 구성되어 있었습니다. 이번 글에서는 클라이언트단의 비즈니스 로직들을 다루는 Application-Layer 부분을 다뤄보겠습니다. 제 프로젝트를 기반으로 설명하는 거라 아키텍처와 무관한 내용이 포함될 수 있습니다. ❗️주의: 스스로 학습하며 구성한 프로젝트라 현직자 분들이 보시면 이상하게 느끼 실수 있습니다. "쟤는 저런 식으로 해봤구나" 정도로만 봐주시고 만약 틀린 부분을 발견하셨다면 피드백 남겨주시면 감사하겠습니다 해당 글은 이전 글에서 계속 이어집니다. 이해가 필요하신 분은 아래의 글을 참고해 주세요! [Flutter] 실제 Reposit..