1
00:00:03,879 --> 00:00:07,577
Позвольте мне начать с краткого 10-минутного знакомства

2
00:00:07,577 --> 00:00:11,705
с основными основами сетевого взаимодействия.

3
00:00:11,705 --> 00:00:18,769
Чем больше я преподаю английский язык, тем больше я понимаю, что просто для использования своих самых красивых особенностей

4
00:00:18,769 --> 00:00:23,210
углового, вам нужно иметь понимание так много различных связанных FINs

5
00:00:23,210 --> 00:00:27,165
, прежде чем вы сможете даже понять, что вы делаете с угловым.

6
00:00:27,165 --> 00:00:29,929
К моменту, когда вы начнете преследовать каждый из этих FINS,

7
00:00:29,929 --> 00:00:32,890
они станут целыми курсами самостоятельно и довольно скоро,

8
00:00:32,890 --> 00:00:37,539
я в конечном итоге преподаю всю свою учебную программу компьютерных наук вам.

9
00:00:37,539 --> 00:00:41,174
Но учитывая тот факт, что у нас есть ограниченное время,

10
00:00:41,174 --> 00:00:43,554
я сосредоточусь на предоставлении вам основных

11
00:00:43,554 --> 00:00:48,344
, которые вам нужны для понимания каждой из тем.

12
00:00:48,344 --> 00:00:53,383
Теперь, то, что мы рассматриваем в этом конкретном модуле, потребует

13
00:00:53,383 --> 00:00:57,829
хотя бы элементарного понимания того, как работает компьютерная сеть

14
00:00:57,829 --> 00:01:01,310
, прежде чем мы поймем, почему нам нужно использовать HTTP,

15
00:01:01,310 --> 00:01:03,587
, почему мы общаемся с сервером.

16
00:01:03,587 --> 00:01:08,284
Причина задержки заключается в том, что когда вы разговариваете с сервером,

17
00:01:08,284 --> 00:01:09,394
и так далее.

18
00:01:09,394 --> 00:01:14,111
А также различные протоколы, которые вам нужно знать

19
00:01:14,111 --> 00:01:17,420
, прежде чем вы сможете даже общаться с сервером.

20
00:01:17,420 --> 00:01:20,239
Итак, имея все это в виду,

21
00:01:20,239 --> 00:01:25,950
10-минутная краткая знакомство с основными положениями нетворкинга.

22
00:01:25,950 --> 00:01:30,575
Мы начинаем понимать, что веб-приложения больше не являются автономными.

23
00:01:30,575 --> 00:01:38,015
У них всегда есть конец цитаты облачной серверной части, поддерживающей ваше веб-приложение.

24
00:01:38,015 --> 00:01:40,370
Теперь, в эти дни все находится в облаке.

25
00:01:40,370 --> 00:01:46,444
Довольно скоро вы тоже будете на облаке, по крайней мере, на облаке девять с серебряной подкладкой.

26
00:01:46,444 --> 00:01:55,939
Но учитывая, что нам нужна поддержка Silverside для нашего углового приложения, чтобы работать правильно,

27
00:01:55,939 --> 00:01:58,615
там бы вы разместили сервер.

28
00:01:58,615 --> 00:02:06,140
И в наши дни хостинг сервера очень легко сделать с помощью одного

29
00:02:06,140 --> 00:02:09,619
облачных инфраструктурных сервисов.

30
00:02:09,619 --> 00:02:15,860
Такие вещи, как Amazon, Web Services, Heroku или Digital Ocean

31
00:02:15,860 --> 00:02:21,650
или многие другие, которые обеспечивают поддержку облачных серверов

32
00:02:21,650 --> 00:02:26,574
, которую вы можете использовать для обеспечения поддержки серверов для вашего углового приложения.

33
00:02:26,574 --> 00:02:32,363
Итак, на стороне сервера, что именно доступно на стороне сервера?

34
00:02:32,363 --> 00:02:39,814
Обычно у вас есть интерфейс сервера, который разговаривает с вашим угловым приложением.

35
00:02:39,814 --> 00:02:45,349
Итак, это логика сервера и за кулисами,

36
00:02:45,349 --> 00:02:52,790
логика сервера взаимодействует с постоянным хранилищем, таким как база данных

37
00:02:52,790 --> 00:02:56,905
, где ваши данные хранятся и извлекаются.

