기본 콘텐츠로 건너뛰기

NodeJS: In Three(ish) Minutes.

NodeJS: In Three(ish) Minutes.

NodeJS: In Three(ish) Minutes.

3분 만에 NodeJS 파해치기 :)

This is a new format I'm considering trying, so let me know if you like it.

내가 이제 새로운 방식으로 글을 써보려고해. 맘에 들면 말 해줘.

I'm going to take a topic, probably always a technology, and explain it as concisely and clearly as possible in 3 minutes.

앞으로 간결, 깔끔하게 3분 내로 읽을 수 있도록 한 주제에 대해 얘기해볼꺼야. (아마도 항상 기술분야가 되겠지만..)

To begin I'll choose the focal technology of my recent article, NodeJS. So let's begin!

첫 시작은 나의 최근 글들의 중심 기술인 NodeJS다. 시작할겡 :)

NodeJS was created in 2009 by Ryan Dahl.

Ryan Dahl이 NodeJS를 2009년에 만들었어.

Prior to NodeJS, Dahl had been working as a developer using Ruby on Rails.

NodeJS 나오기 전에, Ryan은 Ruby on Rails를 사용하는 개발자였지.

He got the base concept for NodeJS while using Flickr (an image uploading and sharing website), and he noticed that there was a progress bar, that told him the status of his image uploading.

