Чистая архитектура в Node.js

Основное внимание в чистой архитектуре уделяется отделению основной бизнес-логики приложения от деталей инфраструктуры. В этой статье мы обсудим чистую архитектуру в Node.js и рассмотрим, как реализовать ее в проектах Node.js примерами кода и как применять к ним концепции.

Выявление и решение проблем

При разработке приложений Node.js мы часто сталкиваемся с некоторыми проблемами, такими как дублирование кода, неорганизованная кодовая база и тесная связь (tight coupling). В следующем разделе мы используем простой пример приложения Node.js, которое извлекает данные из базы данных и возвращает их в качестве ответа JSON. Чистая архитектура предлагает решения этих проблем, делая упор на следующие принципы:

Разделение ответственности (Separation of Concerns, SoC)

Фундаментальный принцип разработки программного обеспечения, который подчеркивает важность разделения системы на отдельные модули или компоненты, каждый из которых несет определенную и независимую ответственность. В Node.js SoC часто реализуется с использованием модульной архитектуры, где каждый модуль отвечает за одну задачу или функциональность. Вот пример того, как разделение ответственности может быть применено к этому коду:

// index.js - Плохой код!

const express = require('express')
const app = express()
const database = require('./database')

app.get('/users', async (req, res) => {
  try {
    const users = await database.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

В этом коде мы смешали задачи маршрутизации, извлечения данных и обработки ошибок в одном файле. Это может затруднить обслуживание и масштабирование кода по мере роста приложения.

Вот как мы можем применить разделение ответственности к этому коду:

// index.js

const express = require('express')
const app = express()
const usersRouter = require('./routes/users')

app.use('/users', usersRouter)

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

// routes/users.js

const express = require('express')
const router = express.Router()
const usersController = require('../controllers/users')

router.get('/', usersController.getUsers)

module.exports = router

// controllers/users.js

const database = require('../database')

async function getUsers(req, res) {
  try {
    const users = await database.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
}

module.exports = {
  getUsers,
}

В этом переработанном коде мы разделили задачи маршрутизации, контроллера и извлечения данных на три отдельных файла. Файл index.js отвечает за создание приложения Express и регистрацию маршрутов, файл routes/users.js отвечает за обработку маршрута /users и делегирование запроса usersController, а файл controllers/users.js отвечает за извлечение данных из базы данных и возврат ответа клиенту. Разделив эти задачи, мы можем достичь лучшей модульности и удобства сопровождения кода. Например, если мы хотим добавить больше маршрутов, мы можем создать новый файл в routes и зарегистрировать его в index.js без изменения существующего кода. Аналогичным образом, если мы хотим изменить способ извлечения данных из базы данных, мы можем изменить database.js файл без изменения маршрута или кода контроллера.

Инверсия зависимостей (Dependency Inversion, DI)

В Clean Architecture зависимости инвертируются, что означает, что модули более высокого уровня должны зависеть от модулей более низкого уровня. Это гарантирует, что бизнес-логика не будет связана с деталями инфраструктуры. Вот пример того, как инверсия зависимостей может быть применена к этому коду:

// index.js - Плохой код!

const express = require('express')
const app = express()

const usersController = require('./controllers/users')
app.get('/users', async (req, res) => {
  try {
    const users = await usersController.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

// controllers/users.js

const database = require('../database')
async function getUsers() {
  try {
    const users = await database.getUsers()
    return users
  } catch (error) {
    throw new Error('Error retrieving users')
  }
}

module.exports = {
  getUsers,
}

В этом коде index.js напрямую зависит от модуля usersController, который в свою очередь напрямую зависит от модуля database. Это нарушает принцип инверсии зависимостей, поскольку высокоуровневые модули не должны зависеть от низкоуровневых модулей.

Вот как мы можем применить инверсию зависимостей к этому коду:

// index.js

const express = require('express')
const app = express()
const usersController = require('./controllers/users')
const database = require('./database')

app.get('/users', async (req, res) => {
  try {
    const users = await usersController.getUsers(database)
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

// controllers/users.js

async function getUsers(database) {
  try {
    const users = await database.getUsers()
    return users
  } catch (error) {
    throw new Error('Error retrieving users')
  }
}

module.exports = {
  getUsers,
}

В этом переработанном коде мы применили Dependency Inversion, передав модуль database в качестве параметра функции getUsers в модуле usersController. Таким образом, высокоуровневый модуль index.js не зависит напрямую от низкоуровневого модуля database, но оба зависят от абстракции функции getUsers. Применяя инверсию зависимостей, мы можем добиться большей модульности, гибкости и тестируемости кода. Например, если мы хотим переключиться на другую реализацию базы данных, мы можем создать новый модуль, реализующий функцию getUsers, и передать ее в качестве getUsers в модуле usersController без изменения существующего кода. Точно так же мы можем легко имитировать модуль database для целей модульного тестирования.

Принцип единой ответственности (Single Responsibility Principle, SRP)

Каждый модуль или функция должны нести единую ответственность. Это помогает в создании кодовой базы, которую легко понять и поддерживать. Вот пример в Node.js который иллюстрирует принцип SRP:

// user.js - Плохой код!

class User {
  constructor(name, email, password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }

  saveToDatabase() {
    await database.saveUser(user)
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
      res.status(400).send('Email Error')
    });
  }

  sendWelcomeEmail() {
    await mailService.send(user, 'Welcome')
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
        res.status(400).send('Email Error')
    });
  }
}

В этом примере у нас есть класс User, который имеет две обязанности:

1. Сохранение пользовательских данных в базе данных
2. Отправка приветственного электронного письма пользователю

Это нарушает принцип SRP, поскольку класс User имеет несколько причин для изменения. Например, если мы решим изменить способ сохранения пользовательских данных в базе данных, нам также придется изменить класс User, даже если это не связано с отправкой приветственного электронного письма.

Чтобы следовать принципу SRP, мы можем разделить эти обязанности на отдельные классы:

class User {
  constructor(name, email, password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }
}

class UserRepository {
  saveToDatabase(user) {
    await database.saveUser(user)
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
      res.status(400).send('Email Error')
    });
  }
}

class EmailService {
  sendWelcomeEmail(user) {
      await mailService.send(user, 'Welcome')
      .then(() => {
        res.status(200).send()
      })
      .catch(err => {
        res.status(400).send('Email Error')
      });
    }
  }
}

Теперь у нас есть три класса, каждый из которых несет единую ответственность:

1. User: отвечает за представление пользователя.
2. UserRepository: отвечает за сохранение пользовательских данных в базе данных.
3. EmailService: отвечает за отправку приветственного электронного письма пользователю.

Разделив обязанности, мы сделали наш код более модульным и простым в обслуживании. Если нам нужно изменить способ сохранения пользовательских данных в базе данных, нам нужно только изменить класс UserRepository. Класс User и класс EmailService остаются неизменными.

Концепции и детальное проектирование

Чистая архитектура в Node.js основана на принципах чистой архитектуры, введенных Робертом С. Мартином (он же дядя Боб). В нем подчеркивается разделение ответственности, разъединение зависимостей и модульность. Цель состоит в том, чтобы создать кодовую базу, которую легко понять, протестировать и поддерживать. Основная идея Clean Architecture заключается в разделении приложения на разные слои, где каждый уровень несет определенную ответственность. Слои взаимодействуют друг с другом через четко определенные интерфейсы. Это позволяет легко модифицировать и тестировать приложение, не затрагивая другие части кодовой базы. Node.js — это популярная среда выполнения для создания веб-приложений. Он имеет обширную экосистему библиотек и фреймворков, которые можно использовать для реализации Clean Architecture. Вот некоторые из ключевых концепций чистой архитектуры в Node.js:

Уровень инфраструктуры (Infrastructure Layer)

Уровень инфраструктуры отвечает за обработку внешних зависимостей, таких как базы данных, API или файловая система. Он должен быть отделен от уровня домена, чтобы обеспечить легкое тестирование и модификацию. Уровень инфраструктуры должен реализовывать интерфейсы, определенные уровнем домена. В Node.js уровень инфраструктуры может быть реализован с помощью пакетов или модулей. Например, можно использовать популярный пакет Knex.js для обработки запросов к базе данных. Уровень инфраструктуры должен быть спроектирован так, чтобы быть подключаемым, что позволяет легко заменять внешние зависимости. Вот пример модуля инфраструктуры, реализующего адаптер базы данных:

const knex = require('knex');

class UserDatabase {
  constructor(config) {
    this.db = knex(config);
  }
  
  async getById(id) {
    const data = await this.db('users').where({ id }).first();
    return data ? User.create(data) : null;
  }
  
  async save(user) {
    const data = User.toData(user);
    const { id } = user;
    
    if (id) {
      await this.db('users').where({ id }).update(data);
    } else {
      const [newId] = await this.db('users').insert(data);
      user.id = newId;
    }
  }
}

Этот модуль предоставляет методы для получения пользователя по идентификатору и сохранения пользователя в базе данных с помощью библиотеки Knex.js.

Уровень представления (Presentation Layer)

Уровень представления отвечает за отображение выходных данных приложения для пользователя и обработку вводимых пользователем данных. Он должен быть отделен от прикладного уровня и уровня инфраструктуры. Уровень представления может быть реализован с помощью веб-фреймворков, таких как Express.js или Hapi.js. В Node.js уровень представления может быть реализован с помощью веб-фреймворков или модулей. Веб-фреймворки предоставляют мощный и гибкий способ реализации уровня представления и размещения всей логики вместе. Вот пример модуля презентации, реализующего REST API с помощью веб-платформы Express.js:

const express = require('express');
const bodyParser = require('body-parser');
const UserService = require('./services/user-service');
const UserDatabase = require('./infra/user-database');

const app = express();

app.use(bodyParser.json());

const userDatabase = new UserDatabase(config);
const userService = new UserService(userDatabase);

app.get('/users/:id', async (req, res) => {
  const { id } = req.params;
  try {
    const user = await userService.getUserById(id);
    res.json(user);
  } catch (error) {
    res.status(404).json({ error: error.message });
  }
});

app.put('/users/:id', async (req, res) => {
  const { id } = req.params;
  const { userData } = req.body;
  try {
    let user = await userService.getUserById(id);
    user = User.create({ ...user, ...userData });
    await userService.saveUser(user);
    res.json(user);
  } catch (error) {
    res.status(404).json({ error: error.message });
  }
});

Этот модуль создает приложение Express.js, настраивает пользовательскую службу и базу данных, а также предоставляет конечные точки REST API для получения и обновления пользовательских данных.

Прикладной уровень (Application Layer)

Прикладной уровень отвечает за оркестрацию взаимодействия между доменным уровнем и уровнем инфраструктуры. Он содержит варианты использования приложения, которые представляют взаимодействия между пользователем и системой. Прикладной уровень должен быть отделен от уровня домена и уровня инфраструктуры. В Node.js прикладной уровень может быть реализован с помощью классов или модулей. Классы обеспечивают четкое разделение ответственности и инкапсуляцию. Модули обеспечивают более простой подход к реализации прикладного уровня. Вот пример класса приложения, представляющего пользовательскую службу:

class UserService {
  constructor(userDatabase) {
    this.userDatabase = userDatabase;
  }
  
  async getUserById(id) {
    const user = await this.userDatabase.getById(id);
    if (!user) {
      throw new Error(`User not found with ID ${id}`);
    }
    return user;
  }
  
  async saveUser(user) {
    await this.userDatabase.save(user);
  }
}

Этот класс предоставляет методы для получения пользователя по идентификатору и сохранения пользователя с помощью модуля инфраструктуры UserDatabase.

Уровень домена (Domain (Enterprise) Layer)

Доменный уровень является сердцем приложения, содержащим бизнес-логику и правила. Он должен быть независим от каких-либо внешних библиотек или фреймворков, что упрощает его тестирование и изменение. Доменный уровень является наиболее важной частью приложения, и любые изменения должны вноситься с большой осторожностью. В Node.js, уровень домена может быть реализован с помощью классов или модулей. Классы обеспечивают четкое разделение ответственности, инкапсуляцию и возможность повторного использования. Модули, с другой стороны, обеспечивают более простой подход к реализации доменного уровня. Вот пример класса домена, представляющего сущность пользователя:

class User {
  constructor(id, name, email) {
    this.id = id;
    this.name = name;
    this.email = email;
  }
  
  changeName(name) {
    this.name = name;
  }
  
  changeEmail(email) {
    this.email = email;
  }
  
  static create(data) {
    const { id, name, email } = data;
    return new User(id, name, email);
  }
  
  static toData(user) {
    const { id, name, email } = user;
    return { id, name, email };
  }
}

Этот класс инкапсулирует пользовательские данные и предоставляет методы для изменения имени и адреса электронной почты пользователя.

Использование сторонних npm пакетов

Использование сторонних пакетов — отличный способ повысить чистоту кода. Существует множество пакетов, которые могут помочь вам организовать кодовую базу и сделать ее более модульной. Например, можно использовать пакет, например Express.js для обработки маршрутизации и промежуточного ПО. Вы также можете использовать пакет, такой как Knex.js для обработки запросов к базе данных. Использование этих пакетов может помочь уменьшить дублирование кода и сделать базу кода более организованной. Вот еще несколько примеров использования сторонних пакетов:

Lodash

Lodash — это служебная библиотека, предоставляющая широкий спектр функций для работы с массивами, объектами и другими структурами данных. Используя Lodash, можно избежать написания повторяющегося кода для таких задач, как фильтрация, сортировка и преобразование данных. Например, рассмотрим следующий код для фильтрации массива пользователей по возрасту:

const users = [
  { name: 'Alice', age: 25 },
  { name: 'Bob', age: 30 },
  { name: 'Charlie', age: 35 },
];

const filteredUsers = users.filter(user => user.age >= 30);

Используя Lodash, вы можете вместо этого написать следующий код:

const _ = require('lodash');

const users = [
  { name: 'Alice', age: 25 },
  { name: 'Bob', age: 30 },
  { name: 'Charlie', age: 35 },
];

const filteredUsers = _.filter(users, user => user.age >= 30);

Этот код более лаконичный и легкий для чтения, а использование функции filter от Lodash дает понять, что делает код.

Moment.js или date-fns

Moment.js — это библиотека для синтаксического анализа, манипулирования и форматирования даты и времени. Используя Moment.js, можно избежать написания сложного кода манипуляции с датой и снизить вероятность ошибок. Например, рассмотрим следующий код для форматирования даты в виде строки:

const date = new Date();
const formattedDate = `${date.getFullYear()}-${date.getMonth() + 1}-${date.getDate()}`;

Используя Moment.js, вы можете вместо этого написать следующий код:

const moment = require('moment');
const date = new Date();
const formattedDate = moment(date).format('YYYY-MM-DD');

Этот код легче читать и поддерживать, а использование функции format от Moment.js дает понять, что делает код.

Winston

Winston — это библиотека логирования (журналирования), которая предоставляет множество функций для ведения журнала сообщений, включая различные уровни логов и настраиваемое форматирование. Используя Winston, вы можете избежать написания пользовательского кода ведения журнала и убедиться, что ваши журналы согласованы и легко читаются. Например, рассмотрим следующий код для регистрации сообщения:

console.log(`[${new Date().toISOString()}] INFO: User logged in`);

Используя Winston, вы можете вместо этого написать следующий код

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.printf(info => `[${info.timestamp}] ${info.level}: ${info.message}`)
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'app.log' }),
  ],
});
logger.info('User logged in');