38
00:02:56,905 --> 00:03:01,069
Когда вы войдете в мир нетворкинга, вы скоро будете бомбардированы

39
00:03:01,069 --> 00:03:04,264
с 304 маленькими аббревиатурами.

40
00:03:04,264 --> 00:03:08,930
Вещи, которые вы думали, что знаете, что они из обычного английского

41
00:03:08,930 --> 00:03:11,509
или они имеют совершенно другое значение

42
00:03:11,509 --> 00:03:15,610
или цели, когда вы сталкиваетесь с ними в мире сетей.

43
00:03:15,610 --> 00:03:17,764
Итак, давайте рассмотрим несколько из них.

44
00:03:17,764 --> 00:03:22,159
Итак, в мире сетей вы услышите, как люди говорят по протоколу HTTP.

45
00:03:22,159 --> 00:03:26,379
Протокол, используемый для связи между клиентом и сервером.

46
00:03:26,379 --> 00:03:29,000
Это протокол уровня приложения

47
00:03:29,000 --> 00:03:34,409
, о котором мы кратко расскажем немного больше в остальной части этой лекции.

48
00:03:34,409 --> 00:03:41,004
Протокол HTTP для его работы нуждается в URL-адресе,

49
00:03:41,004 --> 00:03:42,955
Единый локатор ресурсов.

50
00:03:42,955 --> 00:03:51,095
Итак, это строка символов, разделенных косой чертой с каждым двоеточием TTP,

51
00:03:51,095 --> 00:03:55,694
на https: прикрепленный перед ним.

52
00:03:55,694 --> 00:03:58,530
И я уверен, что если вы используете всемирную паутину,

53
00:03:58,530 --> 00:04:02,655
вы довольно знакомы с тем, как выглядят URL-адреса.

54
00:04:02,655 --> 00:04:06,435
Теперь, кроме того, вы услышите, как люди говорят о JSON,

55
00:04:06,435 --> 00:04:11,607
не к вашему другу Джейсону, а к JavaScript Object Notation.

56
00:04:11,607 --> 00:04:19,026
Таким образом, нотация объектов JavaScript является одним из способов кодирования данных, которые отправляются

57
00:04:19,026 --> 00:04:22,850
со стороны сервера на сторону клиента или наоборот.

58
00:04:22,850 --> 00:04:26,038
А также вы услышите людей, говорящих о XML,

59
00:04:26,038 --> 00:04:30,574
еще одном способе кодирования данных, пока он находится в транзитной отправке

60
00:04:30,574 --> 00:04:33,240
между клиентом и сервером сайта.

61
00:04:33,240 --> 00:04:41,584
Теперь, а также вы услышите людей, говорящих о протоколах более высокого уровня, называемых SOAP,

62
00:04:41,584 --> 00:04:46,550
не тот вид, с которым вы принимаете душ, но SOAP как протокол

63
00:04:46,550 --> 00:04:55,034
, который позволяет общаться между объектами распределения внутри сети.

64
00:04:55,034 --> 00:04:59,449
А также вы услышите, как люди говорят о REST, а не о чем-то

65
00:04:59,449 --> 00:05:02,479
, что вы получаете слишком много пройти через этот конкретный курс.

66
00:05:02,479 --> 00:05:06,057
REST или передача представительного состояния.

67
00:05:06,057 --> 00:05:10,850
У меня будет более короткая лекция специально посвящена

68
00:05:10,850 --> 00:05:14,089
REST немного позже в этом модуле.

69
00:05:14,089 --> 00:05:18,410
И в мире HTTP вы услышите, как люди говорят о GET,

70
00:05:18,410 --> 00:05:23,449
PUT, POST и DELETE, и вам будет интересно,

71
00:05:23,449 --> 00:05:25,235
, что они все означают?

72
00:05:25,235 --> 00:05:29,454
Давайте узнаем немного об этом в этой лекции

73
00:05:29,454 --> 00:05:34,459
, а также лекцию на REST, которую вы увидите немного позже.

74
00:05:34,459 --> 00:05:38,959
Одна важная вещь, которую вы должны понять, когда вы общаетесь

75
00:05:38,959 --> 00:05:45,439
с сервером заключается в том, что связь клиентского сервера вызывает неожиданное количество задержек

76
00:05:45,439 --> 00:05:48,350
или неопределенное количество задержки

