본문 바로가기

전체 글

 (117)
[Flutter] 안드로이드 appbundle에 서명되는 업로드 키를 분실했을 때 대처방안 1. 다음 명령어로 새로 키스토어를 만든다. keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias key 2. 만들어진 key.jks 파일을 /android/app 밑에 넣는다. 3. /android 밑에 key.properties 파일을 생성하고 다음을 작성한다 storePassword=[비번] keyPassword=[비번] keyAlias=key storeFile=./key.jks 4. /android/app/build.gradle의 android{} 위에 다음 내용을 추가한다. def keystoreProperties = new Properties() def keystorePropertiesFile ..
JSON Serialization 보호되어 있는 글입니다.
flutter ios app Firebase Distribution으로 배포 1. Firebase Distribution에 앱 등록 + Provisioning Profiles 등록 2. flutter 프로젝트 폴더 -> 터미널에서 flutter build ipa 실행 3. 요런 녀석이 나오면 클릭 distribute app 클릭 ad hoc 모드 선택 이렇게 export된 폴더 안에 ipa 파일이 있다. 여기에 업로드. 그리고 테스터 초대
ReadMe 파일 작성 방법 1. 프로젝트 이름 2. 컨트리뷰터 리스트(깃허브 닉네임이 좋음) 3. Tech Requirements(Tech Stack) 4. Docker(도커를 어떤 식으로 쓰고 있는지, 빌드와 관련된 것들) 5. Script(스크립트 정리를 통해 협업하는 동료들끼리 도움이 됨) npm run dev, npm run build 등
react 리액트를 사용하는 이유, 리액트에서 함수형 컴포넌트를 사용하는 이유 강력한 커뮤니티 확장성 - next.js, getsby.js 등 react-native 경쟁상대의 부재 커리어 채용문제 ---- 함수형 컴포넌트의 사용이 주류가 된 이유 원래 함수형 컴포넌트에서는 클래스 컴포넌트 생명주기(componentDidMount 등)를 사용할 수 없어서 컴포넌트가 변화된 후 리렌더링을 할 수가 없었다. 그러나 리액트 훅의 등장으로 함수형 컴포넌트에서도 이것이 가능해졌다. + 지금은 함수형 컴포넌트가 성능 면에서도 더 뛰어나다(실행되는 속도가 조금 더 빠름). hooks란? 쉽게 말하면 A라는 액션이 실행될 때 A라는 액션과 동시에 실행되는 함수를 정의하는 것이다. 또한 hooks는 기본적으로 함수로 뺄 수 있기 때문에 useEffect()에서 실행해야 하는 함수를 별도의 파일로 ..
MSA 마이크로 서비스 아키텍처, MFA 마이크로 프론트엔드 아키텍처, 모노레포 하나의 코드 베이스에 모든 것을 때려넣은 모놀리틱 아키텍처와 대비되는 개념. 모놀리틱은 구현 속도는 빠르지만 스파게트 코드가 되기 쉽다. 초기 스타트업에서 빠른 개발을 위해 모놀리틱을 사용하는 경우가 많다. MSA는 서비스를 잘게 쪼갠다. 예를 들어, 상품 서비스, 결제 서비스, 장바구니 서비스 등으로 쪼개서 각자 따로 관리한다. 하나의 서비스가 다른 서비스에 영향을 미치지 않는다는 장점이 있다. MSA를 사용할 때는 프론트와 백 사이에 API 게이트웨이를 두어서 엔드포인트를 하나로 통일할 수 있게 하는 경우가 많다. 이렇게 되면 프론트는 각각의 서버에 대해서 알 필요가 없어지고 API를 찌르기만 하면 된다. API 게이트웨이는 여러 API를 묶어주는 aggregation 역할 이외에도, 스케일링, 인증..
SSG 정적 사이트 생성 Static Site Generation SSR, CSR 모두 유저가 리퀘스트를 날린 시점마다 렌더링을 한다는 공통점이 있었다. 서버에서 렌더링을 하든 클라이언트에서 렌더링을 하든 유저가 어느 시점에 요청을 보내는지가 중요했다. 그러나 모든 콘텐츠가 유저가 요청을 보낸 시점에 렌더링이 되어야 할까? 그렇지 않다. 뉴스 기사 사이트, 상품 진열 사이트 등을 생각해보자. SSG는 사이트를 빌드하는 시점에 미리 html을 만든다. 미리 만들어 놓은 html을 유저에게 전달하는 것이다. 장점은 API 서버에 대한 부하가 훨씬 줄어들게 된다는 것이다. 규모가 큰 서비스의 경우 비용 측면에서 훨씬 절약이 된다! 정적 사이트 빌드 -> 정적인 html, css, js로 나옴 -> CDN, S3에 업로드 -> S3, ..
SSR 서버 사이드 렌더링 CSR, SSR 모두 콘텐츠를 컨텐츠를 어디서 만들어내는가에 포커싱이 맞춰져 있다. 콘텐츠를 서버에서 만들면 SSR, 클라이언트에서 만들면 CSR. SSR은 서버에서 html을 미리 만들어서 내려줌. CSR은 클라이언트에서 html을 만든다. SSR의 장점은 빠르다는 것이다. 서버는 클라이언트보다 훨씬 성능이 강력하다. 크로미움이나, 브라우저에 비하면 컴퓨팅 파워가 훨씬 강력하다. SSR을 구현하기 위해서는 Next.js나 Node.js의 템플릿 엔진 등을 사용할 수 있다. 또한 리액트로도 가능한데, React DOM(리액트와 DOM을 연결시키는 역할)의 hydrate라는 메소드를 사용하면 리액트 DOM 내에서 리액트를 랜더링 할 때 SSR 방식으로 렌더링을 시켜준다. 어차피 Next.js도 이것을 사용..

티스토리툴바