Этот код более настраиваемый и легко читаемый, а использование Winston дает понять, что делает код.

Итоги

Чистая архитектура — это мощная концепция, которая может помочь вам создать модульный и поддерживаемый код в проектах Node.js. Следуя принципам чистой архитектуры, можно создать кодовую базу, которую легко понять, протестировать и расширить. Можно также использовать сторонние пакеты и различные структуры папок для повышения чистоты кода. Реализация Clean Architecture в проектах Node.js может помочь вам избежать распространенных ошибок, таких как дублирование кода, неорганизованная кодовая база и тесная связь.

SSR фреймворки

Одностраничные приложения (SPA) и соответствующие им фреймворки (например, React.js, Vue.js, Svelte.js) прошли через более или менее громкие циклы и существуют уже много лет. Однако с появлением мета-фреймворков поверх этих решений мы можем наблюдать четкую тенденцию перехода приложений от рендеринга на стороне клиента (CSR) к рендерингу на стороне сервера (SSR). В наши дни SSR повсеместно используется при работе с JavaScript-фреймворками. Самый популярный SSR фреймворк под названием Next.js работает поверх React.js. Эндрю Кларк, core разработчик React, назвал его "настоящим релизом React 18" в 2022 году, потому что он поставляется со всеми встроенными возможностями (например, Suspense, streaming SSR), которые команда React предоставляет в качестве фундаментальных строительных блоков на нижнем уровне библиотеки. И Vercel (компания, стоящая за Next.js), и основная команда React.js работают в тесном сотрудничестве, обеспечивая отличный опыт для разработчиков.

