없으면 없는대로

BaaS 개요 및 현황

+ BaaS란?

    - 모바일 어플리케이션에 특화된 클라우드 서비스

    - 서버사이드 개발 능력 없이도 손쉽게 Backend를 구축

    - 모바일 생태계와 밀접한 관련이 있음

    - '11년 태동된 따끈한 서비스 사업

+ BaaS를 사용하지 않으면(즉, 서버사이드를 직접 개발하면),

    - 서버사이드 SW 개발에 막대한 비용 소요

    - 운영 인프라 확보에 막대한 비용 소요

    - 운영 라이선스 확보에도 막대한(?) 비용 소요

    - Time to Market 보장 못함

+ BaaS 서비스 종류

    - 데이터 저장

    - Push Notification

    - Social 통합

    - 사용자관리/권한제어

    - Rating

    - 인증

    - Location

    - Billing 

    - 사진 저장 및 공유

    - 기타등등...

+ BaaS 사용자들이 선호하는 서비스 순위

    - 1위 Location Service(35%), 2위 Notification(33%), 3위 Rating(11%)

+ BaaS의 목표

    - 서버코드를 작성 않고도 클라이언트가 서버 API를 호출하여 필요한 Backend 서비스를 이용

    - 모바일 어플리케이션의 개발 효율 제고

+ BaaS의 기능이 확장되면서 PaaS와 경계가 모호해지는 경향이 존재함

    - 커스텀 API 생성 지원

    - Java, Ruby, Python, Lua 등을 통한 Biz로직 커스터마이징 지원

+ 관련 업체

    - Appcelerator : Titianium 개발업체, 최근 BaaS 업체인 Cocoafish를 인수함

    - Parse : 공개 베타 종료, 정식 서비스 오픈함

    - 기타 StackMob, Kinvey, Apple iCloud, RhoMobile 등

    - 현재(2012년 04월 기준), BaaS 참여업체는 최소 20개

+ BaaS 제공업자가 고민해야 할 점

    - 클라우드를 통한 확장성(Scaling), 높은 가사용성(Availability)

    - Backend 데이터 보안(Security), 신뢰성(Reliability)

    - 서비스 재사용성(Reusability of Services)

        - 서비스가 특정 App과 tightly coupled되지 않게 주의해야 함

        - 그래야 App 개발 생산성을 보장할 수 있음

+ BaaS 사용자가 고민해야 할 점

    - 벤더 안정성

        - 벤더가 갑자기 가격정책을 변경하면?

        - 벤더가 갑자기 없어지면?

+ BaaS 가격 정책 예시(API 호출 횟수에 따라 과금)

    - free tier: 500,000 calls/month 까지 free

    - paid tier: 500,000 calls/month 이후, 

        - 매 1000 calls 당 $0.2

        - 10 million calls/month 당 $249

        - 매 1000 calls 당 $0.15

    - enterprise tier: 비밀?

Reference

BaaS(Backend as a Service) 에 대하여

http://www.mimul.com/pebble/default/2012/05/05/1336192251452.html

The Rise of Mobile Cloud Services: BaaS Startups Grow Up

http://www.readwriteweb.com/mobile/2012/04/mobile-backend-as-a-service-ec.php

StackMob: The Complete Technology Stack for Mobile Apps

http://www.readwriteweb.com/mobile/2011/01/StackMob-the-complete-technology-stack-for-mobile-apps.php

Open Source Mobile Backend as a Service

http://apievangelist.com/2012/08/28/open-source-mobile-backend-as-a-service/

Mobile Backend as a Service Roundup and the Future of Web APIs

http://developerthinktank.com/roundtable/mobile-backend-as-a-service-roundup-and-the-future-of-web-apis/

Appcelerator, Cocoafish 홈

http://cocoafish.com

Buddy Announces Pricing!

http://us2.campaign-archive2.com/?u=89af861528a693bdec7af3af7&id=5ae7773b1a

HTML5 Device API 표준화 현황 (2012년 10월 19일 기준)

출처: http://www.w3.org/2009/dap/

