Bienvenidos a Serverless Framework

Es una herramienta para crear, implementar y administrar recursos en AWS (también admite la configuración de otros proveedores de la nube). Deberá especificar la configuración de recursos en archivos yaml, como la creación de roles de AWS para funciones específicas, base de datos DynamoDB, API Gateway o SQS. etc.

Construye rápidamente la pila de formación de nubes e implementa aplicaciones sin servidor en AWS.

Crea paquetes con un solo comando. Lo bueno es que toda la pila también se puede eliminar con un solo comando.

Buen artículo sobre cómo probar el marco sin servidor.

Cosas que usé en mi aplicación que mejoraron mi código

Complementos:

Definitivamente, los complementos están hechos para una funcionalidad personalizada para agregar a sus aplicaciones sin servidor.

Uno de esos son …

– complemento-dotenv-serverless:

Que cargará las variables de entorno en una aplicación sin servidor. Este complemento proporciona tantas funciones listas para usar como que puede especificar las variables env requeridas y también puede ser la exclusión de las variables que se usaron en el desarrollo local. Aquí está el enlace del paquete npm.

Pero la última versión de serverless proporciona la palabra clave useDotEnv para cargar variables env. Por lo tanto, el complemento ya no es necesario para funciones básicas en variables de entorno. Puede consultar el enlace de este artículo para obtener más información.

serverless-iam-roles-per-function

Se recomienda definir un rol a nivel de función por motivos de seguridad. Puede definir tantas declaraciones de permisos como necesite para que se ejecute la función. El marco proporciona una opción (iamRoleStatementsName) para dar un nombre personalizado. Aquí puede encontrar información sobre el complemento.

– Usando pseudoparámetros

Para agregar cualquier pseudoparámetro (como # {AWS :: AccountId}) en los parámetros de recursos (como ARN), el serverless framework proporciona funciones integradas (en la última versión) que se reemplazarán durante la implementación.

Variables personalizadas basadas en condiciones:

Supongamos que tiene una variable (definida en el archivo yaml) que debe formarse en función de la condición de la etapa (como dev, etapa, prod). En este caso, hubo que llamar a la función lambda en el desarrollo local para probar, por lo que los pseudoparámetros para construir ARN ocurrirán solo en la implementación.

Así que utilicé la condición para resolver en el propio local según el escenario.

CLIENT_AC_ID:  ${self:custom.CLIENT_AC_ID_LOGIC.${self:provider.stage}, self:custom.CLIENT_AC_ID_LOGIC.other}CLIENT_AC_ID_LOGIC:
   dev-user: “21289893432”
   other: “#{AWS::AccountId}”STAGE1_ARN: arn:aws:states:${self:provider.region}:${self:custom.CLIENT_AC_ID}:stateMachine:stage1pipeline-datasync-${self:provider.stage}

Aquí CLIENT_AC_ID se evaluará en función del parámetro de etapa en condición. Si desea características de condición más avanzadas en yaml, puede optar por este complemento. Y también las funciones basadas en condiciones son otra característica que puede utilizar para sus requisitos personalizados.

Revestimiento de código serverless:

Linting es básicamente código de análisis automático para verificar errores programáticos y estilísticos.

La configuración de linting se especificará en el archivo .eslintrc.json

{
 "extends": "@serverless/eslint-config/node",
 "parserOptions": {
   "ecmaVersion": 2020
 },
 "env": {
   "node": true
 },
 "rules": {
   "no-console": "off",
   "no-unused-vars": ["error", { "argsIgnorePattern": "^_" }],
   "strict": "off"
 }
}

Si bien compromete el código también en la confirmación previa, puede forzar a hacer linting para verificar si está libre de errores.

Especificando config en package.json

"lint-staged": {
   "*.js": [
     "npm run lint",
     "prettier --write"
   ],
   "*.json": [
     "prettier --write",
     "git add"
   ]
 },
 "husky": {
   "hooks": {
     "pre-commit": "lint-staged"
   }
 },

Para que esto funcione, debe tener instalado husky y lint-staged en su paquete de dependencias de desarrollo.

¿Y si la aplicación sigue creciendo?

¿Cómo mantenemos la estructura de carpetas y las mejores prácticas? Si sigue agregando funciones en un solo archivo yaml. Será muy difícil para la legibilidad. Junto con esa pila de Cloudformation, tiene una limitación de 200 recursos. Entonces, el serverless framework ofrece un buen artículo sobre cómo explicar el problema y abordarlo. En eso, nuestro enfoque será dividir su configuración yml única serverless en otras separadas, según las funcionalidades.

[Para eso, vea el siguiente proyecto de ejemplo de muestra en este repositorio]

Como se indica en el repositorio, solo muestre la estructura de carpetas. Tomé un ejemplo de una aplicación de comercio electrónico de múltiples inquilinos, aunque no tiene el código completo, al ver el repositorio obtendrá una idea de cómo se puede administrar la aplicación. Para una perspectiva de implementación, en la canalización de CI / CD puede configurar esto para una implementación separada para cada pila individual.

Explicaré un poco sobre esto aquí:

El serverless.common.yml, que utilicé para declarar la ruta común y los recursos comunes necesarios para toda la aplicación. Toda la declaración de función especificada en ese archivo se define en la carpeta común.

Cada ruta definida puede tener una definición de esquema para validar la carga útil de la solicitud. Esta definición de esquema se especifica en la carpeta de esquema como archivos de extensión json. Cualquier función auxiliar de DynamoDB u otra función auxiliar relacionada con el proyecto se puede escribir dentro de la carpeta auxiliar. La definición de las declaraciones de funciones de IAM para DynamoDB o la definición de recursos de SQS se puede escribir en archivos yml separados, se pueden importar en cualquier otra pila (archivos yml sin servidor). Carpeta de servicios utilizada para almacenar diferentes pilas de servicios. Por ej. en el caso de la aplicación e-com, los servicios serán como gestión de pedidos, gestión de inventario, etc. y cada servicio tendrá un archivo serverless.yml diferente que representará una pila diferente.

Hay otra opcion

Donde serverless proporciona una forma de implementar la aplicación express.js en la API REST sin servidor. Hay un paquete adicional llamado serverless-http que debe usar junto con express.

Solo una ruta de función es suficiente para declarar en un archivo yml sin servidor.

service: serverless-express-rest-api

plugins:
  - serverless-dotenv-plugin

provider:
  name: aws
  runtime: nodejs14.x
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-1'} 
  environment:    
    NODE_ENV: ${env:NODE_ENV, 'development'}
    SLS_STAGE: ${self:provider.stage}

functions:
  app:
    handler: index.handler
    events:
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

Y si necesita otorgar declaraciones de funciones de IAM (permisos) para DynamoDB o SQS, se pueden otorgar a esta única función. El paquete serverless-http no solo se adhiere al marco expreso y también admite muchos otros paquetes.