Хотя многие разработчики смотрят на тесную связь между Next.js и React.js с опаской, для React.js есть альтернативы, такие как Remix (недавно приобретенная Shopify). Remix использует другой подход к превращению React.js в SSR-фреймворк, но есть и функции, которые схожи (например, вложенная маршрутизация) в обоих фреймворках из-за их конкуренции. Несмотря на то, что Next.js уже является признанным лидером в современной SSR разработке и превратил многих фронтенд-разработчиков в фуллстек разработчиков, другие фреймворки тоже должны быть в вашем списке внимания: SvelteKit (построенный на Svelte.js) с его недавним релизом 1.0 при поддержке Vercel и SolidStart (построенный на Solid.js) с его улучшенным DX по сравнению с React.js.

Виды рендеринга

В то время как в последнее десятилетие (2010 - 2020) доминировали одностраничные приложения (SPA) с их клиентским рендерингом (CSR), начиная с Knockout.js и Ember.js и заканчивая Angular.js, React.js и Vue.js, в последние годы наблюдается растущий интерес к рендерингу на стороне сервера (SSR) с SSR-фреймворками. Со стороны кажется, что цикл снова замыкается, потому что мы уже давно (с 2005 по 2010 год) используем SSR с внедрением JavaScript (например, jQuery, MooTools, Dojo.js) в многостраничных приложениях (MPA). Однако, если раньше использовилась Java (например, JSP) или позже Ruby on Rails, то в этот раз все по-другому, потому что вместо этого мы полагаемся на JavaScript. В течение нескольких лет Next.js был движущей силой этой тенденции, однако, другие SSR-фреймворки, такие как SvelteKit, догоняют. SSR довольно долго конкурировал со статической генерацией сайтов (SSG) за идеальную производительность, хотя оба паттерна служат совершенно разным целям. В то время как последний паттерн используется для статического контента (например, веб-сайты типа блога), первый используется для динамического контента (например, веб-приложения). Если SEO имеет значение, то и SSR, и SSG могут иметь смысл. Однако при необходимости создания динамичного контента или контента, ориентированного на пользователя, с аутентификацией, разработчики не могут выбрать SSG (один раз собрать перед развертыванием, поэтому статичен) и вынуждены выбирать между SSR (сборка по требованию для каждого запроса с индивидуальными данными на сервере) и CSR (выборка индивидуальных данных по требованию на клиенте).

