일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 네이티브
- Route53
- 페이스북
- AWS
- react
- 알려줌
- Elastic Beanstalk
- angular
- beanstalk
- ios
- nextjs
- 웹뷰
- node.js
- node
- 안드로이드
- JavaScript
- TypeScript
- Android
- angular4
- fanzeel
- hybrid
- cors
- 도메인
- https
- NeXT
- S3
- 카카오톡
- swift
- 감사일기
- php
- Today
- Total
쪼렙 as! 풀스택
[개발후기 - WEB] Angular4를 사용하여 FindBM.com 웹페이지 개발하기. 본문
프로젝트 참여.
백엔드 (서버) - 100%
프론트 (Angular) - 50%
0. 개요
- 로아컨설팅과 함께 만든, 기업용 콘텐츠 (B2B) 를 보여주는 웹 사이트
- 기업용 계정 관리
- 유튜브 영상 플레이, PDF 보고서 보기, Audio 청취.
1. AWS 사용.
- Elastic Beanstalk 로 서버를 구성했다. 로드밸런서와 오토스케일링을 자동으로 세팅해주니 무지하게 편하다.
- CertificateManager 으로 아마존에서 제공하는 HTTPS 인증서를 무료로 사용할 수 있는데, 이것은 또 로드밸런서에만 사용이 가능하다. 로드밸런서도 손쉽게 구성해주니, 더욱 Elastic Beanstalk 를 사용하게 된다.
- Elastic Beanstalk 에 Database Tier 도 구성해 줄 수 있긴 하지만, 이미 회사에서 사용중인 RDS 가 있기 때문에, 따로 RDS 인스턴스를 돌리지 않는다. (RDS 비싸 ㅠㅠ) 그래서 기존 RDS에 접근하여 사용할 수 있도록 Security Group을 직접 설정해 줘야 했다.
- 블럭스토리지를 따로 사용하지 않는다. FindBM 에는 사용자가 파일을 업로드 할 일이 없기 때문에, 따로 파일관리가 딱히 필요하지 않는다. 하지만, Angular 소스나, 홈페이지에 필요한 이미지들은 S3 로 처리하기 위해서 S3 에 CloudFront 붙여서 사용했다.
2. Angular4 의 사용.
- 본인은 여태껏 아이폰, 안드로이드 네이티브 앱 개발을 주로 해왔기 때문에, 웹개발 경험은 한참 부족하다. API 서버 개발이야 앱 개발을 하면서 많이 해왔는데, 내가 해본 웹 개발이래 봤자, 앱 서비스를 운영하기 위한 '어드민 페이지' 뿐 이였다. (심지어 JAVASCRIPT를 단 한 줄도 쓰지 않고 만든 어드민 페이지도 있다!!)
- 데이터 통신해서 데이터 가져오고, 라우팅 잡아주는 등의 전체적인 구조, 틀은 내가 만들고, 퍼블리싱은 다른 사람이 했다.
- 처음엔 Angular2 로 개발을 시작했는데, 중간에 Angular4 로 판올림 되었다. 그래서 자연스럽게 Angular4 까지 가게 되었다.
- Angular를 처음 사용해 봤는데, 앱 개발을 주로 하던 나에게도 매우 익숙한 방식의 개발이여서 너무 좋았다. MVC 패턴이 잘 녹아져 있고, 특히 컴포넌트 단위의 개발은, 정말 효율적이고 관리도 편하고 좋았다.
- Angular2 에서부터는 TypeScript 로 개발하게 되어있는데, 이것도 너무 좋았다. 주로 Java 와 Objective-C, Swift 로 네이티브앱을 주로 개발해 왔기 때문에, 타입이 명확한 언어가 훨씬 더 개발할 때 안정감이 느껴진다. 게다가 Visual Studio Code 로 개발을 하기 시작했는데, TypeScript 가 지원이 아주 잘되서, 디버그도 편하다. 기본인 자바스크립트도 익숙하지 않은채로, 처음부터 TypeScript 를 사용하게 된다는게, 썩 좋은것 같지는 않지만, 여튼 내 개인 취향으론 TypeScript 가 역시 더 좋다.
- 처음에는 Angular 홈페이지에 있는 'quick-start'를 이용해서 개발을 했는데, 중간에 Angular - CLI 로 프로젝트를 만들어서 개발하게 되었다. Angular-CLI 를 통해서 'Product 모드'로 빌드를 하게 되면, Javascript 가 minified 되서 결과물이 나온다. 이게 또 너무 좋다. 빌드된 JS파일의 용량이 줄어들 뿐 아니라, 아무래도 minified 되면, 어느정도 소스 난독화가 되기도 하는 것이니, 굉장히 맘에 들었다.
3. S3 을 이용한 서버리스 구성.
- 처음에는 서버비용을 줄이고자, S3의 static web hosting 기능을 이용하여, 서버리스로 구성했었다. 물론 API 서버가 따로 필요하지만, 기존에 사용하고 있는 서버를 사용하면 되기 때문이다. 이렇게 해서 서버비용도 줄이고 아주 좋다고 생각했다.
- 이게 가능한 이유는 Angular 가 완벽하게 Client 렌더링 방식으로 동작하기 때문인데, 이 말은 그냥 index.html 파일과 Angular 를 동작하게 하는 JavaScript 파일만 다운로드 된다면, 사용자의 브라우저에서 모든 화면이 렌더링 된단 얘기이다. 물론 API 서버는 별개의 문제이지만... 아... 이거 참 설명하기 어렵다. 전통적인 방식으로 웹을 개발하던 사람에겐 이게 참 어려운 이야기일 수도 있겠다. 여튼, 데이터와 화면을 완벽하게 분리하고, 화면(템플릿)은 완벽하게 클라이언트단(브라우저)에서 처리 되기 때문에 서버리스가 가능하다.
4. 서버리스 구성의 단점.
- 서버에서 라우팅을 처리하는 과정이 전혀 없기 때문에, 무조건적으로 #URL (Hash URL) 을 사용해야한다. 예를 들어서, "https://findbm.com/#/bm/Voysis" 이런식으로 무조건 중간에 "#"이 들어가야만 한다.
- 페이지마다 <head> 태그와 <meta> 를 동적으로 입력할 수 가 없다! 이 말은 즉... SEO 최적화에 쥐약이며, 페이스북공유나 카카오톡 공유의 '미리보기' 기능이 제대로 동작하지 못한다는 뜻이다.
5. 결국 서버를 사용하기로 결정.
- 서버를 사용하여 HashURL 문제를 해결하고, 검색최적화 및 공유의 '미리보기'기능을 위해서는 전통적으로 페이지마다 <head>와 <meta> 데이터를 동적으로 응답해줘야 한다.
- Angular 로 다 개발한 프론트단은 그대로 사용하기 위해서, 전통적인 방식 + Angular 를 섞었다.
- 서버를 요청하면, <head><meta>값을 동적으로 응답 + <body> 부분에는 Angular 소스를 그대로 다운로드 받게 해줌.
- SEO 를 위한 몸부림.
6. Angular 를 사용한 소감.
- 개발생산성은 정말 좋다.
- SEO 와 '공유'가 중요한 미디어 같은 '정보'가 중요한 사이트에는 어울리지 않아보인다.
- 특정 '기능'이 중요한 웹앱 (어드민 페이지같은...) 에는 정말 잘 어울린다.
- TypeScript 맘에 든다. 개발환경 Visual Studio Code 도 좋다.
'포트폴리오 & 개발후기' 카테고리의 다른 글
[개발 후기] FANZEEL.COM - 통합매거진 (0) | 2018.03.13 |
---|---|
[개발후기 - WEB] FANZEEL.COM - 서브도메인을 활용한, 콘텐츠별 미니 홈페이지 퍼블리싱 시스템 (0) | 2017.09.14 |
[개발후기 - iOS, Android] 투이톡 (2E 아카데미) 앱 (0) | 2017.06.15 |
[개발후기 - iOS, Android] 줄거리 알려줌 앱 (0) | 2017.06.10 |
[개발후기 - iOS, Android] IT 알려줌 앱 (0) | 2017.06.05 |