웹 사이트 프로젝트(Web Site Project)와 웹 응용프로그램 프로젝트(Web Application Project)의 차이

혹시 알고 넘어가는지 모르겠지만, 닷넷에서 웹 앱을 만드는 데 2가지 프로젝트 형식이 있다.
바로 웹 사이트 프로젝트와 웹 앱 프로젝트인데, 이 둘의 차이점은 간단하게 짚어보는 시간을 갖겠다.

웹 사이트 프로젝트(Web Site Project)

타 언어 웹 사이트로 치자면, ASP, PHP, 일반 JSP 페이지를 만드는 꼴이라고 보면 된다. VS 2005부터 소개되었다.
폴더 루트를 잡고, 거기에 페이지와 리소스, 백엔드 코드를 특정 폴더인 App_Code 에 넣는 방식이다.
프로젝트 생성이 빠르고, 단순하다. 그리고 프로젝트 파일도 생성하지 않는다. 그럼 구성 설정은 어디다가 저장하냐?
바로 솔루션 파일과 구성 설정 파일인 web.config에다 저장한다. 각기 역할은 당연히 틀리고 대부분 설정은 web.config에다 저장한다.
개발만 하고 폴더 그대로 IIS에 배포할 수 있다. 사이트 설정만 하면 작동을 시작한다. 나머진 IIS가 파싱하여,
각 페이지마다 변경 사항이 생길 때마다 컴파일 후, 각기 페이지마다 DLL 파일이 생성되어 페이지를 렌더링 한다.
그렇기 때문에 빠른 배포와 수정이 장점으로 통한다. 하지만 이런 특성이 단점으로 작용하는데,
이렇게 될 경우 각 페이지 내에서 클래스 네임 중복을 확인하지 않는다, IIS는 그걸 인식하지 않고 파일마다 컴파일 하기 때문에,
클래스 이름이 중복되더라도 다른 이름으로 클래스를 생성 후 컴파일하기 때문에 참조 등에서 어떤 문제가 나올 지 파악이 어렵다.
이런 불상사를 예방하기 위해 “게시” 기능이 있다. 게시할 때 “미리 컴파일(Precompiled)” 개념이 있으며, 최적화하고 정리하여 깔끔한 백엔드와 성능을 보장받을 수 있다.

이럴 때 웹 사이트를 쓰면 좋다. 프로토타입, 시연, 데모, 단순한 소개 사이트.

웹 응용프로그램 프로젝트(Web Application Project)

웹 앱을 아예 응용 프로그램처럼 프로그램 단위로 관리하고 운영하는 프로젝트로, VS2005 SP1부터 내장되었으며, 이런 개념은 이미 VS 2003부터 도입이 되었다.
폴더 루트에 .csproj.vbproj 등의 프로젝트 파일이 생기며, 프론트엔드 코드와 백엔드 코드를 아무 곳이나 넣을 수 있으며, 예외 설정 등이 가능하여
관리적 측면에서 아주 유리한 프로젝트이다. 왠만한 구성 설정은 프로젝트 파일에 저장하기 때문에 web.config 파일엔 서버 운영에 필수적인 구성 설정밖에 없는 것도 장점이다.
단점이라면, 매 수정시마다 빌드(컴파일)해줘야 하고, 당연히 컴파일된 상태로 배포를 해야 한다. 물론 아예 “게시”하여 배포할 수 있다.
빌드 후에는 모든 백엔드 코드가 하나의 DLL에 담게 된다. 배포 방식이야 웹 사이트처럼 폴더째로 담으면 땡이지만, 백엔드 코드를 DLL에서 바로 불러오기 때문에 성능 측면에서 이득이다.
또한 게시 기능을 통해 웹 사이트처럼 모든 페이지의 백엔드 코드까지 퉁쳐서 하나의 DLL로 담은 후 배포할 수 있기 때문에,
성능과 안정성 측면에서 당연히 가장 추천되는 웹 앱 프로젝트 방식이다.

이럴 때 웹 응용 프로그램을 쓰면 좋다. 웹 사이트에서 소개한 거 빼고 전부 다. 모든 서비스들 말이야.

결론?