Однако CSR, SSR, SSG - это не самые последние тенденции в технике рендеринга. В то время как SSR и SSG начали тенденцию оптимизации производительности несколько лет назад, появились иные техники рендеринга, такие как Incremental Static Regeneration (ISR) и Streaming SSR. ISR берет за основу SSG, поскольку позволяет статически перестраивать сайт на основе отдельных страниц (например, перестраивать страницу X каждые 60 секунд) вместо того, чтобы перестраивать весь сайт. Кроме того, On-Demand ISR, также называемая On-Demand Revalidation, может быть использована для пересборки через API (например, при обновлении данных CMS). Потоковый SSR, с другой стороны, оптимизирует однопоточное узкое место рендеринга на стороне сервера. В то время как обычный SSR должен ждать от сервера данных, чтобы отправить отрисованный контент клиенту сразу, потоковый SSR позволяет разработчикам разделить приложение на фрагменты, которые могут быть отправлены параллельно от сервера к клиенту.

В последние годы модели рендеринга были довольно прямолинейными с SSG и SSR в SPA/MPA. Однако в наши дни в моду входят более тонкие варианты. Но не только ISR и SSR стриминг становятся более актуальными, но и частичная гидратация (например, React Server Components), которая позволяет гидратировать только некоторые компоненты на клиенте, прогрессивная гидратация (Progressive Hydration), которая дает более тонкий контроль над порядком гидратации, Island Architectures (островные архитектуры) (например, Astro) для изолированных приложений или компонентов в MPA, а также использование возобновляемости вместо гидратации (например, Qwik с его SSR-фреймворком Qwik City) становятся актуальными подходами в наши дни.