77
00:05:48,350 --> 00:05:54,454
в то время как данные либо извлекаются, либо загружаются на сервер со стороны клиента.

78
00:05:54,454 --> 00:05:57,566
Итак, что означает, что в вашем клиент-серверном приложении

79
00:05:57,566 --> 00:06:00,409
вам нужно держать пользователя в курсе того факта

80
00:06:00,409 --> 00:06:07,970
, что что-то происходит за кулисами и уметь справляться с задержками

81
00:06:07,970 --> 00:06:14,149
и, возможно, не в состоянии получить данные со стороны сервера.

82
00:06:14,149 --> 00:06:18,589
Вполне возможно, что при попытке подключиться к серверу

83
00:06:18,589 --> 00:06:20,959
соединение с сервером может завершиться неудачей,

84
00:06:20,959 --> 00:06:27,224
сервер может вернуть неверные данные или может вызвать ошибку в общении.

85
00:06:27,224 --> 00:06:31,129
Все это должно обрабатываться на стороне клиента соответствующим образом, чтобы

86
00:06:31,129 --> 00:06:37,259
, что ваше приложение все равно будет работать даже при наличии этих проблем.

87
00:06:37,259 --> 00:06:43,939
Переход в самый популярный протокол уровня приложений, используемый для связи

88
00:06:43,939 --> 00:06:48,569
между клиентом и сервером, протокол передачи гипертекста

89
00:06:48,569 --> 00:06:51,785
, но это протокол связи клиентского сервера.

90
00:06:51,785 --> 00:06:54,019
Теперь, это может иметь или не иметь большого смысла для вас

91
00:06:54,019 --> 00:06:58,250
, если у вас нет достаточного фона в сети, но это протокол

92
00:06:58,250 --> 00:07:04,189
, который используется для кодирования сообщений, которые вы обмениваетесь между вашим клиентским приложением,

93
00:07:04,189 --> 00:07:08,416
, которое в этом случае является угловым приложением, и серверной стороной.

94
00:07:08,416 --> 00:07:14,300
Таким образом, этот протокол HTTP позволяет извлекать документы на основе гипертекста

95
00:07:14,300 --> 00:07:19,459
со стороны сервера все чаще информация, загружаемая

96
00:07:19,459 --> 00:07:25,298
со стороны сервера, кодируется в одном из стандартных форматов кодирования, таких как JSON или XML.

97
00:07:25,298 --> 00:07:28,759
И, для того, чтобы иметь возможность говорить с сервером,

98
00:07:28,759 --> 00:07:35,270
у вас есть поддержка различных HTTP-действий,

99
00:07:35,270 --> 00:07:39,295
или то, что мы называем HTTP-глаголами: HEAD, GET, POST,

100
00:07:39,295 --> 00:07:44,634
PUT, DELETE, TRACE, OPTIONS и CONNECT.

101
00:07:44,634 --> 00:07:51,069
Мы увидим, в частности, глаголы GET, PUT, POST и DELETE более подробно

102
00:07:51,069 --> 00:07:57,654
, когда мы рассмотрим остальной протокол API немного позже.

103
00:07:57,654 --> 00:08:00,904
Как работает протокол HTTP?

104
00:08:00,904 --> 00:08:08,487
В протоколе HTTP вы отправляете запрос от вашего клиентского приложения на сервер

105
00:08:08,487 --> 00:08:12,990
и это кодируется в виде сообщения HTTP-запроса.

106
00:08:12,990 --> 00:08:18,767
Сообщение запроса обычно содержит URL-адрес в сообщении запроса, указывающий,

107
00:08:18,767 --> 00:08:22,279
, что это такое, что вы хотите с серверной стороны отправить вам

108
00:08:22,279 --> 00:08:24,920
, и это обычно сообщение GET

109
00:08:24,920 --> 00:08:29,805
, если вы хотите, чтобы данные были загружены с сайта сервера.

110
00:08:29,805 --> 00:08:35,404
И вы также укажете, с каким именно сервером вы общаетесь.

111
00:08:35,404 --> 00:08:39,320
Когда сервер получает ваш запрос, сервер

112
00:08:39,320 --> 00:08:45,215
извлекает данные из своего хранилища данных, как правило, базы данных на стороне сервера,

113
00:08:45,215 --> 00:08:49,160
, а затем упаковывает эти данные в соответствующие четыре обратно,