참고로 ASP.NET Core 프로젝트는 웹 사이트 프로젝트가 아직 없다. 웹 앱 프로젝트 방식이다. ASP.NET 팀에서는 ASP.NET Core Web Pages 으로 만들고 있다.
닷넷 코어는 IIS 종속이 아니기 때문에 어떤 방식으로 배포하고 운영할 지는 모르겠으나, 어자피 정식 웹 앱을 만드는 데에는 웹 앱 프로젝트 만큼 관리가 좋은 건 없으니 그거 쓰자.
어자피 WebMatrix는 VS Code가 그 뒤를 계승 이미 끝났으니 신경 끄고.

composite / 2017년 8월 30일 / Piss Development / 0 Comments

node.js 이전 추억이 되버린 자바스크립트 서버단…

1. Classic ASP

ASP에 자스 지원하는거 아는사람이 얼마나 있을까? ASP 개발자들 대부분 비베 썼을텐데.

하지만 자바스크립트 또한 지원했다. 윈도우 스크립팅 엔진에 비베와 자바스크립트 둘 다 들어가 있다보니.

물론 그때당시 Javascript 란 단어가 상표권이 있어서 JScript 라고 명명하긴 했지만 요즘은 좆망 엔진.

지금 자스 말고 마소에 내장된 자스 엔진 말하는거다. 자스 개발자인 내가 왜 자스를 욕하나?

일단 자바스크립트만 알면 접근성이 용이하다는게 장점이고, C언어처럼의 코딩 스타일로도 제격이다.

예를 들어보자.

<%

Dim myVar

myVar = “내가 니 앱이다.”

Response.Write myVar

%>

추억 새록새록하지 않는가? 아.. 지금도 ASP 쓰는데 있지. 아무래도 기존 프로젝트가 있다보니.

지금도 ASP로 HTML5 라던가 DB 접근성은 별 달라진 거 없이 그냥 쓰면 된다. 확장성이 개같은거만 빼고는.

그리고 요즘 많이 사용하는 JSON도 쓸 수 있으며, JSON2.js 를 ASP 스크립트에 그대로 첨부하여 JSON.stringify 같이 직렬화 병렬화도 지원되 Ajax 기술 쓰는데 지장이 없을 정도로 꽤나 강력하다.

<%

var myVar = “내가 니 앱이다.”;

Response.Write(myVar);

%>

하지만 아무래도 불편해서 잘 안쓰는 이유가 바로.. 대소문자 구분이다. 비베에 익숙한 ASP 개발자라면.

예를 들면, 비베는 이렇게 해도 동작한다.

response.write “뭐”

RESPONSE.WRITE “왜”

ReSpOnSe.WrItE “어”

하지만 자스는 대소문자를 가리기 때문에 당연히 지켜야 하며, 모든 API는 카멜케이스로 대문자부터 시작한다.

Response.Write(“뭐”);

이렇게 안된다.

response.write(“왜”); //오류남.

또한 ASP API 가 비베에 맞춰져 있다 보니 자스를 어떻게 잘 쓰기도 불편할 것이다.

지랄, 노력하면 ASP 를 js 코딩하는데 존나 편하다. Ajax 할때 자스 짱짱맨이다. 실제 2009년 모업체 고객불편센터 프로젝트에 그렇게 썼고 Ajax 기술을 아무렇지도 않게 잘 소화해냈다. DB가 오라클인건 비밀.

아, 유지보수는 이게 시발 이딴 코딩이 다있냐며 나 존나 욕하겠지만 ㅋ

2. Jaxer

Ajax 기술이 뜨면서 Web 2.0 이 아주 질리도록 듣는 시절, 웹표준 지키는 코딩은 개발자들 사이에서 단연 이슈였다.

물론 어자피 IE만 쓰니 IE 중심 코딩 하라는 나이 똥꾸먹으로 쳐먹은 개발자도 있긴 하다.

그 중에 Aptana. 신개념 웹 환경에 목마른 개발자라면 알 것이다. 마의 자바스크립트 IDE 아니던가? 그것도 유료 프로그램..

그들이 내놓은 서버단 솔루션을 개발했는데. 이름하여 Jaxer. 서버단 자바스크립트 되겠다.

 이녀석이 쓰는 거 좀 재밌다. 하이브리드고, Javascript 다.

