0
400
Views¿La forma más económica de implementar una aplicación React usando NextJS SSR en AWS?
Entiendo que Nextjs es un marco de Node que requiere capacidades de servidor y, por lo tanto, usarlo para la representación del lado del servidor no se puede alojar solo en un S3. Sin embargo, ¿eso significa que la única alternativa es alojar toda la aplicación en un EC2, que es significativamente más costoso, o existe otra solución intermedia?
6 answers
Answer question0
Puede utilizar AWS Lightsail: https://aws.amazon.com/lightsail/
En mi experiencia con nextjs , las funciones de la nube no son un buen lugar para implementar una aplicación grande, por lo que estas serían sus opciones:
- Utilice las funciones de la nube solo si su aplicación es muy pequeña y nunca va a crecer. La función de la nube tiene limitaciones en el tamaño del archivo, las dependencias, el tamaño del paquete, etc., etc., etc.
- AWS Lightsail: https://aws.amazon.com/lightsail/ y un pequeño VPS que puede configurar usted mismo con Nginx y node. Es como $ 5 / mes y puede usar sus créditos.
- Igual que el número 1, pero en Digital Ocean.
- AWS Ec2
0
NextJS + Serverless no es gratuito.
NextJS+ Serverless se implementa actualmente en Lambda Edge, que no es gratuito . No disfruta del nivel gratuito de Lambda (no de Lambda@Edge).
Vercel + NextJs es gratis
Si tiene un sitio web con poco tráfico, le recomendaría implementarlo con Vercel.com, que utiliza Lambda (AWS Network) en el backend.
*Su versión de pasatiempo es gratuita y brinda un generoso tráfico gratuito e invocación comparable al nivel gratuito de AWS Lambda.
La implementación de una aplicación NextJS es tan fácil como cargarla en la implementación automática de Github + Vercel con la integración de GitHub. No necesita preocuparse por S3, alojamiento o sus archivos estáticos, todo se aloja en Vercel en el momento en que ingresa a Github. Solo necesita concentrarse en el desarrollo.
Cuando su requisito aumenta (pasa el paquete Hobby y pasa el paquete Pro), entonces se vuelve más rentable implementar en Serverless@Edge.
Para entonces, todo lo que necesita hacer es cambiar su dominio.
Actualización: simplemente impleméntalo en un VPS
Serverless es un buen concepto, y la capacidad de lanzar sus sitios web de forma gratuita en varias plataformas es una ventaja.
Sin embargo, el inicio en frío puede ser un gran problema, ya que a veces se tarda de 3 a 4 segundos en cargar una página para el visitante.
Esto no es un gran problema si está haciendo una generación incremental estática O estática. Simplemente NO ES BUENO para getServerSideProps .
Si tiene problemas para arrancar en frío, confíe en mí y pase a un VPS. Un VPS de $ 5 puede ejecutar un sitio bastante bien.
0
Para implementar nuestro sitio web nextJs, hemos estado usando AWS lambda: https://github.com/serverless-nextjs/serverless-next.js Fue increíblemente simple de usar. Lamentablemente en algún momento la carga de la página fue muy lenta. Fue de 2 segundos a 7 segundos. También fue confirmado por la consola de búsqueda de Google. 
No pudimos encontrar una manera de profundizar realmente en este problema y cómo pudimos resolverlo, pero sospecho que fue un comienzo en frío. Después de algunas investigaciones, AWS era teóricamente posible resolverlo con concurrencia:
¡Pero no pude hacerlo funcionar, ya que es un Lambda@Edge y también es muy caro! 
En http://nachonacho.com nos enfocamos en el SEO, por lo que el tiempo de carga de la página era nuestra mayor preocupación.
Finalmente decidimos pasar a un AWS EC2 simple.
Aquí tenéis la comparativa:
fuente: https://www.site24x7.com/
- Azul claro: EC2
- Azul oscuro: imagen Lambda imagen
Fuente: https://www.dareboost.com/
0
Módulo Terraform de AWS Next.js
Creamos un módulo Terraform de código abierto como una alternativa de menor costo al marco Serverless para este caso de uso. En lugar de confiar solo en Lambda@Edge para todas las operaciones de SSR, usamos Lambda@Edge solo para el enrutamiento (como una especie de proxy inverso) y luego redirigimos la solicitud internamente a través de API Gateway a un Lambda regional.
Dado que usamos CloudFront como proxy inverso, también podemos dividir la mayoría de las solicitudes de archivos estáticos en _next/static/* para css, js, etc. y atenderlos directamente desde S3 sin tocar el proxy Lambda@Edge en absoluto.
Entonces, el costo por solicitud es diferente por ruta:
Solicitudes de activos estáticos : css, js, imágenes
Solo se aplican costos para CloudFront y S3 (para fallas de CloudFront)
Solicitudes de HTML : rutas HTML renderizadas previamente o rutas que necesitan representación del lado del servidor (SSR)
Se aplican costos para Cloudfront , Lambda@Edge (Proxy, medido en pasos de 1 ms).
Reescriba las rutas que sirven HTML prerenderizado
Se aplican costos para S3 .
Rutas que usan representación del lado del servidor (SSR)
Se aplican costos para HTTP API-Gateway y Lambda regional (SSR, medido en pasos de 1 ms).
Los costes totales suelen estar muy por debajo de los 0,50 $/mes para unas pocas miles de solicitudes con este modelo, al tiempo que se cuenta con un sitio de servicio rápido impulsado por el almacenamiento en caché de borde de CloudFront.
Encuentre más información en el repositorio de GitHub: https://github.com/dealmore/terraform-aws-next-js
0
No estoy seguro de si tiene un requisito para hospedar en Amazon o no, pero puede hospedar en DigitalOcean por $ 5 / mes, o puede hospedar en el nivel gratuito para Heroku hasta que esté seguro de que desea mudarse a Amazon, luego puede mudarse a un solución más costosa y anfitrión de EC2:
- DigitalOcean Eso le dará 1 GB de memoria - SSD de 25 GB - Transferencia de 1 TB por $ 5 / mes
- Heroku That le dará 512 MB de memoria: 1 Web y 1 Worker Dyno de forma gratuita e incluso si paga, hay algunos precios asequibles y Heroku es un servicio administrado, por lo que se encargarán de todo y usted no tiene que configurar nada.
Creo que debería ser un buen comienzo para usted antes de pagar por soluciones más caras.
Y esa respuesta a sus preguntas, sí, EC2 es el más barato para Amazon y Elastic beanstalk si prefiere una solución más administrada dentro de Amazon.
0
Next.js SSR + marco sin servidor + AWS Lambda
Para implementar su aplicación Next.js SSR, en lugar de seguir un enfoque tradicional de administrar y ejecutar una instancia completa de AWS EC2 que continúa funcionando las 24 horas del día, los 7 días de la semana. En realidad, existe un enfoque más rentable y moderno que utiliza AWS lambda y el marco Serverless.
P. ¿Qué es AWS lambda ?
AWS Lambda le permite ejecutar código sin aprovisionar ni administrar servidores. Solo paga por el tiempo de cómputo que consume.
P. ¿Qué es el marco sin servidor ?
Serverless Framework Open Source le permite desarrollar aplicaciones con arquitecturas sin servidor e implementarlas con AWS Lambda, Azure Functions, Google CloudFunctions y más.
P. ¿Qué es Serverless-Next.js ?
Este es un componente sin servidor creado solo para implementar la aplicación Next.js. Además, cualquiera de sus activos en las carpetas estáticas o públicas se carga en S3 y se sirve desde CloudFront automáticamente, por lo que creo que esto es exactamente lo que está buscando.
A continuación se muestra la arquitectura que explica cómo sirve su aplicación al usuario.
Si es nuevo en el marco sin servidor, le sugiero que realice un curso gratuito de la comunidad sin servidor llamado Sin servidor para desarrolladores frontend
EDITAR: 03/03/2021
@super7egazi expresó una preocupación genuina en el comentario a continuación. Afortunadamente, hay algunas formas de mantener caliente la función Lambda. Este es el acto de enviar eventos de ping programados a sus funciones para mantenerlas vivas e inactivas, listas para atender solicitudes.
Encontrará varios métodos y complementos para lograr esto, si solo busca "¿Cómo mantener calientes las funciones lambda?" en Google.
A continuación hay algunos enlaces que adjunto como referencia.
¿Cómo mantener calientes las funciones lambda?