114
00:08:49,160 --> 00:08:53,595
и отправляет данные обратно вам на стороне клиента.

115
00:08:53,595 --> 00:08:58,430
Если вы получаете стандартный код HTML, CSS и javascript со стороны сервера,

116
00:08:58,430 --> 00:09:00,746
, то ваш браузер может сделать это.

117
00:09:00,746 --> 00:09:05,705
Вернувшись с приложениями, такими как угловые, вы в основном подключаетесь к серверу

118
00:09:05,705 --> 00:09:12,919
, а затем извлекаете данные в виде либо JSON, либо XML большую часть времени.

119
00:09:12,919 --> 00:09:16,730
За исключением первоначальной загрузки всех ресурсов

120
00:09:16,730 --> 00:09:22,259
, необходимых для выполнения углового приложения в вашем браузере.

121
00:09:22,259 --> 00:09:29,929
Итак, как мы видели ранее, HTTP-приложение требует отправки сообщений

122
00:09:29,929 --> 00:09:31,954
между клиентом и сервером.

123
00:09:31,954 --> 00:09:36,524
Сообщение запроса, обычно отправляемое клиентом на сервер,

124
00:09:36,524 --> 00:09:42,600
и сообщение запроса состоит из строки запроса плюс куча заголовков

125
00:09:42,600 --> 00:09:47,309
, где вы предоставите дополнительную информацию для квалификации запроса.

126
00:09:47,309 --> 00:09:49,889
Мы увидим использование различных заголовков

127
00:09:49,889 --> 00:09:53,129
и настроек в заголовках, как мы проходим через некоторые

128
00:09:53,129 --> 00:09:56,634
упражнений в этом конкретном модуле.

129
00:09:56,634 --> 00:09:59,159
Строка запроса и заголовки отделены

130
00:09:59,159 --> 00:10:04,500
от тела сообщения запроса одной пустой строкой.

131
00:10:04,500 --> 00:10:08,279
Тело сообщения может содержать дополнительные данные, особенно

132
00:10:08,279 --> 00:10:11,754
, если ваши клиенты отправляют данные на сервер.

133
00:10:11,754 --> 00:10:13,769
Например, при отправке формы

134
00:10:13,769 --> 00:10:20,819
информация в форме кодируется в формате JSON

135
00:10:20,819 --> 00:10:24,409
, а затем передается на стороне сервера со стороны клиента.

136
00:10:24,409 --> 00:10:28,860
Таким образом, это будет сделано с использованием сообщения POST или PUT.

137
00:10:28,860 --> 00:10:33,610
Глядя на немного более подробную информацию о HTTP-запросе,

138
00:10:33,610 --> 00:10:38,134
типичное сообщение запроса в строке запроса будет содержать метод,

139
00:10:38,134 --> 00:10:39,011
, который является либо GET, PUT, PAUSE, DELETE

140
00:10:39,011 --> 00:10:43,455
, либо некоторые другие глаголы, которые вы видели ранее.

141
00:10:43,455 --> 00:10:48,360
Затем следует URL-адрес и версия протокола HTTP

142
00:10:48,360 --> 00:10:52,500
, который вы используете для связи с клиентом на стороне сервера.

143
00:10:52,500 --> 00:10:57,120
Поле заголовка обычно содержит имя поля заголовка, двоеточие,

144
00:10:57,120 --> 00:11:00,539
и значение этого поля заголовка.

145
00:11:00,539 --> 00:11:08,100
И содержимое тела, как я уже упоминал, может быть закодировано либо в формате JSON, либо в формате XML.

146
00:11:08,100 --> 00:11:16,419
Вот пример типичного сообщения HTTP-запроса

147
00:11:16,419 --> 00:11:19,294
, которое может быть отправлено на сервер от клиента.

148
00:11:19,294 --> 00:11:23,169
Итак, в этом конкретном сообщении запроса мы просим сервер сохранить

149
00:11:23,169 --> 00:11:28,090
и index.hmtl страницы со стороны сервера на сторону клиента так

150
00:11:28,090 --> 00:11:31,320
, что его можно отобразить в браузере на стороне клиента.

151
00:11:31,320 --> 00:11:37,029
Подобный запрос обычно имеет пустое тело в сообщении запроса.

152
00:11:37,029 --> 00:11:42,309
Большая часть информации будет закодирована в строке запроса плюс заголовки