<script runat=”server”>

//..서버단 자스. 클라이언트에서는 안보임

</script>

<script>

//..클아이언트단 자스

</script>

<script runat=”both”>

//..서버도 인식하고 클라이언트에서도 돌아가도록 남김.

</script>

따라서 jQuery 를 서버와 클라이언트단 동시에 돌리는 위엄을 토한다.

<script type=”text/javascript” src=”jquery.js” runat=”both”></script>

<script>

$(function(){

    $(‘#hello’).html(‘world’);

});

</script>

<script runat=”server”>

$.each(dbFetch, function(){

    // fetch data…

});

</script>

하지만 기대는 컸으나 실망이 더 컸다. 나도 이거 쓰려다 말았고, 못해먹겠다.

그 이유는…

  1. 아파치 종속모듈. 뭐.. 그건 이해하지만 제약이 꽤나 많았다.

  2. JSP의 스크립틀릿 같은 개념이 없다. <%=myVar%> 클래식 개발자에겐 낮은 접근성. (그렇다고 확장성도 별로..)

  3. API가 독자적이면서 많고, 어려우며 동기적이다.

<

p>

큰 단점 : 버그 존나 많고 성능 개같고.. 낮은 접근성까지.

node.js 반만 닮아갔어도 아마 명맥을 유지할 지도 모른다.

그리고 Jaxer 는 더이상 명맥을 유지하지 못하고 어느 네크로맨서 개발자가 다시 부활시켜 Github 에 오픈소스로 고이 모셔뒀다.

그리고 Aptana 는 자바스크립트로 네이티브 앱을 만드는 솔루션을 가진 Titanium 에 흡수되어 Titanium Studio 를 개발중에 있다.

그리고 Aptana 는 아예 오픈소스로 무료로 공개했지만, 지금도 기능은 막강하다. 자바 개발자에겐 웹개발에 신세계를 줄 것이다.

왜냐? 이클립스 플러그인으로도 깔 수 있으니까. 기회되면 한번 깔아보고 해봐. 이렇게될거야.

composite / 2014년 1월 2일 / 미분류 / 0 Comments

AppHarbor 로 .NET Application 테스트/서비스하기

아오 썅 AppHarbor 쓰는 한국인들 없나? 닷넷이 이렇게 죽었어? 엉? 구글 검색으로도 안나와 어떻게 된게.

그래서 내가 열받아서 쓴다. 참고로 AppHarbor 는 웹 어플리케이션 및 백그라운드 어플리케이션 (걍 콘솔)을 지원한다.

여기서는 웹 어플리케이션을 만들고, 올리고, 보여주는 식으로 강좌를 올리겠다.

AppHarborHeroku 의 .NET 버전이라고 보면 된다고 한다. (어느 외쿡님이)

AppHarbor 는 PaaS 서비스로, 어플리케이션을 올려서 서비스 한다고 보면 되며, 야는 .NET 만 지원한다.

.NET 버전은 csproj 파일에 있는 버전으로 알아채기 때문에 버전이 어떤 거든 상관은 없는데 최신 기술인 4.5 도 지원된다고 한다.

일단 .NET 클라우드 플랫폼에서 웹 서비스만 할거라면.. 무료다. 표를 통해 확인해봅세.

구분 

Azure 웹 무료

 AppHarbor 무료

 앱 개수

사이트 10개

제한 없음

 사이트 개수

 1

1

 저장소 용량

1GB (사이트 공유 총용량)

딱히 없는듯

 트래픽 제한

 일 165MB

월 100GB (작은 Worker) 

 사용자 지정 도메인

지원 안함

추가 요금 (제한없이 10$/월)

 SSL

지원 안함

기본 SSL 지원, 개별 별도 요금

 DB

MSSQL 전용 20MB 제공

 확장을 통해 무료 MSSQL 공유 20MB

MySQL 및 MongoDB도 있음.

 협업

불가능 (웹 게시 방식)

Git 를 통해 가능

 비고

 90일 무료 체험 가입해야함

그냥 가입하고 쓰면 됨

구분 

Azure 웹 서비스 표준

AppHarbor CATAMARAN

월 가격 (최소 인프라)

75$

49$

사이트 개수

100

1

 인스턴스 개수

 10

2

 사용자 지정 도메인

 지원

지원

 SSL

 별도 추가 요금

지원

 DB

 마찬가지이며 추가시 별도과금

마찬가지이며 추가시 별도과금

 협업

 불가 (웹 게시 방식)

Git 를 통해 가능

 저장소

10GB (사이트 공유 총용량)

 제한 없음

요금제 분석

 작은 여러 사이트 운영시 유리한 요금

큰 단일 사이트 운영시 유리한 요금

딱히 놓고 보면 AppHarbor 가 가격 면에서 비싸보인다. (솔직히 비싼것 같다.) 하지만 무료 환경이 좋다. 그래서 소개하는 것이다.

유료 요금제 분석 내가 가격과 스펙을 봤을 때 아무래도 이렇게 쓸 때 좋겠다는 주관적 입장일 뿐이며, 자세한 사항은 직접 가서 비교하기 바란다.

AppHarbor 는 Worker Scale 에 자세한 스펙을 표시하지 않았다. 그래서 한번 찾아봤더니 다음과 같이 나온다.

One worker is currently limited to roughly 50% of an AWS Elastic
Compute Unit (ECU) which is equivalent to 500-600 MHz. The worker
is allowed to consume up to 512MB of RAM (soft limit) and there’s a
1GB hard RAM limit. You might also want to check out the limits
section of our program policy which
specifies other limits of interest.

Limits

AppHarbor has soft and hard limits for the use of its services. Hard
limits are automatically enforced and soft limits are consumable
resources that you agree not to exceed.

  • Network Bandwidth per Worker Unit: 100GB/month – Soft
  • Shared DB processing: Max 200msec per second CPU time – Soft
  • Request timeout: 30 seconds – Soft; 120 seconds – Hard
  • RAM usage per Worker Unit: 512 MB – Hard (if you only have a single
    worker unit per worker the limit is: 512MB – Soft; 1024MB – Hard).
    Workers are restarted/recycled when exceeding this value).
  • CPU resources per Worker Unit: ~600MHz – Hard
  • Requests Queue limit per Worker Unit: 500 Requests – Hard