W3C의 표준화 단계는 WD -> LC -> CR -> PR -> Rec

- WD: Working Draft

- LC: Last Call

- CR: Candidate Recomendation

- PR: Proposed Recomendation

- Rec: Recomendation

스펙별 진행상태

+ Battery Status API, 08 May 2012, CR

+ HTML Media Capture, 12 Jul 2012, LC

- Web App에서의 사진찍기, 녹음하기 방식 규정

+ Media Capture and Streams, 28 June 2012, WD

- media stream 접근 API 규정

+ Network Information API, 7 June 2011, WD

+ Ambient Light Events, 2 August 2012, WD

+ Proximity Events, 12 Jul 2012, WD

+ Vibration API, 08 May 2012, CR

+ Web Intents, 26 June 2012, WD

- Web App 사이의 상호 발견 및 RPC 방식 규정

+ Web Intents Addendum Local Services, 04 Oct 2012, WD

- Web Intent를 통해 브라우저가 Web Intent Service를 발견하고  통신하는 방법 규정

+ Pick Media Intent, 12 July 2012, WD

- Web App에서 사용자의 미디어 갤러리 접근 방식 규정

+ Pick Contacts Intent, 12 Jul 2012, WD

- Web App에서 사용자의 연락처 정보 접근 방식 규정

+ Network Service Discovery, 04 Oct 2012, WD

- 네트웍 상에 공개된 서비스를 발견하는 프로토콜 규정

+ Menu API, 진행상황 없음

+ Permissions for Device API Access, 5 Oct 2010, WD

총 14개의 HTML5 Device API 표준 중 LC이상이 3개, WD이하가 11개.

- Battery Status API, 08 May 2012, CR

- HTML Media Capture, 12 Jul 2012, LC

- Vibration API, 08 May 2012, CR

- Media Capture and Streams, 28 June 2012, WD

- Network Information API, 7 June 2011, WD

- Ambient Light Events, 2 August 2012, WD

- Proximity Events, 12 Jul 2012, WD

- Web Intents, 26 June 2012, WD

- Web Intents Addendum Local Services, 04 Oct 2012, WD

- Pick Media Intent, 12 July 2012, WD

- Pick Contacts Intent, 12 Jul 2012, WD

- Network Service Discovery, 04 Oct 2012, WD

- Menu API, 진행상황 없음

- Permissions for Device API Access, 5 Oct 2010, WD

아직 갈 길이 멀다. 브라우저에서 모든 일을 할 수 있는 세상이 빨리 오길...

(이상)

Modern Javascript WebApp 동향

+ SPA : Single Page Application

- 하나의 HTML 파일(Single Page)에 여러 화면을 담아 제공

- 화면이 바뀔 때마다 새로운 HTML 파일을 읽어들일 필요가 없어지기 때문에 응답성이 개선됨