153
00:11:42,309 --> 00:11:44,559
сообщения запроса.

154
00:11:44,559 --> 00:11:49,179
Когда клиент отправляет запрос на сервер,

155
00:11:49,179 --> 00:11:55,355
сервер обрабатывает запрос, а затем отправляет ответ на клиентскую сторону.

156
00:11:55,355 --> 00:11:59,379
Ответное сообщение состоит из, опять же, трех частей.

157
00:11:59,379 --> 00:12:05,679
Сохраняется строка состояния с некоторой информацией о том, как был обработан запрос

158
00:12:05,679 --> 00:12:08,940
и что отправляется обратно клиенту.

159
00:12:08,940 --> 00:12:16,149
Заголовки будут содержать дополнительные сведения о том, что содержится в ответном сообщении

160
00:12:16,149 --> 00:12:22,654
, а затем следует пустая строка, а затем фактическое тело сообщения.

161
00:12:22,654 --> 00:12:28,750
Пример того, что обычно содержится в сообщении ответа HTTP.

162
00:12:28,750 --> 00:12:32,766
В этом случае ответное сообщение возвращается с 200

163
00:12:32,766 --> 00:12:36,549
, который является кодом состояния сообщения.

164
00:12:36,549 --> 00:12:40,644
Если вы видите здесь, 200 в строке запроса как код состояния.

165
00:12:40,644 --> 00:12:43,360
Это означает, что ваш запрос был успешным

166
00:12:43,360 --> 00:12:50,169
и сервер может вернуть данные, которые вы запросили со стороны сервера.

167
00:12:50,169 --> 00:12:56,544
И затем заголовок будет содержать дополнительные направления на клиентскую сторону,

168
00:12:56,544 --> 00:13:02,735
, включая информацию о том, как кодируется фактическое тело сообщения.

169
00:13:02,735 --> 00:13:07,099
Затем тело может содержать, если вы запросили индекс HTML страницы,

170
00:13:07,099 --> 00:13:12,399
тело сообщения будет содержать код HTML

171
00:13:12,399 --> 00:13:18,534
для начальной страницы индекса HTML, как вы видите в этом примере здесь.

172
00:13:18,534 --> 00:13:27,210
Одна из частей информации в строке состояния, которую я называю кодом состояния.

173
00:13:27,210 --> 00:13:31,304
Если сервер сможет обработать ваш запрос правильно,

174
00:13:31,304 --> 00:13:34,990
он отправит обратно ответ с оценкой состояния 200,

175
00:13:34,990 --> 00:13:37,450
означает, что все в порядке на стороне сервера,

176
00:13:37,450 --> 00:13:40,914
и серверная сторона вернет данные правильно.

177
00:13:40,914 --> 00:13:45,294
Если сервер не может обработать запрос по какой-либо причине,

178
00:13:45,294 --> 00:13:50,259
, то эта информация будет закодирована в коде состояния в

179
00:13:50,259 --> 00:13:53,309
в строке состояния ответного сообщения.

180
00:13:53,309 --> 00:13:56,950
Различные коды состояния, как правило, что вы столкнетесь

181
00:13:56,950 --> 00:13:59,210
при получении ответа со стороны сервера,

182
00:13:59,210 --> 00:14:05,864
включают 201, что означает, что когда вы пытаетесь создать объект на стороне сервера,

183
00:14:05,864 --> 00:14:11,230
он был успешно создан или 301, что означает, что все, что вы запрашиваете

184
00:14:11,230 --> 00:14:13,750
имеет переехал навсегда в новое место,

185
00:14:13,750 --> 00:14:17,889
и что вы находитесь на новом месте этого ресурса

186
00:14:17,889 --> 00:14:20,205
, будет возвращен на вашу клиентскую сторону.

187
00:14:20,205 --> 00:14:26,014
400s и 500s обычно указывают на некоторые проблемы на стороне сервера.

188
00:14:26,014 --> 00:14:31,210
A 404 - это то, с чем вы часто сталкиваетесь, когда запрашиваете

189
00:14:31,210 --> 00:14:35,110
для чего-то, что не существует на стороне сервера.

190
00:14:35,110 --> 00:14:38,860
Аналогично, 500 означает, что сервер просто сдается,

191
00:14:38,860 --> 00:14:43,620
он не может обработать ваш запрос, а затем отправляет обратно внутреннюю ошибку сервера.

