1
00:00:01,110 --> 00:00:02,860
‫-: En este video, haremos

2
00:00:02,860 --> 00:00:05,780
‫una última configuración específica de Heroku que es

3
00:00:05,780 --> 00:00:08,047
‫responder a una llamada "señal de

4
00:00:08,047 --> 00:00:10,770
‫término enfermo" que Heroku emite de vez

5
00:00:10,770 --> 00:00:12,023
‫en cuando.

6
00:00:13,670 --> 00:00:16,300
‫Entonces, un dinamómetro de Heroku, y nuevamente

7
00:00:16,300 --> 00:00:19,460
‫un dinamómetro es solo un nombre que Heroku usa

8
00:00:19,460 --> 00:00:21,540
‫básicamente para un contenedor en el

9
00:00:21,540 --> 00:00:23,230
‫que se está ejecutando

10
00:00:23,230 --> 00:00:26,820
‫su aplicación, por lo que estos dynos se reinician cada 24

11
00:00:26,820 --> 00:00:29,930
‫horas para mantener su aplicación en un estado saludable.

12
00:00:29,930 --> 00:00:32,930
‫¿Okey? Y la forma

13
00:00:32,930 --> 00:00:36,060
‫en que Heroku hace esto es enviando la llamada

14
00:00:36,060 --> 00:00:38,577
‫"señal de término enfermo" a nuestra aplicación

15
00:00:38,577 --> 00:00:41,640
‫de notas, y la aplicación básicamente se cerrará inmediatamente.

16
00:00:41,640 --> 00:00:44,680
‫¿Está bien? Ahora, el problema con esto

17
00:00:44,680 --> 00:00:46,830
‫es que el cierre puede ser muy abrupto.

18
00:00:46,830 --> 00:00:50,020
‫Entonces, esto puede dejar las solicitudes que se

19
00:00:50,020 --> 00:00:51,930
‫están procesando actualmente básicamente en

20
00:00:51,930 --> 00:00:53,730
‫el aire, y

21
00:00:53,730 --> 00:00:55,789
‫eso no es lo ideal.

22
00:00:55,789 --> 00:00:58,830
‫Así que, básicamente, eso es lo que sucede

23
00:00:58,830 --> 00:01:01,623
‫también cuando hay un rechazo incontrolado.

24
00:01:02,850 --> 00:01:05,024
‫Entonces, aquí en nuestro servidor, dot

25
00:01:05,024 --> 00:01:07,320
‫JS, recuerde cómo apagamos el servidor

26
00:01:07,320 --> 00:01:09,700
‫con gracia cada vez que hubo un

27
00:01:09,700 --> 00:01:12,690
‫rechazo no controlado. ¿Está bien?

28
00:01:12,690 --> 00:01:13,990
‫Así que ahora

29
00:01:13,990 --> 00:01:16,240
‫vamos a hacer algo muy similar cuando recibamos

30
00:01:16,240 --> 00:01:20,310
‫la "señal de término enfermo". ¿Está bien? Así que digamos

31
00:01:22,410 --> 00:01:23,690
‫procesar punto

32
00:01:26,870 --> 00:01:29,660
‫en término enfermo, y básicamente, realmente el

33
00:01:29,660 --> 00:01:32,300
‫término enfermo es solo un evento que

34
00:01:32,300 --> 00:01:35,160
‫puede ser emitido y que nuestra aplicación recibe

35
00:01:35,160 --> 00:01:36,700
‫y luego puede responder.

36
00:01:36,700 --> 00:01:40,383
‫Tan exactamente como el rechazo incontrolado. ¿Derecha?

37
00:01:41,430 --> 00:01:43,293
‫Ahora bien, aquí no tenemos un error,

38
00:01:46,210 --> 00:01:47,760
‫así que hagamos un registro

39
00:01:48,720 --> 00:01:50,250
‫de la consola aquí,

40
00:01:52,130 --> 00:01:53,713
‫así como el término enfermo recibido.

41
00:01:56,200 --> 00:01:57,280
‫Apagando

42
00:01:58,690 --> 00:02:00,520
‫con gracia.

43
00:02:00,520 --> 00:02:02,820
‫Y agreguemos algunos emoji aquí

44
00:02:02,820 --> 00:02:05,400
‫solo para que se destaque en nuestra consola

45
00:02:05,400 --> 00:02:07,823
‫entre todos estos registros que tenemos allí.

46
00:02:09,580 --> 00:02:11,980
‫Muy bien, y ahora

47
00:02:11,980 --> 00:02:14,700
‫hagamos el cierre ordenado, que básicamente

48
00:02:14,700 --> 00:02:17,173
‫es solo para cerrar el servidor.

49
00:02:21,650 --> 00:02:25,270
‫Así que esto básicamente cerrará el servidor, pero antes de

50
00:02:25,270 --> 00:02:27,150
‫eso todavía manejará todas las