Serverless (бессерверные функции)

Технологии рендеринга, такие как SSR и SSG, очень коррелируют с тенденцией serverless at the edge, потому что обе они ориентированы на производительность с целью обеспечения бесшовного пользовательского опыта в браузере. По сути, стремление обслуживать пользователей быстрее веб-сайтов и веб-приложений вызвало интерес к serverless edge. Но давайте начнем с самого начала: Бессерверность, также известная как бессерверные функции, бессерверные вычисления (например, AWS Lambda) или облачные функции (например, Google/Firebase Cloud Functions), уже несколько лет является большой тенденцией в облачных вычислениях. Хотя бессерверность по-прежнему означает наличие работающего (удаленного) сервера, разработчику не нужно управлять сервером и связанными с ним задачами (например, масштабирование инфраструктуры по требованию). Вместо этого необходимо развернуть одну функцию как бессерверную функцию, о которой позаботится облачный провайдер.

Бессерверные функции открывают еще одно преимущество, поскольку вместо развертывания сервера приложений в одном (или нескольких) центре (центрах) обработки данных, их могут быть десятки по всему миру. Поэтому в идеальном мире бессерверные функции должны работать как можно ближе к пользователям, так как это означает кратчайший путь клиент-сервер и, следовательно, улучшенный пользовательский опыт. Развертывание бессерверных функций как можно ближе к пользователю привело к появлению терминов edge computing и edge functions. Многие облачные провайдеры (например, Cloudflare с Cloudflare Workers, Vercel со своей Edge Network, Deno с Deno Deploy) конкурируют в этом пространстве, где каждый оптимизирует для достижения наилучшего времени интерактивности (TTI) для своих конечных пользователей. Пограничные функции не только быстрее обслуживают контент SSG/SSR (поскольку провод до конечного пользователя короче), но и могут кэшировать свои результаты ближе к пользователю. Но не только производительность имеет значение, хотя она и является основным фактором, другие преимущества, такие как снижение стоимости, также связаны с вычислениями, которые происходят ближе к пользователю. Например, часто не все данные, передаваемые между клиентом и сервером (здесь функция edge), должны вычисляться в главном центре обработки данных. В IoT существует множество нерелевантных данных (например, видеозаписи без изменений в каждом кадре), которые отправляются в главный центр обработки данных и могут быть просто отфильтрованы на границе. В конце концов, пограничные функции - это только начало.

