Исследование Node.js

Node.js

js в браузере VS js в NodeJs

)

js в браузере — это синтаксис ECMAScript + веб-API.

js в NodeJs — это синтаксис ECMAScript + Node API.

Как видно из рисунка выше, синтаксис тот же (ECMAScript), но среда другая, предоставляемый API другой и то, что можно сделать, другие. На рисунке не перечислены все API, но видно, что http (связанный со службой http) предоставляется в среде NodeJS. Вы можете позволить NodeJs написать серверную программу.

Front-end разработка vs back-end разработка

Мышление фронтенд-разработки VS мышление бэкенд-разработки

Как было сказано выше, языки программирования являются для нас препятствием для изучения NodeJ, а синтаксис ES.

Первое, что нужно изменить нашему мышлению, — это внешний интерфейс, который запрашивает данные, а затем обрабатывает результат запроса. Серверная часть принимает запросы, а затем возвращает данные в ответ на запросы.

Front-end и back-end фокусируются по-разному, а front-end фокусируется на презентации и взаимодействии. Бэкэнд фокусируется на безопасности и стабильности.

Внешний технологический стек VS внутренний технологический стек

Изучение NodeJs — это большой проект, который заключается в изучении целого набора технологий и освоении стека серверных технологий, прежде чем их можно будет использовать в работе.

Я провожу приблизительное сравнение стеков передних и внутренних технологий:

В серверной части есть некоторые технологии, которые не используются во внешнем интерфейсе, например база данных sql. Есть также некоторые технологии, которые являются общими для внешнего и внутреннего интерфейса, например файлы cookie, и серверная часть также будет обращать внимание на установленные файлы cookie и точки знаний, связанные с сеансом.

Я считаю, что по приведенной выше картинке мы можем понять, на каком уровне технологии находится NodeJs, не просто определенная технология, а Js для серверной разработки.

Прочесывание знаний NodeJs

запустить службу

После изучения NodeJ в целом и изучения деталей первым шагом будет запуск службы:

var http = require("http");

http.createServer(function(request, response) {
  // 处理一切
  // request接收请求
  // response响应请求
}).listen(8888);

Самой важной частью NodeJs является этот код, сервер получает/отвечает на запросы. NodeJs использует метод обратного вызова, где я могу справиться со всем.

маршрутизация

Просто напишите switch для обработки разных запросов.

http.createServer(function(request, response) {
  // 从request中获取请求url和method:get/post
  switch(url){
    case '/api/blog/list':
        // 返回博客列表相关代码
        break;
    case '/api/blog/new':
        // 新建博客相关代码
        break;
    ...
    case '/api/user/list':
        // 返回用户列表相关代码
        break;
    case '/api/user/new':
        // 新建用户相关代码
        break;
    ...
  }
}).listen(8888);

В проекте неразумно писать весь код обработки запросов в одном методе, поэтому его нужно разделить. Есть маршрутизация.

Мы помещаем различную обработку запросов в разные файлы, разделенные по бизнес-логике, такой как блог/пользователь:

// app.js
http.createServer(function(req, res) {
 handleBlogRouter(req, res)
 handleUserRouter(req, res)
}).listen(8888);

// router/blog.js
export default handleBlogRouter(req, res){
    ...
    switch(url){
    case '/api/blog/list':
        // 返回博客列表相关代码
        break;
    case '/api/blog/new':
        // 新建博客相关代码
        break;
    ...
  }
}

// router/user.js
export default handleBlogRouter(req, res){
    ...
    switch(url){
    case '/api/user/list':
        // 返回用户列表相关代码
        break;
    case '/api/user/new':
        // 新建用户相关代码
        break;
    ...
  }
}

Внутренняя маршрутизация концептуально отличается от внешней маршрутизации.Внешняя часть относится к переходам между страницами, а одна страница — это один маршрут. Адрес интерфейса серверной части, который относится к маршруту.

controler

Продолжаем разбивать, пусть роутер тоже несет единую ответственность, и извлекаем бизнес-логику:

// router/blog.js
const {
    getBlogList,
    newBlog,
    ...
} = require('../controler/blog')

export default handleBlogRouter(req, res){
    ...
    switch(url){
    case '/api/blog/list':
        const result = getBlogList(id);
        res.json(result);
        break;
    case '/api/blog/new':
        const result = newBlog(body);
        res.json(result);
        break;
    ...
  }
}

Здесь возвращаемые данные, такие как генерация json или html, помещаются в маршрутизатор, но бизнес-логика размещается в контроллере.