- WebApp의 현재 상태/화면을 hash-url(한 HTML 페이지 안의 위치를 나타내기 위해 사용하는 #으로 시작되는 http://some.domain.com/some-page.html#some-location 과 같은 형태의 URL)로 관리

- hash-url을 이용하여 WebApp의 상태/화면 관리하는 개념을 Routing이라고 하고, hash-url을 해석해서 WebApp의 상태/화면을 관리하는 모듈을 Router라고 함

+ Off-line enabled WebApp

- HTML5의 off-line 지원 기능을 활용, 네트웍에 연결되어 있지 않아도 로컬에 캐시된 WebApp 코드를 이용해서 WebApp을 실행

- Off-line enabled WebApp이 되려면 서버의 도움 없이 실행될 수 있도록 모든 프로그램 로직이 front-end에 존재해야 함

+ BaaS : Back-end as a Service

- WebApp의 front-end에 모든 로직을 담고 정형화된 back-end를 RESTful API 형태로 제공하는 개념

- Back-end가 제공하는 데이터를 가공하는 모든 로직은 front-end에 존재해야 함

=> SPA, Offline enabled Web App, BaaS 등 Modern JS WebApp은 기본적으로 규모가 큰 front-end 코드를 요구함

=> front-end code의 규모가 커짐에 따라 소스코드의 유지/보수 비용을 절감하기 위해 MVC 패턴을 이용해서 WebApp 코드를 구조적으로 만들 필요가 생김

MVC 디자인 패턴

+ 디자인 패턴이란?

- 재사용 가능한 소프트웨어 디자인(설계)

- 검증된 문제 해결 방식

- 필요에 따라 유연하게 적용 가능

+ MVC 패턴이란?

- Model, View, Controller로 소프트웨어 구조를 나눔

- Model은 데이터를 표현

- View는 화면(보통 아무런 로직도 없음)을 표현

- Controller는 M과 V 사이의 조율, 비즈니스 로직을 처리

- 전통적으로 서버-사이드에서 많이 사용됨

MVC를 지원하는 Javascript f/w 종류

+ JavaScriptMVC

- 완성도 높은 성숙한 기술

- all-in-one 솔루션

- 대규모 프로젝트에 적합

- GrooveShark(미국의 음원 제공 서비스)에 적용됨

+ Backbone.js

- 경량

- SPA 제작에 최적

- 다른 컴포넌트와 함께 사용하기 좋음

- MetaLab, SoundCloud, BitTorrent 등에 적용됨

+ Spine.js

- 경량

- Class 개념 제공

- Backbone API에 기초하여 Backbone 개발자라면 추가 학습 비용이 낮음

+ Sammy.js

- Route 기반 앱 개발에 적합한 경량 프레임워크

- Controller만 제공 (M과 V를 제공하지 않음)

- PaperlessPost에 적용됨

+ SproutCore

- 데스크탑 어플 같은 Rich함을 지향하는 앱 개발에 적합

- 대규모 엔터프라이즈 앱 개발에 적합

- 애플 MobileMe에 적용됨

Reference

- MVC and the Web

http://kanian77.wordpress.com/category/software-engineering/mvc/mvc-and-the-web/page/3/

- Tools For jQuery Application Architecture (Extended Slides)

http://addyosmani.com/toolsforjqueryapparchitecture/

- 자바스크립트 웹어플리케이션 개발경험기

http://blog.outsider.ne.kr/787

- Digesting JavaScript MVC ? Pattern Abuse Or Evolution?

http://addyosmani.com/blog/digesting-javascript-mvc-pattern-abuse-or-evolution/

- Scaling Isomorphic Javascript Code

http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

- MVC Architecture for JavaScript Applications

http://michaux.ca/articles/mvc-architecture-for-javascript-applications

자바스크립트(Javascript) 모듈화

배경

- Web App 로직의 비중이 서버에서 클라이언트로 이동하면서 클라이언트 코드가 거대화, 엔터프라이즈화 됨

- 클라이언트 Web App 개발 언어는 자바스크립트(이하 JS)

- JS를 본격적인 프로그래밍 랭귀지로 사용하려면 모듈화가 선결조건

- 모듈화의 중요성 

==> 유지보수의 간편함

- 시스템이 독립적인 모듈로 느슨하게 결합되어 있어야 관리하기 쉽다

- 어느 한 부분을 수정해도 전체 시스템에 영향을 주지 않는다

히스토리

- JS 모듈 관리를 위한 코딩 표준을 정의하려는 노력이 있었음(CommonJS와 AMD)

- CommonJS

- JS의 활용성을 높이려는 자발적 워킹그룹

- JS를 범용 프로그래밍 언어로 만드는 것이 목적

- 2009년 1월 Kevin Dangoor가 SSJS(서버-사이드 자바스크립트)에 대한 아이디어를 제시하고 사람들을 모으기 시작

- JS 모듈 관리에 관한 코딩 표준을 제시함

- AMD(Asynchronouse Module Definition)

- 브라우저에서의 JS 모듈 활용성을 높일 목적으로 CommonJS에서 파생됨

- AMD는 CommonJS와 interoperable

- jQuery를 비롯 다수의 오픈소스 솔루션이 AMD를 지지

- jQuery의 경우, 1.7부터 AMD 모듈 등록 기능을 지원하기 시작

- CommonJS와 마찬가지로 JS 모듈 관리에 관한 코딩 표준을 제시함

- RequierJS

- AMD 표준을 준수하는 가장 인기 있는 JS Loader

- 기존 JS 로딩의 문제(<script> 태그를 이용 JS 파일을 로딩할 경우...)

- 로딩이 시퀀셜하게 진행

- JS 파일간 dependency가 없을 경우 시퀀셜하게 로딩하는 것은 시간 낭비

- JS 파일간 dependency가 있을 경우 개발자가 script 태그 배열 순서를 신경 써야 함

- RequireJS를 비롯한 asynchronous loader의 역할

- JS를 비롯한 모든 리소스를 가능한 병렬로 로딩

- JS 파일간 dependency를 JS Loader가 지능적으로 관리

전망, 결론

- CommonJS, AMD가 해결하려는 문제의 핵심은 모듈화

- 모듈화는 JS가 보다 범용적인 언어로 자리매김하는 단초가 될 것

- 모듈화는 JS framework(이후 f/w) 패러다임이 변화하는 토대가 될 것

- 지금까지는 모든 것을 해결하는 다목적 f/w가 주류

- 글로벌 네임스페이스를 차지하는 대형 f/w은 다른 JS 코드와 충돌하기 쉽다

- 특정 영역에 집중하는 작은 모듈이 관리하기 쉽다

- 이제부터는 필요한 기능별로 f/w 모듈을 로드하여 사용하는 시대

- 특히 크기가 중요한 모바일 환경에서 중요성 증대

- HTML5가 지원되는 스마트폰 환경에서 활용사례 증가 예상(로컬 스토리지를 통해 모듈 로딩 성능 향상 가능)

솔직히 말해서, 

Subversion 이후로 새로운 버전 관리 툴이 필요할 거라는 생각을 하지 않았다. 그래서 Git(깃)이 세상에 나왔을 때 나는 분노했다. 뭣하러? 새로운 톨이 나오고, 사람들이 열광하고, 아쉬울 것 없던 내가 Git을 배우게 된 걸까?

하지만, Git에 대해 요모조모 알고난 지금, 난 누구에게도 자신있게 Git을 권할 수 있다. 이제 Subversion과 Git 중에 하나 고르라고 하면 Git을 추천한다.

GitHub

- SourceForge와 Google Code를 빠르게 앞서고 있는 오픈소스 프로젝트 근거지

- 단순한 소스 호스팅 뿐 아니라 개발자들끼리의 SNS로 기능하고 있음

- Subversion (SVN)을 오픈소스 호스팅 기반으로 사용하는 SourceForge와 달리 Git을 소스 호스팅 도구로 사용

- 코드 생산자가 아니라 소비자로 활동하기에도 좋다

Git

- Git은 2006년경 BitKeeper라는 리눅스 커널 개발에 쓰던 분산형 패치 도구에 대한 대안으로 리누스 토발즈가 직접 개발한 분산형 소스 콘트롤(Source Control Management) 시스템

- Offline으로 동작 가능하며 거의 모든 기능의 반응 속도가 기존 버전 관리 툴을 압도 (Why Git is Better than X 참고)

- GitHub를 쓰기 위해 Git을 사용하는 사람이 늘고 있음 (GitHub가 활성화 되었음을 의미)

참고자료

- Github, 코드 개발 기반 소셜 네트웍 (http://channy.creation.net/blog/626)

- 웹 항해일지 - GitHub 특집 (http://occamsrazr.net/tt/254)

- The Git 슬라이드 (http://www.slideshare.net/dalinaum/the-git)

- Why Git is Better than X (http://whygitisbetterthanx.com/)

- Git 사용기 (http://help.github.com/be-social/)

- Pro Git (http://dogfeet.github.com/articles/2012/progit.html) 

: 이 책, "Pro Git"은 꼭 읽어야 한다. Git에 대한 완벽한 안내서. 무려 한글! 내용 충실! 책을 이렇게 공개하면 종이책이 팔리지 않을텐데... 저자가 고마우면서도 걱정되는 복잡한 기분.

(이상)