Возрождение баз данных

С появлением бессерверных функций (на границе) базы данных также переживают ренессанс. При использовании бессерверных функций разработчики быстро столкнулись с проблемой открытия слишком большого количества соединений с базой данных, поскольку существует не один сервер, который держит открытым одно соединение, а множество бессерверных функций с соединением 1:1 с базой данных. Решением этой проблемы стало объединение соединений, но об этом приходится заботиться либо самостоятельно, либо с помощью стороннего сервиса. Популярными соперниками в области бессерверных баз данных являются PlanetScale (MySql), Neon (PostgreSQL) и Xata (PostgreSQL), которые имеют множество функций, таких как разветвление баз данных, дифферинцирование схем и мощный поиск/аналитика/инсайты. Когда речь заходит о бессерверных системах, они предоставляют краевое кэширование или распределенную базу данных только для чтения, чтобы переместить данные ближе к пользователям с минимальной задержкой. Если сторонний сервис должен распространять не только вашу базу данных, но и ваше приложение, Fly.io упаковывает все в одну платформу. Что выводит нас за рамки только баз данных, где также происходит много движений. Railway, рассматриваемый как преемник Heroku, предлагает все для платформы как услуги (PaaS) для развертывания вашего технологического стека. Если вы хотите продвинуться на один шаг вверх по цепочке услуг в сторону Backends as a Service (BaaS), вы получите альтернативу Firebase с открытым исходным кодом - Supabase, которая поставляется с хостингом приложений/баз данных, аутентификацией и пограничными функциями.

Среды выполнения JavaScript

Все началось с того, что Райан Дал объявил о Node.js на конференции в 2009 году. То, что начиналось как эксперимент, который отделил JavaScript от браузера и сделал его доступным на сервере, стало одним из самых больших факторов успеха JavaScript за последнее десятилетие. По сути, Райан Дал использовал JavaScript Engine под названием V8 (реализованный в Chrome) для Node.js без самого браузера. Таким образом, и браузер Chrome, и Node.js используют один и тот же JavaScript Engine, но имеют свои собственные JavaScript Runtimes (например, Browser APIs vs Node APIs) для взаимодействия с ним. Десятилетие спустя Райан Дал объявил Deno преемником Node с обещанием предоставить разработчикам более безопасную и быструю среду, которая поставляется с похожими API браузера, TypeScript и стандартной библиотекой из коробки. Однако Deno, который также работает на V8, является лишь одним из многих JavaScript Runtimes в наши дни.