Ryan은 Flickr(이미지를 업로드하고 공유하는 웹사이트[https://www.flickr.com/])를 사용하면서 NodeJS에 대한 기본 개념을 생각해냈고, 이미지가 업로드 되는 상태를 나타내는 progress bar가 있다는걸 알았지.

It seems almost a fickle feature now, but back in the late 00s, that kind of server-always-talking behaviour was new and rare.

지금은 그게 아주 변덕스러워 보이지만, 2000년 후반 server-always-talking 종류의 방식은 새로운 것이었고 귀했지.

This was the case because back then, servers didn't really have the ability necessary to process multiple things at once, such as uploading a file and also handling other requests from the same user, an idea known as concurrency.

그 당시에, 서버는 한 번에 여러 항목을 process할 수 있는 능력이 없었어. 예를 들어, 한 사용자 보낸 요청을 처리하면서 파일을 업로드할 경우 말야. concurrency에 대한 개념이지.

Seeing this interaction between browser and server sparked something in Dahl.

Ryan은 browser하고 server가 상호작용 하는걸 보면서 영감을 받았어.

He realised that a web server needs to be able to process multiple things at the same time.

Ryan은 web server는 여러 항목을 동시에 처리 할 수 있어야 한다는 걸 깨달은거지.

The old method of get a request/send a response was outdated and ill fitting.

get a request(요청을 받는 것)과 send a response(응답을 전송하는 것) 은 오래된 방법은 시대에 뒤쳐지고 부적절했지.

I don't know about you but that doesn't make a tremendous amount of sense to me, so let me explain it further with a diagram

너도 그런지는 모르겠지만 나는 이게 이해가 잘 안돼. 그래서 그림을 통해 한번 봐보자 :)

A request comes in, in this case it's a request to upload a file.

파일을 업로드하는 요청이 들어왔다 생각해보자.

The server accepts that request, and while it is processing that request (the thick dark line to the right) it handles other requests, before finally returning a response to the main request.

server가 요청을 수락하고 처리하는 동안(맨 오른쪽에 두꺼운 까만줄), 가장 중심적인 request를 응답하기 전에 다른 요청들을 처리 하는거지.

This is the concept of concurrency at the root of NodeJS.

이게 바로 NodeJS에서 근간이 되는 concurrency에 대한 개념이야.

It was built by Dahl and co in Javascript using a wonderful implementation of technology, in the form of Google's V8 engine.

이 concurrency에 대한 개념은 Ryan과 공동으로 Google의 V8엔진 형태의 멋진 Javascript기술로 만들어졌어.

This engine takes Javascript code, and compiles it into C++, which executes at lightning speeds.

Google's V8 엔진은 Javascript code를 받아서, 겁나 빠르게 실행 할 수 있는 C++로 compile 하지.

V8 does this on the fly, and compiles quickly upon execution.

V8 엔진은 이를 즉시 수행하며, 실행 시 컴파일 되지.

This is partly what gives NodeJS it's edge when it comes to speed compared to other programming languages and frameworks.

이게 바로 NodeJS가 부분적으로 다른 프로그래밍 언어나 프레임워크랑 속도 면에서 비교 했을때 장점이 있는 이유야.

NodeJS wasn't back then, and still isn't, a web server by default.

NodeJS는 기본적으로 웹서버가 아니였고 지금도 아니야.

When you get NodeJS out of the box, it doesn't just start a web server.

너가 NodeJS를 딱 시작하면, 이건 뭐 웹서버를 시작하지도 않지.

Developers have to utilise either frameworks, or write the logic directly on top of NodeJS, to make it into a web server.

개발자들이 NodeJS에서 프레임워크를 활용하거나 코드를 작성해야만 web server를 만들 수 있어.

So why isn't NodeJS just a web server by default, if that's why it was invented?

그렇다면 왜 NodeJS는 기본적으로 웹서버가 아닐까? 왜 NodeJS는 만들어 졌을까?

It's because NodeJS was built to address an issue greater than just the problem of multiple requests to a website, it was built to address the idea of multiple requests and of processing multiple things at once.

NodeJS는 웹사이트의 여러개의 requests를 처리하는 문제보다 더 큰 문제를 해결하기 위해 만들어졌기 때문이야.

여러 request를 처리하고 동시에 여러 항목을 process하기 위해 개발 된거지.

That's part of the reason for the popularity of NodeJS, because it can do a lot more than just web servers.

그게 바로 NodeJS가 인기를 얻은 이유중 하나지. NodeJS는 web server보다도 더 다양한 것들을 할 수 있거든.

NodeJS is used for the aforementioned web servers, but also as an operating system, a logging tool (to record say, http requests, or user generated behaviour in a desktop application), a general scripting language, and I have personally used it for developing neural networks and machine learning.

NodeJS는 앞서 말한 web servers로도 사용되지만 또한, 운영체제, logging tool(녹음, http requests, 데스크탑 프로그램의 유저행동 기록), general scripting(자동 작업)으로도 사용이 돼.

그리고 나는 개인적으로 NodeJS를 신경망 네트워크나 machine learning(기계 학습)에 사용 해오고 있지.

But because it is by far most commonly used for web servers, I'm focusing on that aspect the most.

그러나 지금까지 NodeJS가 대부분 웹서버로 사용되고 있어서, 나도 웹서버 쪽에 집중하고 있어.

Anyway let's jump ahead to NodeJS in 2018.

어쨌든 2018년 NodeJS로 넘어가자.

It is now most commonly used for developing Backends.

이제 NodeJS는 Backends를 개발 할 때, 완전 핫하지.

Backend meaning the part of the website you don't see; all the logic that makes a website work.

Backend란 website내에서 너가 보지 못하는 부분을 의미해; website가 작동하도록 하는 모든 logic들 말야.

It is however also commonly coupled with the major Frontend frameworks, the part that you do see and interact with, to make what's called a Full-Stack environment.

또한, 주요한 frontend(유저가 website내에서 볼 수 있는 부분) 프레임워크들과 결합되어서 Full-Stack 환경을 만들지.

These include Angular, Vue, and React, to name the most popular frameworks.

Frontend 프레임워크들 중 요즘 가장 핫한 건 Angular, Vue 그리고 React야.

I can go more into this full-stack development topic in another article.

내가 나중에 full-stack development에 대해선 다른 글로 좀더 자세히 설명해 줄게.

NodeJS comes with a resource called NPM bundled into it.

NodeJS는 NPM이라고 불리는 resource가 번들로 제공이 돼.

NPM allows the developer to manage packages, which are useful Javascript functions, and to add them to any NodeJS project.

NPM은 개발자가 packages(유용한 Javascript 함수)를 관리하고, 어느 NodeJS 프로젝트에도 넣어 사용할 수 있게 해주지.

Using packages speeds up development and allows the developer to abstract away a lot of the nitty gritty development, allowing for faster code iterations.

packages를 사용해서 개발 속도를 빠르게 하고 껄끄러운 개발사항이나 코드반복을 처리 할수 있게 해줘

So let's summarize.

자, 요약해보자 :)