192
00:14:43,620 --> 00:14:47,575
Это два распространенных кода ошибок, с которыми вы столкнетесь.

193
00:14:47,575 --> 00:14:53,629
Остальные имеют конкретное значение, как указано в этой таблице.

194
00:14:53,629 --> 00:14:57,625
Есть больше, чем коды состояния, которые я дал вам в этой таблице

195
00:14:57,625 --> 00:15:00,519
, но это некоторые из наиболее распространенных кодов состояния

196
00:15:00,519 --> 00:15:06,220
, которые вы встретите в ответном сообщении, поступающем со стороны сервера.

197
00:15:06,220 --> 00:15:13,044
Еще один момент, о котором я упомянул, - это тот факт, что сервер может кодировать данные

198
00:15:13,044 --> 00:15:21,534
в определенном формате, таком как XML или расширяемый язык разметки или JSON, JavaScript

199
00:15:21,534 --> 00:15:24,085
Object Notation для этого.

200
00:15:24,085 --> 00:15:28,690
Теперь, как правило, в этом конкретном курсе мы будем иметь дело с данными

201
00:15:28,690 --> 00:15:31,164
, которые закодированы в основном в JSON.

202
00:15:31,164 --> 00:15:38,544
Большинство приложений, клиентских приложений, включая мобильные приложения в наши дни,

203
00:15:38,544 --> 00:15:40,450
обычно связываются с сервером

204
00:15:40,450 --> 00:15:49,240
и формат обмена данными по умолчанию JSON.

205
00:15:49,240 --> 00:15:54,968
Именно поэтому я потрачу несколько минут на объяснение вам о JSON.

206
00:15:54,968 --> 00:16:01,000
Обозначение объекта javascript, или JSON, представляет собой легкий формат обмена данными.

207
00:16:01,000 --> 00:16:09,279
Причина, по которой формат данных JSON представляет особый интерес для нас в этом курсе, -

208
00:16:09,279 --> 00:16:13,955
, потому что нотация объекта javascript, как следует из названия,

209
00:16:13,955 --> 00:16:20,480
очень легко сопоставляется с объектом javascript, который вы используете с любым из кодов javascript.

210
00:16:20,480 --> 00:16:24,890
Таким образом, преобразование объекта javascript в нотацию JSON,

211
00:16:24,890 --> 00:16:26,924
и наоборот, очень просто.

212
00:16:26,924 --> 00:16:30,350
Эта нотация JSON является, то, что мы называем,

213
00:16:30,350 --> 00:16:35,045
как самоописывающая и очень простая для понимания нотация.

214
00:16:35,045 --> 00:16:38,230
В формате нотации объектов javascript

215
00:16:38,230 --> 00:16:44,335
данные структурированы в очень чистом указанном порядке.

216
00:16:44,335 --> 00:16:47,810
Это структурировано как набор пар имя/значение,

217
00:16:47,810 --> 00:16:52,855
и это структурировано как упорядоченный список значений.

218
00:16:52,855 --> 00:16:56,674
Вы можете увидеть пример этого на правой стороне здесь,

219
00:16:56,674 --> 00:17:03,980
мы фактически использовали данные JSON с нашим угловым приложением уже раньше.

220
00:17:03,980 --> 00:17:08,809
Итак, теперь вы видите, почему данные структурированы таким образом.

221
00:17:08,809 --> 00:17:15,503
И вы также понимаете, что очень легко иметь дело с этими данными

222
00:17:15,503 --> 00:17:21,335
в вашем javascript аудио, машинопись поймается в вашем угловом приложении.

223
00:17:21,335 --> 00:17:27,484
С этим я завершаю краткий обзор основных элементов сети.

224
00:17:27,484 --> 00:17:33,109
Теперь мы перейдем к и упражнения, где мы создадим рудиментарный сервер

225
00:17:33,109 --> 00:17:39,080
, который обслуживал некоторые данные, к которым мы можем подключиться из нашего углового приложения

226
00:17:39,080 --> 00:17:42,140
, а затем обмениваться данными с сервером.

227
00:17:42,140 --> 00:17:48,079
Теперь мы разработаем полноценный сервер в одном из последующих курсов

228
00:17:48,079 --> 00:17:52,400
код узла JS и курс разработки на стороне сервера

229
00:17:52,400 --> 00:17:56,669
, который придет в качестве последнего курса в этой специализации.