В конкурирующей стране краевых функций многие облачные провайдеры внедряют свои собственные JavaScript Runtime (например, Cloudflare Workers), которые оптимизированы для их собственной инфраструктуры (например, Cloudflare). Таким образом, бизнес-модель Deno также становится облачным провайдером с Deno Deploy и их SSR-фреймворком для рендеринга на границе (который начинался как доказательство концепции) под названием Deno Fresh. Независимые от облачных провайдеров решения, такие как Bun (работающий на JavaScriptCore Engine), недавно стали еще одним вирусным хитом в гонке за самый быстрый JavaScript Runtime. Если что-то пойдет не так, мы окажемся в той же ситуации, что и с фрагментированной поддержкой JavaScript в браузерах в течение многих лет, но на этот раз на сервере, где не весь JavaScript может поддерживаться одинаково во всех средах выполнения при развертывании на различных облачных провайдерах. Поэтому все заинтересованные стороны (например, Deno, Vercel, Cloudflare) присоединились к WinterCG, чтобы сотрудничать в области совместимости API между их JavaScript Runtimes.

Монорепо

В прошлом монорепо использовалось в основном для крупномасштабных приложений, где один проект содержит более мелкие проекты в одном репозитории с контролем версий. Каждый из этих небольших проектов может быть чем угодно - от отдельного приложения (например, SPA, MPA) до пакета многократного использования (например, функции, компоненты, сервисы). Практика объединения проектов восходит к началу 2000 годов, когда это называлось общей кодовой базой. Однако в наши дни монорепозитории используются не только крупными приложениями, но и небольшими компаниями и проектами с открытым исходным кодом, которые, несомненно, извлекут из них пользу. Например, компания может иметь различные пакеты в монорепозитории, начиная от общих компонентов пользовательского интерфейса, общей системы проектирования (например, многоразовое совместное проектирование) и заканчивая широко используемыми полезными функциями для соответствующей области.

Эти пакеты могут быть импортированы в различные приложения: реальное приложение (например, app.mywebsite.com с рендерингом на стороне клиента), которое использует все эти общие пакеты, домашняя/продуктовая/лендинговая страница (например, mywebsite.com с рендерингом на стороне сервера или генерацией статического сайта) с учетом SEO использует только пакет общей системы дизайна, а страница технической документации (например, docs.mywebsite.com) использует общие компоненты пользовательского интерфейса и пакеты общей системы дизайна. Turborepo (приобретенная компанией Vercel) вновь подняла шумиху о монорепо в JavaScript/TypeScript. Turborepo позволяет командам создавать конвейеры сборки для всех своих приложений и пакетов в рамках монорепо. Самое привлекательное: кэширование сборок в рамках конвейера на локальной машине или в облаке для всех команд. Turborepo в сочетании с другими жизненно важными инструментами монорепо, такими как npm/yarn/pnpm workspaces (управление зависимостями) и changesets (версионирование), делает этот инструментарий местом, за которым стоит следить в этом году. Конкурентами Turborepo являются Nx, Rush и Lerna (некоторое время не поддерживался, затем был приобретен компанией Nx - Nrwl).

CSS на утилитах

Разработчики либо любят, либо ненавидят его: Tailwind CSS является примером CSS с утилитами. В то время как одна сторона разработчиков ненавидит его за многословность в коде пользовательского интерфейса, другая сторона разработчиков любит его за его великолепный DX. Как разработчик, вы настраиваете его один раз в своем проекте и сразу же используете его готовый CSS в HTML. Этому разделению любви и ненависти к CSS, ориентированному на утилиты, может прийти конец с недавним ростом рендеринга на стороне сервера (SSR). В течение нескольких лет CSS-in-JS решения, такие как Styled Components (SC) и Emotion, были преобладающей силой для стилизации современных веб-приложений на основе компонентов. Однако, если производительность в мире SSR является одной из основных целей, CSS-in-JS имеет негативные последствия: увеличение размера пакета (SC - 12,7 кБ, Emotion - 7,9 кБ) и, что более важно, накладные расходы во время выполнения из-за сериализации CSS перед вставкой в DOM.

Поэтому мы можем наблюдать миграцию разработчиков в сторону более дружественных SSR решений, таких как utility-first-CSS (например, Tailwind CSS, UnoCSS) в паре с предварительно определенным UI компонентом (например, DaisyUI), других не менее популярных альтернатив, таких как CSS Modules, или так называемых без ранатаймовых (без компиляции) CSS-in-JS (например, vanilla-extract, linaria, astroturf, compiled).

TypeScript