51
00:02:27,150 --> 00:02:29,300
‫solicitudes pendientes. Y eso

52
00:02:29,300 --> 00:02:31,800
‫es exactamente lo que queremos, en

53
00:02:31,800 --> 00:02:35,820
‫lugar de un final muy abrupto de la aplicación, ¿verdad?

54
00:02:35,820 --> 00:02:38,310
‫Luego, una vez hecho esto, bloqueemos eso en

55
00:02:38,310 --> 00:02:39,193
‫la consola.

56
00:02:40,810 --> 00:02:42,133
‫Así que el

57
00:02:43,580 --> 00:02:46,010
‫registro de puntos de la consola, nuevamente

58
00:02:47,260 --> 00:02:50,063
‫agreguemos un lindo emoji aquí, el proceso terminó.

59
00:02:50,950 --> 00:02:53,740
‫Bueno. Y en este caso

60
00:02:53,740 --> 00:02:56,654
‫aquí, no usamos el punto de proceso de salida, porque

61
00:02:56,654 --> 00:02:59,940
‫el término enfermo en sí mismo hará que la aplicación se cierre.

62
00:02:59,940 --> 00:03:01,970
‫No es necesario que lo hagamos manualmente

63
00:03:01,970 --> 00:03:05,100
‫como lo hicimos aquí. ¿Está bien?

64
00:03:05,100 --> 00:03:07,990
‫Básicamente, término enfermo es una señal que se utiliza

65
00:03:07,990 --> 00:03:09,720
‫para hacer que un programa

66
00:03:09,720 --> 00:03:12,430
‫deje de ejecutarse. Así que es una

67
00:03:12,430 --> 00:03:17,430
‫forma muy cortés de pedirle a un programa que termine. ¿Okey?

68
00:03:17,900 --> 00:03:21,510
‫Entonces, nuevamente, necesitamos implementar esta escucha de este

69
00:03:21,510 --> 00:03:23,560
‫evento aquí, porque Heroku cada

70
00:03:23,560 --> 00:03:25,530
‫24 horas cerrará

71
00:03:25,530 --> 00:03:28,140
‫nuestra aplicación enviando esta señal, o

72
00:03:28,140 --> 00:03:30,470
‫este evento, a nuestra aplicación.

73
00:03:30,470 --> 00:03:32,720
‫Y entonces, cerramos el proceso con gracia,

74
00:03:32,720 --> 00:03:34,882
‫utilizando el punto del servidor close, lo

75
00:03:34,882 --> 00:03:37,760
‫que permite que todas las solicitudes pendientes se sigan

76
00:03:37,760 --> 00:03:41,090
‫procesando hasta el final. ¿Okey?

77
00:03:41,090 --> 00:03:43,390
‫Entonces, ahora probemos esto.

78
00:03:43,390 --> 00:03:45,190
‫Entonces, lo que tenemos que

79
00:03:45,190 --> 00:03:47,890
‫hacer primero es, por supuesto, enviar todas estas

80
00:03:47,890 --> 00:03:50,000
‫modificaciones a nuestro repositorio de git

81
00:03:50,000 --> 00:03:51,690
‫y verá que

82
00:03:51,690 --> 00:03:53,670
‫ahora mismo tenemos tres archivos modificados.

83
00:03:53,670 --> 00:03:56,530
‫Así que modificamos el servidor en esta conferencia y

84
00:03:56,530 --> 00:03:59,340
‫el controlador alt en la aplicación dot JS

85
00:03:59,340 --> 00:04:01,923
‫en la última. ¿Derecha?

86
00:04:02,980 --> 00:04:06,050
‫Entonces, agreguemos todos al área de preparación git

87
00:04:06,050 --> 00:04:08,850
‫add all, y luego confirmemos estos cambios

88
00:04:09,860 --> 00:04:12,163
‫realmente en nuestro repositorio.

89
00:04:14,600 --> 00:04:19,390
‫Así que edita, Heroku, config.

90
00:04:19,390 --> 00:04:20,683
‫Llamémoslo así.

91
00:04:21,800 --> 00:04:24,240
‫Está bien. Y ahora

92
00:04:24,240 --> 00:04:26,890
‫recuerde cómo básicamente redistribuimos la aplicación.

93
00:04:26,890 --> 00:04:28,980
‫Bueno, eso es muy fácil.

94
00:04:28,980 --> 00:04:33,133
‫Git empuja la rama maestra del anexo de Heroku.

95
00:04:34,730 --> 00:04:37,260
‫Bien, entonces esto básicamente enviará

96
00:04:37,260 --> 00:04:40,300
‫todas las modificaciones a esta rama

97
00:04:40,300 --> 00:04:42,830
‫y luego reconstruirá la

98
00:04:42,830 --> 00:04:47,170
‫aplicación en Heroku y, por supuesto, la reiniciará también.

99
00:04:47,170 --> 00:04:49,350
‫Como puede ver, hace todo

