Какие использовал Environment?

Использование Environment Variables в Frontend-разработке

В современной Frontend-разработке работа с environment variables (переменными окружения) стала неотъемлемой частью профессионального workflow. Я использую их систематически для управления конфигурацией приложений в разных средах выполнения.

Основные подходы и инструменты

1. .env файлы в экосистеме React/Vue/Next.js В большинстве современных фреймворков я использую подход с файлами .env:

// .env.development
API_URL=http://localhost:3000/api
WS_URL=ws://localhost:3001
DEBUG=true
SENTRY_DSN=

// .env.production  
API_URL=https://api.production.com/v1
WS_URL=wss://ws.production.com
DEBUG=false
SENTRY_DSN=https://[key]@sentry.io/[project]

Для доступа к переменным в коде:

// React приложение
const apiClient = axios.create({
  baseURL: process.env.REACT_APP_API_URL,
  timeout: parseInt(process.env.REACT_APP_TIMEOUT || '5000')
});

// Важно: в Create React App переменные должны начинаться с REACT_APP_

2. Динамическая конфигурация в runtime Для более сложных сценариев я реализовывал динамическую загрузку конфигурации:

// config.js - динамическая загрузка конфигурации
async function loadConfig() {
  const env = window.location.hostname.includes('localhost') ? 'dev' : 'prod';
  const response = await fetch(`/config.${env}.json`);
  return response.json();
}

// Использование в приложении
const config = await loadConfig();
const apiEndpoint = config.api.baseUrl;

3. Интеграция с CI/CD системами В пайплайнах сборки я настраиваю подстановку переменных на этапе build:

# GitHub Actions example
- name: Build React App
  env:
    REACT_APP_API_URL: ${{ secrets.API_URL }}
    REACT_APP_VERSION: ${{ github.sha }}
  run: npm run build

Типизация и валидация переменных

Для TypeScript-проектов я создаю типизированные конфигурации:

// config.ts
interface AppConfig {
  apiUrl: string;
  wsUrl: string;
  enableAnalytics: boolean;
  version: string;
}

function validateConfig(): AppConfig {
  const apiUrl = process.env.REACT_APP_API_URL;
  if (!apiUrl) {
    throw new Error('REACT_APP_API_URL is required');
  }
  
  return {
    apiUrl,
    wsUrl: process.env.REACT_APP_WS_URL || '',
    enableAnalytics: process.env.REACT_APP_ENABLE_ANALYTICS === 'true',
    version: process.env.REACT_APP_VERSION || '1.0.0'
  };
}

export const config = validateConfig();

Практические use cases из моего опыта

Мультитенантные приложения:

• Разделение конфигурации для разных клиентов через переменные TENANT_ID
• Динамическое подключение к различным API endpoints

A/B тестирование и feature flags:

// feature-flags.js
export const featureFlags = {
  newCheckout: process.env.REACT_APP_FEATURE_NEW_CHECKOUT === 'true',
  darkMode: JSON.parse(process.env.REACT_APP_ENABLE_DARK_MODE || 'false')
};

Безопасность и секреты:

• Никогда не храню реальные секреты в frontend-коде
• Использую proxy-серверы для доступа к защищенным ресурсам
• Для чувствительных данных применяю server-side rendering с передачей только необходимых данных

Best Practices, которые я соблюдаю:

1. .gitignore для .env файлов - никогда не коммичу файлы с реальными значениями
2. Образцы конфигурации - создаю .env.example с описанием всех необходимых переменных
3. Валидация на этапе сборки - проверяю наличие обязательных переменных перед build
4. Минимизация runtime конфигурации - стараюсь решать максимум на этапе сборки
5. Логирование в dev-режиме - вывод используемой конфигурации в development для отладки

Продвинутые сценарии

Для микрофронтендов и сложных SPA я использовал:

Контейнеризованные приложения:

# Dockerfile
FROM node:18-alpine
ARG REACT_APP_API_URL
ENV REACT_APP_API_URL=$REACT_APP_API_URL

SSR-приложения (Next.js/Nuxt.js):

// Next.js - доступ на сервере и клиенте
export async function getServerSideProps() {
  return {
    props: {
      apiUrl: process.env.API_URL
    }
  };
}

Интеграция с мониторингом:

• Передача environment меток в Sentry/DataDog
• Отправка информации о среде в аналитические системы

Работа с environment variables требует баланса между гибкостью и безопасностью. Основной принцип, которого я придерживаюсь: frontend никогда не должен содержать реальные секреты, а конфигурация должна быть максимально прозрачной и воспроизводимой для всех членов команды.