Эволюция от JavaScript к TypeScript неостановима. В этой большой миграции веб-разработки безопасность типов E2E для фулстек приложений, безусловно, является важной тенденцией. Реализация этой концепции зависит от коммуникационного уровня (API), который необходим для передачи типизированных сущностей (например, тип User, тип BlogPost) от сервера к клиентскому приложению. Обычными подходами в веб-разработке для связи клиент-сервер являются REST и GraphQL. Оба этих языка можно использовать с OpenAPI для REST и GraphQL Code Generator для GraphQL для создания типизированного файла схемы для фронтенд приложения. Однако появилась новая восходящая звезда типобезопасных API под названием tRPC, которая может быть использована в качестве замены REST/GraphQL. Если вы работаете в монорепо TypeScript, где фронтенд и бэкенд совместно используют код, tRPC позволяет экспортировать все типы из бэкенда во фронтенд-приложение без промежуточной генерации типовой схемы. Впоследствии фронтенд может вызывать API бэкенда, просто используя типизированные функции, которые под капотом соединены HTTP для обеспечения фактического взаимодействия между клиентом и сервером. Общая тенденция, безусловно, направлена на использование большего количества таких типобезопасных решений для фулстек приложений, таких как tRPC, Zod, Prisma и TanStack Router, которые обеспечивают типобезопасность приложения.

Инструменты сборки

В React несколько лет доминировал create-react-app (CRA). В свое время это была небольшая революция, поскольку начинающие разработчики получали готовый стартовый проект React без необходимости настраивать Webpack с React. Однако за последний год Webpack довольно быстро устарел. Vite - это новый инструмент в блоке, когда речь идет об одностраничных приложениях (SPA), поскольку он работает со всеми популярными фреймворками (например, React.js) для создания стартового проекта. Разработанный Эваном Ю, создателем Vue.js, он называет себя фронтенд-инструментом нового поколения. Под капотом он получает свою мощь от esbuild, который по сравнению с другими JavaScript бандлерами написан на Go, и поэтому собирает зависимости в 10-100 раз быстрее, чем его конкуренты (например, Webpack). В то время как экосистема Vite процветает благодаря таким дополнениям, как Vitest (альтернатива Jest для тестирования), совсем недавно появились другие конкуренты, такие как Turbopack от Vercel. Turbopack называют преемником Webpack, потому что его создателем является Тобиас Копперс, создатель Webpack. Поскольку Next.js все еще использует Webpack, а Turbopack разработан той же компанией, мы можем ожидать, что Next.js и Turbopack будут идеально сочетаться в будущем.

Разработка с использованием искусственного интеллекта

Заменит ли ИИ в конечном итоге работу разработчика? На этот вопрос пока нет ответа, однако разработка с использованием ИИ стала реальностью в 2022 году. С выходом GitHub Copilot разработчики получили возможность работать в паре с ИИ-программистом в своей любимой IDE. Это так же просто, как написать код (или написать комментарий с указанием того, что вы хотите написать), и GitHub Copilot автоматически заполнит детали реализации в соответствии со своим пониманием. Но на этом все не заканчивается: ChatGPT от OpenAI - это более общая языковая модель, которая также заботится о задачах программирования. Хотя вы можете задавать ChatGPT вопросы в свободной форме, он также способен выполнять задачи по кодированию. Многие разработчики уже заметили, что используют ChatGPT в качестве замены StackOverflow. Во многих ситуациях ChatGPT давал полезные ответы (хотя и не всегда безупречные), когда использовался в качестве замены поисковой системы. Поскольку последнему приходится иметь дело с большим количеством SEO-спама (не только для контента, связанного с разработкой), ChatGPT рассматривается как жизнеспособная альтернатива на данный момент. Для того чтобы правильно формулировать и задавать запросы в системе ChatGPT для получения наиболее точных и информативных ответов, рекомендую прочитать Как написать запрос к ChatGPT. От промпта к результату.

Однако "в настоящее время" - это важный термин. С высоты птичьего полета созданный искусственным интеллектом контент может (и будет) также вредить всемирной паутине. Если раньше созданный вручную SEO-контент уже был проблемой, то теперь никто не мешает кому-то производить больше автоматически генерируемого SEO-контента с помощью ChatGPT. Будет ли ChatGPT в конечном итоге тренироваться на собственном генерируемом контенте?

Ещё

Есть несколько заслуживающих внимания упоминаний, но которые не попали в список трендов: Tauri как альтернатива Electron для настольных приложений, реализованных на JavaScript/CSS/HTML, Playwright как альтернатива Cypress для E2E тестирования, Warp и Fig как терминалы нового поколения, CSS Container Queries как альтернатива CSS Media Queries для отзывчивого дизайна, и, наконец, htmx как обогащенный HTML для создания интерактивных пользовательских интерфейсов без JavaScript.