Worker 하나당 500MHz, 반기가헤르츠의 처리 속도와 512기가의 RAM을 제공받는다고 보면 된다. (물론 기본 Worker 당 스케일 늘리면 당연히 늘어나겠지만)

그리고 트래픽 100기가, 공유 DB의 경우 처리 속도가 200밀리초 미만, 최대 요청 시간 30포, 500개의 요청 대기를 지원한다.

그리고 RAM 의 경우 허용 크기를 넘어버리면 Worker 가 다시 시작된다. 사이트를 다시 시작한다는 뜻이다. 그렇게 되면 세션같은 메모리에 적재된 데이터는 날라간다. 무분별하게 메모리 내에 객체를 담는 것은 지양해야 할 것이다.

하지만 이정도 사양이면 사이트 테스트및 개인 연습 사이트 운영 등에 지장이 없다. 대국민 서비스는 젭알.

자. 이제 AppHarbor 로 어플리케이션을 어떻게 배포하는지 알려주도록 하겠다.

필자는 Nancy 로 만든 ASP.NET 웹 프로젝트를 만들었다. ASP.NET MVC 써도 되고 걍 ASP.NET 써도 되고

여의치 않는 사용자는 WebMatrix 로 만든 웹 사이트도 가능하다.

비주얼 스튜디오에서 웹개발 하는 사람이라면 알겠지만, 폴더 단위 프로젝트가 웹 사이트며, WebMatrix 는 웹 사이트 프로젝트만 지원하기 때문에 sln 파일이 따로 없다. 없어도 된다. 그래서 AppHarbor 에 올릴 때 솔루션 파일 (sln)이 없으면 웹 사이트 프로젝트로 취급되어 빌드되고 실행된다.

프로젝트 개수에 상관없이 sln 파일이 있고, 그 하위에 프로젝트 있는 구조로 올리면 된다.

어떤 프로젝트는 sln 이 별도 폴더에 있고 실제 프로젝트는 다른 경로에 있는데 그렇게 하면 잘못 판단하여 빌드 안되므로 유의.

