개발하는 엄무키

오늘 구현할 내용 운영하고 있는 사이트의 health 체크 모니터링을 내 노션 페이지에 연동해보기 Nextjs - Notion API 연동 준비물 vercel에 배포한 Nextjs 웹앱 노션 패키지 : @notionhq/client → nextjs에 설치 github actions 1. Notion에서 연동 설정 1. Notion Integration 생성 Step 1: Integration 만들고 API 시크릿 가져오기 https://www.notion.so/my-integrations 에 접속해서 새 API 통합을 생성한다. 생성한 API 통합에 들어가서 프라이빗 API 통합 시크릿 을 복사. → 환경변수로 사용 예정 Step 2: 데이터베이스에 Integration 연결 (필수!) Notion으로 가서 데이터베이스를 생성한다. ~ DB 예시 ( 참고용 ) 속성 타입 용도 Server Name

정리 들어가며 nestjs 강의를 통해서 nestjs에 대한 이해도와 지식을 높이기 위한 정리를 시작한다. 인수인계 받은 코드로 내가 얼마나 많은 시간을 날려먹었나 생각하면서 머리속에 뼛속에 새기련다. 1. Authentication / Authorization 비교 AUTHENTICATION AUTHRIZATION 무엇을 하는가? 자격 증명 권한을 부여하거나 허락하지 않는다. 어떻게 작동하는가? password, 생체인식, 일회용PIN, app을 통해 보안팀이 관리하는 설정을 통해 유저가 볼수 있는가? 예 아니오 유저에 의해서 변경가능한가? 부분적으로 아니오

개요 오늘은 무작정 간단한 라이브러리 등록을 해보자. Roll with the punches 다. 맞으면서 적응해보자. 0. 배포 전 npm scope 확인하기 Scope란? 패키지 이름 앞에 붙는 @이름/ 부분. 이름 충돌을 방지하는 네임스페이스 역할. 0-1. User scope = npm username username이 mookieum이면 → @mookieum/... 바로 사용 가능 0-2. Scoped 패키지는 기본이 private 무료로 공개 배포하려면 설정 필수: 0-3. scope 소유권 확인 package.json의 @scope/가 내 username과 일치하면 OK. 1. npm 계정 생성 및 확인 먼저 npm 계정을 만든다. npm | Home 터미널에서 npm 로그인 상태를 확인한다. ( 아래 명령어로 확인하기 ) 난 아무 설정도 해두지 않았기 때문에 당연히 아래와 같이 error 메세지가 나온다. npm 로그인 하기 위 명령어를 실행하면 npm 웹사이트를 통해서 인증이 이루어진다.

개요 지난 포스팅으로 Sementic Versioning에 대해서 정리하였다.MAJOR.MINOR.PATCH 규칙, ^ 와 ~ 의 차이, 버전의 각 번호가 사용자들과 어떤 약속인지 - MAJOR.MINOR.PATCH 규칙 - ^ 와 ~ 의 차이 - 버전의 각 번호가 사용자들과 어떤 약속인지 이번 포스팅에는 npm에 등록한 라이브러리에서 버전이 작성되고 관리되며 동작하도록 하기위해 설정하는 package.json에 대해서 정리 해보려고 한다. npm 라이브러리 배포 시 반드시 알아야할 필드들에 집중해서 정리할 예정이다. Package.json package.json은 단순히 의존성 목록을 적어두는 파일이 아니다. npm에 라이브러리 배포시 " 이 패키지를 어떻게 사용해야 하는지" 를 npm과 사용자에게 알려주는 명세 역할을 한다. package.json내에 필드 하나 잘못 설정하면 사용자가 import조차 못하는 상황이 생길 수 있다. 2. name , version name name : npm 레지스트리에서 패키지를 식별하는 유일한 이름이다. *scoped package : @mookie-sdk 처럼 scoped package 설정 이유 - 등록하려는 패키지의 이름이 누군가와 겹칠 수 있다. - @my-sdk/sdk 처럼 scope를 붙이면 네임스페이스가 확보된다. - 추후 개발될 라이브러리가 있거나 그룹을 만들어서 배포시에 유리하다. ( 회사나 프로젝트 브랜딩시 활용) name이 패키지를 식별하는 값이기 때문에 배포 전에 아래의 명령어로 중복 여부를 확인하자. version : 지난 포스팅에서 다룬 Semantic Versioning 규칙을 따른다. 첫 배포라면 0.1.0 부터 시작하는 것이 관례다. 1.0.0 은 이 "라이브러리는 안정적이다" 라는 선언이므로, 초기 개발 단계에서는 0.x.x 를 유지하는 것을 추천한다. 2. 진입점 설정 : main, module, types

개요 회사에서 진행하는 프로젝트의 궁극적인 목표가 SDK로 정해졌고 개발을 하면서 항상 라이브러리를 꼭 한 번 만들어서 배포하고 싶은 꿈을 가지고 있었는데 이번 기회에 npm에 라이브러리를 등록해보면서 시야를 넓혀보려고 한다. Semantic Versioning npm에 등록되어 있는 라이브러리를 보면 아래의 예시처럼 버전 번호가 붙는데 이건 전 세계 개발자들이 합의한 규칙 이다. 이걸 Semantic Versioning 이라고 부른다. 이 규칙을 지키면 사용자는 버전 번호만 보고도 "이거 업데이트해도 내 코드 안 깨지겠네" 또는 "이건 조심해야겠다"를 판단할 수 있다. PATCH (1.0.0 → 1.0.1) "고쳤어요, 쓰던 대로 쓰면 됩니다" 버그 수정 내부 로직 개선 성능 최적화 기존 API 변경 없음 이 버전 업데이트는 사용자 입장에서는 아무것도 안 바꿔도 된다. 그냥 업데이트하면 버그가 고쳐진다. MINOR (1.0.0 → 1.1.0) "새 기능 추가했어요, 기존 거 그대로 써도 됩니다" 새로운 함수/컴포넌트 추가 기존 함수에 선택적 파라미터 추가 하위 호환성 유지

들어가며 : 왜 Stack Auth인가? 인증 시스템을 직접 구현하는 것은 MVP 개발에서 가장 큰 시간 낭비 중 하나다. 비밀번호 해싱, OAuth 플로우, 세션 관리, 토큰 리프레시... 이 모든 것을 직접 제대로 구현하려면 최소 2-3주는 필요하다. ( 물론 깊이있는 이해와 보안적인 이슈를 생각하면 정말 제대로 구현하는게 맞지만 ) 이번 포스팅은 MVP 개발 프로젝트에 맞춰서 정리하고 stack auth 기반의 시스템을 이해하며 앞으로 더욱 유연한 기능 사용을 위한 시작점으로 정리하려고한다. Stack Auth를 선택한다면 가질 수 있는 이점: 오픈소스 셀프호스팅 가능 빠르게 설정 가능 Teams, RBAC, Permissions 기본 제공 Next.js App router 완벽 지원 ( but pages router 지원 X ) 1. Stack Auth 핵심 기능 1.1 인증 방식 (Authentication Methods) Stack Auth가 지원하는 인증 방식: 📧 Email/Password - 기본 인증 🔗 Magic Link - 비밀번호 없는 이메일 인증 🌐 OAuth Providers - Google, GitHub, Facebook 등 📱 OTP - 이메일/SMS 일회용 비밀번호 🔑 Passkeys - WebAuthn 기반 생체인증 🏢 SAML SSO - 엔터프라이즈 SSO 1.2 사용자 관리 (User Management) 1.3 Teams & Organizations (B2B 필수)