Структура проекта

Структура проекта в основном указана ниже.В случае, когда мы не используем какой-либо фреймворк, нам также необходимо разделить код.

└─bin #启动HTTP服务
    │   www.js      
├─logs #日志文件
└─src  #项目源码
    |   controler #放controler，业务逻辑
    |   model  #放model，数据模型，数据库操作
    |   router #路由相关
    |   utils #工具类文件
    |   db #数据库相关 mysql,redis等基本服务封装
    |   config #项目相关配置
├─app.js 主文件，启动文件

Показать адрес исходного кода структуры проекта

В соответствии с этой базовой структурой проекта я написал небольшой проект и загрузил его в Code Cloud.нажмите здесь, чтобы посмотреть

В проекте вы также можете увидеть мою основную обработку запроса, улучшение объекта запроса, включая получение синтаксического анализа пути, синтаксический анализ запроса, настройку файлов cookie, инкапсуляцию сеанса и инкапсуляцию после запроса. Установите объект ответа, например, установите формат возврата в JSON.

база данных

Первое, что нужно сделать, это выбрать базу данных, я выбрал mysql. Знаком с инструментами баз данных и использовать операторы sql.

  1. Установить базу данных, установить клиент визуализации базы данных
  2. nodejs подключается к базе данных, записывает код в папку db, затем записывает оператор sql в папку модели, а затем вызывает метод, инкапсулированный в модели, в контроллере.

куки, сессия, редис

Эти три точки знания связаны между собой. Все дело в хранении состояния.

HTTP не имеет состояния. Для записи состояния необходимо использовать файлы cookie. Для записи более защищенной информации на стороне сервера требуется сеанс. Чтобы лучше использовать память на стороне сервера и повысить стабильность, необходима база данных Redis в памяти.

Наиболее типичным приложением является запись статуса входа в систему. Используйте файл cookie для записи ключа, используйте сеанс для хранения конфиденциальной информации пользователя или сохраните сеанс в Redis.

файловые операции

Серверу нужны файловые операции, а при обнаружении больших файлов ему также необходимо использовать потоковые операции.

Наиболее типичным приложением является работа с журналом.

Безопасность

Незаменимой частью контента на стороне сервера является контент безопасности, размещения xss-атак, sql-инъекций и т. д.

express

Поняв все аспекты разработки на стороне сервера, вы можете приступить к работе с фреймворком, который в настоящее время широко используется.

var express = require('express');
var app = express();

app.get('/', function (req, res) {
    res.send('Hello World!');
});

app.listen(3000, function () {
    console.log('Example app listening on port 3000!');
});

Можно использовать скаффолдинг, такой как экспресс-генератор, и интегрировать такие модули, как сгенерированные проекты и журналы маршрутизации.

npm install -g express-generator

Использование промежуточного программного обеспечения

Основным механизмом фреймворка является механизм подключаемых модулей. Когда приходит запрос, плагин обрабатывает его и передает следующему плагину, после обработки он передается следующему, обрабатывается один за другим, и, наконец, плагин, отвечающий за бизнес вернет результат ответа.

Это разделяет обязанности. Пусть каждый плагин относится к одной задаче. И это прогрессивно.Например, связанный метод работы с файлами cookie, инкапсулированный предыдущим плагином, следующий плагин может получить соответствующий метод в объекте запроса для обработки бизнеса.

koa2

Узнав об экспрессе, легко начать работу с Koa. В отличие от экспресса, во-первых, добавлена ​​​​асинхронность, а во-вторых, механизм подключаемых модулей стал луковой моделью.

app.use(async (ctx, next) => {
    await next();
    var data = await doReadFile();
    ctx.response.type = 'text/plain';
    ctx.response.body = data;
});

Основной механизм плагина не изменился, а также было достигнуто разделение различных обязанностей по обработке запроса.

koa2 также имеет соответствующие леса

npm install -g koa-generator

обратный прокси nginx

Так как на нашем сервере развернуты и front-end, и back-end, то необходим обратный прокси для выделения, какие из которых запрашивают front-end ресурсы, а какие запрашивают back-end ресурсы.

заключительные замечания

Я просто знакомлюсь с Node, и эта статья — только общее введение в общую разработку NodeJ. Если вы хотите хорошо изучить nodeJ, вам все еще нужно много реальных боев и освоить некоторые концепции и технологии серверной разработки. Поймите его рабочий механизм и принцип на практике.

Категории