NodeJS is a Javascript framework, built in Google's V8 engine, and it was built to serve the need of processing multiple requests at once.

NodeJS는 Google의 V8 engine안에서 만들어진 Javascript 프레임워크야. 그리고, 여러개의 requests를 한번에 처리하기 위해 만들어졌지.

It does this very well, and has become one of the most popular frameworks for developing websites because of it.

그걸 아주 잘하기에 웹사이트 개발에 가장 인기있는 프레임워크가 됐지.

And finally, developers can use the built-in NPM to add other Javascript frameworks and libraries, to speed up their own development.

마지막으로, 개발자들은 NodeJS에 장착된 NPM(필요한 프레임워크나 라이브러리를 추가 할 수 있는 패키지 관리 툴)을 사용해 개발을 겁나 빨리 할 수 있어.

So that's NodeJS very quickly! I hope you enjoyed.

NodeJS를 빠르게 설명해봤어. 너가 즐거웠기를 바래.

출처: https://medium.com/@kieranmaher13/nodejs-in-three-ish-minutes-4c4401b43b2c

Ps. 첫 번역이라 틀린게 있어도 양해부탁드려요 :)

from http://menuand.tistory.com/3 by ccl(A)

댓글

이 블로그의 인기 게시물

카카오 오픈빌더와 외부 API 연동(feat.Nodejs)

카카오 오픈빌더와 외부 API 연동(feat.Nodejs) 이전에 플러스 친구와 외부 API 연동에 관한 글을 작성한 적 있습니다. 하지만 지난 2년동안 플러스 친구에 많은 변화가 생겼는데요. 카카오 플러스 친구의 명칭이 카카오 채널로 바뀌고, 챗봇 세팅 방식이 기존 [카카오 플러스 친구 - 외부 API 연동] 구조에서 오픈빌더가 추가되어 [카카오 채널(구 플러스 친구) - 카카오 i 오픈빌더 - 외부 API 연동] 구조로 바뀌었습니다. 이번 글에서는 오픈빌더의 챗봇 시나리오 관리 기능을 간단히 소개하고 외부 API를 연동하는 예제를 다뤄보겠습니다. (연동파트는 5번 항목부터 보시면 됩니다.) 1. 블록 블록은 오픈빌더에서 질의/응답을 관리하는 최소 단위로, 사용자의 발화와 챗봇의 대답을 입력할 수 있습니다. 예를들어 인사라는 블록을 만들고 인사에 해당하는 사용자 발화 패턴들을 입력해두면, 실제 채널 톡방에서 그에 해당하는 발화가 들어왔을때 입력해둔 응답이 나오는 형식입니다. 예전에는 패턴과 발화 키워드가 1:1 매칭, 즉 입력해둔 패턴과 사용자 발화의 string이 정확히 일치할때만 블록이 실행됐었는데, 발화 패턴을 20개 이상 등록하면 머신러닝 기능을 이용할 수 있도록 기능이 생겼습니다. 아마 유사도 분석 개념이 기본으로 들어가있을 것이기 때문에 블록의 주제와 벗어나는 너무 뜬금없는 발화패턴들을 많이 넣지 않도록 하는걸 권장하겠습니다. 2. 시나리오 시나리오는 '블록'들을 묶어서 관리할 수 있는 단위로, 일종의 폴더 구조라고 생각하면 쉽습니다. 오픈빌더에서 좌측 상단에 파란 버튼을 클릭하여 시나리오를 생성할 수 있습니다. 하나의 시나리오에서 모든 블록을 관리하면 챗봇 도메인이 커질수록 관리가 어려워지니 아래 같은식으로 시나리오를 사용하여 블록을 구조화하면 운영 측면에서 수월해집니다. 3. 컨텍스트 컨텍스트는 맥락이라는 뜻 입니다. 오픈빌더에 존재하는 컨텍스트는 자연어 분석을 통해서 맥...