100
00:04:49,350 --> 00:04:51,900
‫este proceso que hizo cuando implementamos la

101
00:04:51,900 --> 00:04:54,490
‫aplicación por primera vez de nuevo cada

102
00:04:54,490 --> 00:04:57,120
‫vez que implementamos la aplicación en otra ocasión.

103
00:04:57,120 --> 00:05:00,712
‫Y ahora eso está hecho. Entonces, para probar lo

104
00:05:00,712 --> 00:05:04,070
‫que acabamos de hacer aquí, básicamente reiniciemos la

105
00:05:04,070 --> 00:05:06,390
‫aplicación manualmente. Entonces, eso

106
00:05:06,390 --> 00:05:08,663
‫también enviará el término enfermo a

107
00:05:08,663 --> 00:05:12,320
‫la aplicación y debería activar lo que sea que suceda

108
00:05:12,320 --> 00:05:14,980
‫aquí, ¿de acuerdo? Así que comencemos

109
00:05:14,980 --> 00:05:18,520
‫por echar un vistazo a todos nuestros dinamómetros, así que eso

110
00:05:18,520 --> 00:05:21,510
‫es algo que todavía no hicimos, así que ese

111
00:05:23,340 --> 00:05:25,220
‫es Heroku PS y, como puede

112
00:05:25,220 --> 00:05:30,010
‫ver, tenemos aquí este dinamómetro web gratuito. ¿Okey?

113
00:05:30,010 --> 00:05:32,560
‫Cuál se ejecuta, o básicamente cuál

114
00:05:32,560 --> 00:05:35,390
‫comienza usando el comando de inicio MPM, tal

115
00:05:35,390 --> 00:05:38,300
‫como mencioné en uno de los videos anteriores.

116
00:05:38,300 --> 00:05:41,530
‫Bien, ahora lo que podemos

117
00:05:41,530 --> 00:05:46,530
‫hacer para reiniciar es muy simplemente Heroku PS y reiniciar.

118
00:05:49,890 --> 00:05:52,850
‫Entonces no fue correcto, creo.

119
00:05:52,850 --> 00:05:56,340
‫Ahora debería serlo, y ya está.

120
00:05:56,340 --> 00:05:59,360
‫Entonces, echemos un vistazo ahora

121
00:05:59,360 --> 00:06:04,150
‫a los registros que son Heroku logs dash dash tail.

122
00:06:06,940 --> 00:06:11,420
‫Muy bien, aquí está.

123
00:06:11,420 --> 00:06:15,260
‫Viniendo de nuestra aplicación, vemos el término enfermo recibido y

124
00:06:15,260 --> 00:06:17,533
‫luego procesamos los bloqueos terminados.

125
00:06:18,370 --> 00:06:19,940
‫Muy bien, y verá que

126
00:06:19,940 --> 00:06:22,170
‫después de eso, el proceso de inicio con

127
00:06:22,170 --> 00:06:23,723
‫el comando NPM start.

128
00:06:24,980 --> 00:06:27,250
‫Muy bien, y eso es, tenga en

129
00:06:27,250 --> 00:06:30,020
‫cuenta el servidor punto JS tal como lo especificamos,

130
00:06:30,020 --> 00:06:34,120
‫y ahora la aplicación se está ejecutando en el puerto 57 dos seis siete.

131
00:06:34,120 --> 00:06:36,310
‫Y recuerda cómo dije antes que básicamente

132
00:06:36,310 --> 00:06:37,650
‫Heroku ejecuta su

133
00:06:37,650 --> 00:06:40,930
‫aplicación en un puerto aleatorio. Y entonces este es

134
00:06:40,930 --> 00:06:43,790
‫ese. ¿Está bien? ¡Excelente!

135
00:06:43,790 --> 00:06:46,850
‫Así que salgamos de esto, limpiemos esto,

136
00:06:46,850 --> 00:06:49,040
‫y con eso, terminamos todas

137
00:06:49,040 --> 00:06:52,720
‫las cosas de configuración de Heroku en nuestra aplicación.

138
00:06:52,720 --> 00:06:56,140
‫Fantástico. Ahora solo quedan dos

139
00:06:56,140 --> 00:06:57,890
‫cosas más, que es implementar

140
00:06:57,890 --> 00:07:01,129
‫algo llamado CORS, o Intercambio de recursos de origen

141
00:07:01,129 --> 00:07:04,330
‫cruzado, y luego también finalizar los pagos de

142
00:07:04,330 --> 00:07:07,470
‫Stripe mediante webhooks. Así que recuerde cómo

143
00:07:07,470 --> 00:07:09,890
‫prometí implementar eso un poco más tarde,

144
00:07:09,890 --> 00:07:12,990
‫y así lo haremos en las próximas dos conferencias.

145
00:07:12,990 --> 00:07:16,073
‫¿Está bien? Así que nos vemos en un segundo.