Frontends sólidos: configuração

O manifesto do aplicativo de 12 fatores contribuiu significativamente para o desenvolvimento e operação de aplicativos da web, mas isso afetou principalmente os back-ends e contornou os front-ends. A maioria das cláusulas do manifesto não é aplicável a front-ends ou são executadas por si mesmas, mas com o número 3 - configuração - há dúvidas.

O manifesto original dizia: "Mantenha a configuração em tempo de execução". Na prática, isso significa que a configuração não pode ser armazenada no código-fonte ou no artefato final. Ele precisa ser passado para o aplicativo no momento da inicialização. Esta regra tem aplicações práticas, aqui estão algumas:

1. Um aplicativo em ambientes diferentes deve acessar back-ends diferentes. Em produção - para API de produção, em teste - para teste de API e ao executar testes de integração - para um servidor simulado especial.

   
   
   
   
   

2. Para os testes e2e, é necessário reduzir o tempo de espera pela reação do usuário. Por exemplo, se algo acontecer no site após 10 minutos de inatividade, para um cenário de teste, você pode reduzir esse intervalo para um minuto.

   
   
   
   
   

SSR

Se o aplicativo front-end contiver SSR, a tarefa se tornará um pouco mais fácil. A configuração é passada como variáveis ​​de ambiente para o aplicativo no servidor; quando renderizada, ela entra na resposta ao cliente como variáveis ​​globais declaradas no <script>



início da página. No cliente, basta pegar essas variáveis ​​do escopo global e utilizá-las.

Recentemente, na Aviasales, fizemos um aplicativo para renderização em servidor de partes do site e nos deparamos com esse problema. O resultado é meu companheiro de equipe zaopensorsil - isomorphic-env-webpack-plugin .

O belo Next.js faz isso fora da caixa , você não precisa fazer nada de especial.

CSR

, — . , , . , .

:

1. – config.js
   
   
   
   , . , . — -, -, — -. — PR .

   
   
   
   
   

2. . DefinePlugin
   
   
   
   Webpack. — . — , . , , . .

   
   
   
   
   

.

-

- :

1. nginx, nginx -. nginx .

   
   
   
   
   

2. , — API.

   
   
   
   
   

— , nginx . /user-api/path



https://user.my-service.io/path



, /auth-api/path



https://auth.other-service.io/path



.

nginx Docker-

1.19 Docker- nginx . .template



/etc/nginx/templates



. , .

nginx SPA :

server {
  listen   8080;

  root /srv/www;
  index index.html;
  server_name _;

  location /user-api {
    proxy_pass ${USER_API_URL};
  }

  location /auth-api {
    proxy_pass ${AUTH_API_URL};
  }

  location / {
    try_files $uri /index.html;
  }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dockerfile :

FROM node:14.15.0-alpine as build

WORKDIR /app
#   
# ...

FROM nginx:1.19-alpine

COPY ./default.conf.template /etc/nginx/templates/default.conf.template

COPY --from=build /app/public /srv/www
EXPOSE 8080
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

, nginx .

, , .

.

. Caddy , Traefik .

API, - .

-, . , .

JS-:

window.__ENV__ = {
  USER_API_URL: 'https://user.my-service.io/',
  AUTH_API_URL: 'https://auth.other-service.io/',
};

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

, . . <script>



HTML- .

nginx Docker-

, , — API, . , , env.dict



:

BACK_URL
GOOGLE_CLIENT_ID
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Bash- generate_env.sh



JS-:

#!/bin/bash
filename='/etc/nginx/env.dict'

#  JS-
config_str="window._env_ = { "

#    JS-
while read line; do
variable_str="${line}: \"${!line}\""
config_str="${config_str}${variable_str}, "
done < $filename

#  JS-
config_str="${config_str} };"

#    
echo "Creating config-file with content: \"${config_str}\""
echo "${config_str}" >> /srv/www/config.env.js

#  <script>    HTML-
sed -i '/<\/body><\/html>/ i <script src="/confit.env.js"></script>' *.html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Bash, . , .

nginx , nginx. cmd.sh



, :

#!/bin/bash

bash /etc/nginx/generate_env.sh

nginx -g "daemon off;"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dockerfile:

FROM node:14.15.0-alpine as build

WORKDIR /app
#   
# ...

FROM nginx:1.19-alpine

#    Alpine  Bash,  
RUN apk add bash

COPY ./default.conf /etc/nginx/conf.d/

COPY --from=build /app/public /srv/www

COPY ./cmd.sh /etc/nginx/cmd.sh
COPY ./generate_env.sh /etc/nginx/generate_env.sh
COPY ./env.dict /etc/nginx/env.dict
 
EXPOSE 8080

CMD ["bash", "/etc/nginx/cmd.sh"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

— env.dict



.

.

, , SSR . isomorphic-env-webpack-plugin, : HTML.

Há mais um pequeno caso de ponta neste esquema - geralmente um hash de conteúdo é adicionado aos nomes dos arquivos com recursos, de modo que no navegador todos os arquivos possam ser armazenados em cache para sempre por nome sem problemas. Nesse caso, você precisa complicar um pouco o script para gerar um arquivo com variáveis, fazer hash do conteúdo e adicionar o resultado ao nome do arquivo.

Conclusão

O trabalho correto com os parâmetros do aplicativo front-end ajuda a criar sistemas confiáveis ​​e fáceis de usar. Basta desacoplar a configuração do aplicativo e movê-lo para o tempo de execução para melhorar radicalmente o conforto dos membros da equipe e reduzir possíveis erros.

Como você passa configurações para aplicativos cliente?