20.03.24 ShareBook TIL

20.03.24 ShareBook TIL Project/TIL 20.03.24 ShareBook TIL 중간 배포를 위해 EC2, RDS를 다시 설정하였다. EC2에 git에서 clone을 하고 서버를 작동시켜보니 ts로 돌려서 그런지 작동하지 않고 대기 상태로 있다가 timeout같은 시간 초과 에러가 났다. 그리고 갑자기 EC2 자체가 느려져서 nodejs를 삭제하고 다시 nvm으로 높은 버전의 node를 설치하였다. 그리고 나서 혹시 js로 돌리면 될까 해서 tsc로 js로 변환한뒤 돌려보니 RDS와 연결이 되지 않는 에러가 생겼다. workbench로 RDS를 연결했을 때는 정상적으로 작동해서 EC2에서 잘 못 설정한게 있다고 생각했다. 그래서 local에서 한번 config.json을 수정하고 연결하여도 똑같은 에러가 발생했다. 그럼 보안 설정에서 문제인가 싶어서 EC2, RDS 보안 그룹에서 설정을 막 만져보다 RDS에서 Custom TCP에 처음 RDS에서 설정한 포트를 넣어주었더니 연결되었다. config.json내용을 EC2에도 똑같이 적용시켜보려고 json파일을 vim으로 작성해서 넣어 주었지만 여전히 같은 에러를 반복하였다. 그럼 json 파일을 못 읽어내는게 아닌가 싶어서 그냥 module에 index.js에서 sequelize를 생성하는 부분에 직접 넣어 주었더니 마침내 연결이 되었다. 해결하고 난 뒤 생각의 흐름을 적어보니 매우 짧지만 정작 오늘 아침 10시 반부터 시작해서 저녁 10시 반까지 12시간을 고민하고나서야 해결되었다. from http://three-five.tistory.com/46 by ccl(A) rewrite - 2020-03-25 00:54:05

AWS instance로 Nodejs 구현하기

AWS instance로 Nodejs 구현하기 서버와 데이터베이스 관리 차원에서 효율적으로 관리하기 위해선 로컬보다는 서버를 호스팅해서 하는 것이 좋다. 우리는 Nodejs를 구동하기 위해 AWS에서 인스턴스를 할당받을 계획이다. 인스턴스의 pem키를 발급받아 nodejs와 npm까지는 설치를 완료한 상태이다. $ sudo npm install -g express 다음의 명령어를 입력하면 글로벌 옵션으로 어느 path에서든 express를 사용할 수 있게 설치한다. 다음과 같이 실행이 된다면 성공이다. 이후 Express generator를 설치한다. $ sudo npm install -g express-generator@4 버전은 4.x이며 이 역시 글로벌 옵션으로 설치해 준다. 이제 Node monitoring을 위해 nodemon을 설치해 준다. $ sudo npm install -g nodemon 모든 설치가 끝났다. 이제 nodejs를 실행시킬 프로젝트용 directory를 만든다. 이렇게 만들어 주고 express를 실행시키면 된다. $ express -e 다음과 같은 결과가 나오면 된다. 이제 node package를 설치하는 명령어를 입력하자. $ sudo npm install 이제 vi를 통해 포트번호를 정의해보자. app.set의 마지막에 한줄을 추가하면 된다. app.set('port', process.env.PORT || 9000); 이로써 우리는 9000번 포트를 사용하게 되었다. 또한 마지막줄에 서버를 생성하기 위한 코드를 작성하자. module.exports = app; var server = app.listen(app.get('port'), function() { console.log('Express server listening on port ' + server.address().port); }); 이...