즉, 이렇게 하라는 거다. 올바른 앱 폴더 구조는 다음과 같다.

AppHarbor_Test (앱 최상위 폴더)

└ Project1 (클래스 라이브러리 폴더)

└ ASPNETMVC (웹 프로젝트 폴더)

└ MyApp.sln (솔루션 파일)

또는

AppHarbor_Test (앱 최상위 폴더)

└ App_Data (폴더)

└ Index.aspx (페이지 파일)

└ Global.asax (웹 설정)

└ MyClass.cs (임의 클래스)

└ Web.config (웹 설정)

└ MyApp.csproj (프로젝트 파일)

└ MyApp.sln (솔루션 파일)

아래와 같은 앱 폴더 구조는 올바르지 않다. (웹사이트로 인식되어 올바르게 사이트 뜨지 않는다)

AppHarbor_Test (앱 최상위 폴더)

└ Sln (솔루션 폴더)

    └ MyApp.sln (솔루션 파일)

└ Project1 (클래스 라이브러리 폴더)

└ ASPNETMVC (웹 프로젝트 폴더)

<

p>

이렇게 해서 프로젝트를 만들거나, 기존 웹 되는 프로젝트를 먼저 준비한다.

그리고 아래 프로그램이 있어야 한다.

  • Git for Windows (Github for Windows 는 Github 연동일 때만 해당) (필수)
  • TortoiseGit 또는 Git Extensions (마우스 클릭으로 하고 싶으면 설치, 콘솔로 하겠다면 비설치)
  • Git Source Control Provider for VS2012 (있으면 편하고 없어도 무방)

Git 쓰는 방법은 귀찮아서 패스. 구글 검색하면 흔하디 흔하게 나온다.

AppHarbor 가입하는 방법은 간단하다. 메인 페이지에서 GET STARTED NOT 버튼을 클릭하여 이메일, 아이디, 비번 세가지만 쓰면 된다. 그럼 인증메일이 오는데 인증메일 링크를 클릭하고 로긴하면 가입절차가 끝난다.

그러면 Create New Application 나오는데, 원하는 이름을 입력하고, 서버 위치 선택 후 만들면 된다.

서버 위치가 미국, 유럽, 미국베타가 있는데 걍 미국 선택 후 만든다.

그런 다음, 왼쪽 메뉴 하단에 REPOSITORY URL 버튼이 보일 것이다. 클릭하면 URL이 복사된다.

Git 원격 URL을 복사된 URL로 쓰면 된다.

특이한 점은 비밀키 생성된 파일을 요구하지 않고, 비밀번호만 요구할 것이다. 원체 윈도우다 보니 HTTPS 프로토콜만 제공하나보다. 물론 비밀키파일 생성하고 원격에 등록하면 매번 비번 입력하는 귀차니즘 없이 쓸 수는 있는데.. 안타깝소.

그리고 메뉴에 Hostnames 가보면 생성된 URL이 뜨는데 이게 당신이 만든 웹 사이트를 접근할 URL 이다.

안타깝게도 사용자 지정 도메인은 유료이기 때문에 운영할 맘이 없다면 그냥 기본 제공 도메인을 쓰도록 한다.

다음으로, DB를 쓰도록 하자. AppHarbor 사이트 위에 대메뉴에서 Add-ons 가면 되는데, MySQL, PostgreSQL, MSSQL 등의 SQL DB가 지원되고, MongoDB, Redis, CouchDB 등의 No-SQL 디스크 기반 또는 메모리 DB를 사용할 수 있다.

무료 플랜도 찾아보면 나오며, 테스트로 쓸수 있고, 경우에 따라 원격 접속도 가능하여 확인도 가능하다.

MSSQL 쓰려면 맨 아래로 스크롤 이동하면 나오는데, Yocto 가 무료다. 공유된 SQL 환경에서 20MB 무료로 제공한다.

주저없이 테스트 해주자. 당신의 컴터에 매니지먼트 스튜디오 등의 DB 클라이언트 있으면 거기서도 접속 가능하므로 참고.

composite / 2013년 10월 7일 / 미분류 / 2 Comments