Упрощение: сервер

[antonkalinin-ml]

• автор: CRUD
• категория: CRUD
• тег: CRUD
• черновик: CRUD, publish
• юзер: CR-D
• новость: -R--, гибкие параметры запроса
• комменты: C---
• опционально картинки: -R-- (не в жсоне же их получать). Но создавать можно и в
  жсоне для простоты, в запросе создания драфта. Никаких multipart/form-data.

Итого:

• 23 эндпойнта
• много параметров в запросе новостей

Что можно сократить:

• убрать фичу обновления новости из нового черновика. Как только новость создана из
  черновика, ее нельзя изменить. (Хотя это требование и не было четко выражено,
  его смысл был пояснен в комментах в риззоме). Таким образом, "черновики"
  больше не нужны как сущность: новость может быть отредактирована напрямую, и
  ее можно опубликовать или скрыть флажком в базе. Добавить этот флажок в атрибуты новости.
• убрать эндпойнты чтения. Они пишутся легко, но громоздко и шаблонно, можно
  убрать без особого урона программе. Тестировать тут тоже особо нечего. Чтение
  нужно оставить только для новостей, и еще картинок, так как нет другого
  способа их получить - класть жсон с картинками в новость совсем уж стремно.
  Интересно, когда твой сервер выдает картинку и она видна в браузере
  невооруженным глазом.
• убрать удаление. Задание не конкретизирует логику удаления, поэтому стажер и
  сейчас вправе выбрать самый тупой вариант: не удалять сущность, если есть
  зависимости от нее, а это несложно и бойлерплейт. Удаление самая простая
  операция в базе, тут особо нечего изучать, на проекте выучит.
• убрать авторов, сделать флажок в юзере "может создавать новости". Автор вообще
  самая неинтересная сущность, а требует пачку эндпойнтов. Придется пожертвовать
  изучением связи один-к-одному, unique-констрейнтом в базе. Но у нас останется
  много других связей, куда сложнее этой. unique можно сохранить, потребовав
  уникальность имен категорий.
• упростить авторизацию: basic auth по user_id + пароль. Для простоты пароль
  генерируется автоматом и выдается юзеру при создании. В базе можно хранить хеш
  пароля, а можно сам пароль. В реальности же скорее всего будет JWT или что-то
  вроде него, так что генерация временных токенов - вряд ли полезный опыт.
• убрать атрибуты:
  • у юзера убрать фамилию. Имена могут состоять из одного слова, а могут
    включать любое количество слов, для этого достаточно одного поля.
  • аватарка юзера. Стажер напрактикуется с картинками в рамках новостей.
  • не удалять логин, имя, дату, так как нет возможности их править, а чтение
    достаточно просто.
  • убрать главную картинку из новости, оставить просто множество картинок.
    Меньше бойлерплейта.
• убрать теги. Мы жертвуем связью много-ко-многим, но это нетрудно выучить
  позже.
• убрать комментарии. Связь один-ко-многим у нас есть между новостью и
  картинками, принципиально ничего нового.
• можно сократить объем тестов, написав пример и требования, что надо
  тестировать и как. Некоторые пилят полноценные е2е-тесты, это суперизбыточно и
  не способствует пониманию Handle Pattern. Тестировать нужно только
  бизнес-логику, а не базу и не веб: например, проверки при
  создании-редактировании категории, что категория не является собственным
  потомком и что все категории на одном уровне уникальны. Еще полезно написать пример теста на получение новостей с фильтром и сортировкой, со стабовой базой (тестируется функция на хаскеле, а не web API) - это основная функциональность, выглядит логично.
• разрешить servant. Это точно пригодится и сэкономит время на написании роутинга.
• разрешить высокоуровневые библиотеки для базы: beam, esqueleto, etc. С другой стороны, писать запросы простым текстом в таком проекте тоже неплохо, и это поможет понять, чем плох простой текст, - от переименования столбца может перестать работать полприложения, это сложно рефакторить. Изучение esqueleto может отнять время без практического эффекта (разве что потом сэкономится время на реальном проекте с esqueleto)
• написать ясные требования по картинкам: отдавать урлы, возвращать в бинарном виде (есть те, кто возвращает base64 в JSON), создавать можно через base64 в JSON-запросе создания/редактирования новости. multipart/form-data использовать не требуется.

Еще способы (на мой взгляд, это все нежелательно, но можно сделать, если
желаемый объем задания не достигнут):

• плоские категории или даже их отсутствие. Мы теряем иерархические структуры,
  но это можно изучить позже. Один-ко-многим остается (новости-картинки). Из сущностей остаются только юзеры и новости, ну и картинки, как-то совсем неинтересно.
• сократить обновление.
  • редактирование списка картинок в новости. Оно сложно: нужно либо задавать
    новый список картинок, либо список для добавления + список для удаления.
• пагинация. Не хочу убирать, это можно реализовать в одном месте и
  переиспользовать, полезно и не слишком трудно.
  • NB: в норме пагинация выдает не более N элементов, даже если юзер запросил
    больше. Это нужно указать в требованиях, иначе требование не выполняется.

Итого

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

[antonkalinin-ml]

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