Комментарии / Профиль Avdeev / Хабр

Avdeev 6 дек 2019 в 15:32

Не уверен, но, думаю, можно попробовать сделать образ с SDK, который при старте инициализирует окружение.

Avdeev 6 дек 2019 в 14:41

Да, кстати, об это я не подумал. Хороший кейс.

Локальное разворачивание позволяет развернуть у себя любую ветку API.

Например, вот так:

cd api
git checkout feature/branch
docker-compose build api
make migrate
docker-compose up api

Avdeev 6 дек 2019 в 12:44

Да, Вы правы. Плюс ещё примерно 4 ГБ на виртуалку на MacOS.

Avdeev 6 дек 2019 в 12:14

Отличное замечание, я про это не рассказал.

Действительно, полностью избавиться от инструкций и команд не получается.

Мы делаем вот так:

1. docker-compose up api собирает связанные через depends_on образы и запускает их.
2. Все команды на запущенных контейнерах стараемся убирать в Makefile.

Что-то вроде:

# Makefile
migrate:
  docker-compose run api bundle exec rake db:migrate

Avdeev 6 дек 2019 в 12:02

После доклада меня спрашивали несколько раз про этот подход, когда фронтенд-разработчик всё запускает не локально, а использует отдельный staging- или dev-сервер для разработки.

Этот способ работает и имеет свои плюсы, но не лишен и недостатков.

Вот некоторые из них:

Невозможность работать офлайн или при плохом Интернете. Многие любят работать из дома, деревни или в дороге.
Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками. У нас были случаи, когда приходилось создавать необходимую для разработки сущность новости с названием «НЕ УДАЛЯТЬ!», чтобы кто-то её случайно не грохнул. Но, всё равно это периодически случалось.
Такой сервер достаточно хрупкий. Было несколько ситуаций, когда бекенд-разработчики или эскплуатация начинали шатать сервак. Или, к примеру, накатывали туда какие-нибудь ломающие изменения. Это останавливало разработку у всей команды.

Avdeev 6 дек 2019 в 11:47

Оно всё достаточно легковесное, в этом и прелесть Docker. Вот пример вывода docker stats.

CONTAINER ID        NAME                                   MEM USAGE
e4941ea92ce7        nginx_1                                3.16MiB
1b023bfff38f        api_1                                  351.5MiB
e07c6958e378        pg_1                                   18.64MiB
1fa783f5fdbc        terminal-front_1                       14.89MiB
72e9dfa0805a        adminer_1                              11.19MiB
e9ce9f965867        admin-front_1                          1.312MiB
3edacc59a77b        certbot_1                              1.547MiB

Видим, что БД заняла 19 МБ, а API на Java — 352 МБ.

У нас у разработчиков от 8 до 16 ГБ оперативной памяти. Обычно, этого хватает.

По личному опыту, большую часть оперативной памяти во время разработки съедает IDE, Chrome, Telegram, Slack, а не запущенные docker-контейнеры.

GitHub переходит на GraphQL

Avdeev 3 дек 2019 в 12:25

Про REST полностью согласен. За эти два года я поумнел и лучше разобрался в теме. :)

С сериализацией/десериализацией проблем особо не было никогда. Обыкновенная работа со структурами данных.

Тут профит в том, что структура jsonapi-сущности документирована и исключает споры, тогда как «самых простых сериализаций» может быть несколько.

Avdeev 18 окт 2019 в 23:02

Конференции: начало пути

Так вот почему всё время есть доклад про выгорание!

Avdeev 6 мая 2019 в 13:23

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

Мы используем загрузку файлов через Multipart.

Avdeev 4 фев 2019 в 17:06

Сделай, спецификация JSON API это не запрещает. :) Она лишь говорит, что «если Вам нужны связи между представления, то вот так их можно сделать».

Avdeev 4 фев 2019 в 15:50

Нет никакой связи с БД.
Relationships (считай join) связывает представления, которые могут быть получены откуда угодно.

Avdeev 4 фев 2019 в 12:47

Stateless означает, что сервер не хранит никакого состояния о сессии клиента на стороне сервера.

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

Это единственный способ масштабирования до миллионов одновременно работающих пользователей.

Полее подробно с картинками описано в диссертации Роя Филдинга.

Avdeev 4 фев 2019 в 12:26

Да, конечно.
REST — передача состояния представления.
Естественно, представление может быть получено откуда угодно.

Avdeev 4 фев 2019 в 12:21

Это зависит от реализации сервера.
RFC 3986 никак не определяет формат передачи массива через GET-параметры.

В общем случае на сервер придёт строка вся query string.

Если сервер разберёт её по аргументам, то, скорее всего, будет вот так:

{
  'fields': 'title',
  'include': 'authors',
  'fields[author]': 'id,name'
}

Если игнорирование и будет, то только если оно специально так настроено.

Avdeev 29 янв 2019 в 17:28

http://springbot.github.io/json-api/extensions/bulk/#deleting-multiple-resources

DELETE /articles
Content-Type: application/vnd.api+json; ext=bulk
Accept: application/vnd.api+json; ext=bulk

{
  "data": [
    { "type": "articles", "id": "1" },
    { "type": "articles", "id": "2" }
  ]
}

Note: RFC 7231 specifies that a DELETE request may include a body, but that a server may reject the request. This spec defines the semantics of a server, and we are defining its semantics for JSON:API.

Avdeev 29 янв 2019 в 16:27

Спасибо за замечание. Согласен, слово «придумал» не очень корректно. Я имел ввиду, что он является одним из авторов.

Avdeev 29 янв 2019 в 16:25

В докладе я говорю о том, что любое решение будет работать. Но вместо того, чтобы спорить по поводу правильных HTTP-кодов и названий полей, вроде isSuccess, лучше взять готовую спеку и начать делать то, что нужно заказчику.

Avdeev 29 янв 2019 в 16:21

Не предлагается сразу всё запихивать. Большинство условий являются необязательными и просто иллюстрируют «как можно делать, если Вам нужно».

Avdeev 29 янв 2019 в 16:15

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

Avdeev 29 янв 2019 в 16:09

В спеке есть про это, если я правильно понял Ваше замечание.

Some clients, like IE8, lack support for HTTP’s PATCH method. API servers that wish to support these clients are recommended to treat POST requests as PATCH requests if the client includes the X-HTTP-Method-Override: PATCH header. This allows clients that lack PATCH support to have their update requests honored, simply by adding the header.

jsonapi.org/recommendations/#patchless-clients

На вопрос тоже нашёл ответ в спеке:

Note: The above example URI shows unencoded [ and ] characters simply for readability. In practice, these characters must be percent-encoded, per the requirements in RFC 3986.

jsonapi.org/format/#fetching-sparse-fieldsets