Как стать автором
Обновить

Комментарии 11

Вы не Гугл. Не нужен вам grpc. У вас нет той нагрузки где его оптимальность перевесит проблемы его сложности.

Я согласен со следующими утверждениями:
1. Мы не Google.
2. У нас нет той нагрузки, где его оптимальность перевесит проблемы его сложности.

gRPC — это не панацея, и его применение должно быть обоснованным. В статье я старался показать саму технологию и её возможности, чтобы читатели могли поближе познакомиться с ней и с подводными камнями, которые могут встретиться при её интеграции.

Проблемы там мягко говоря другие.

Начнем со сокрытых за парой слоев абстракции пулов. Которые внезапно заканчиваются. На проде в черную пятницу в 4 утра по времени того кто чинить будет, естественно.

Поэтому статья ориентирована не для начинающих разработчиков, а для более опытных, которые уже успели столкнуться с неожиданными сюрпризами в проде и знают, как важно учитывать такие моменты заранее.

Опытные в курсе что такое прото и как он выглядит. Вы мимо и тех и других.

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

Для новичков gRPC может показаться сложным

сдается мне что новичку будет гораздо сложнее освоить spring ))))))

Соглашусь с Вами, самому в первое время было тяжело)

@Transactional
public AreaEntity createArea(AreaEntity area) {
  if (areaRepo.existsByTitleOrCoordinateOrAddress(area.getTitle(), area.getCoordinate(), area.getAddress())) {
    throw new ApiServiceException("Такая площадка уже существует", HttpStatus.CONFLICT);
  }
  return areaRepo.save(area);
}

тут разве не рейс кондишн? кажется, только при serializable это отработает так, как ожидается

Почему?)

Спасибо за замечание, моя ошибка, что не учёл состояние гонки.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации