Что я понял и с какими проблемами столкнулся, создав клон Hacker News

От переводчика: эта статья — сокращенный перевод оригинального поста ^[1] веб-разработчика Джесси Хорна. Его работа и одновременно хобби — веб-дизайн. Своими наработками и полученным опытом Джесси частенько делится с другими программистами, как опытными, так и начинающими.

Некоторое время назад я написал довольно объемный пост на Hacker News, который получил солидную поддержку читателей. Я обратил внимание на возможности этого ресурса и решил попробовать создать его клон ^[2], для того чтобы получить новый опыт и знания.

Skillbox рекомендует: Практический годовой курс PHP-разработчик ^[3].
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Изначально это казалось мне отличной целью, где набор инструментов и тактика работы были предопределены. Ранее я работал над менее крупными задачами, используя разные языки и фреймворки. Единственное, чего не было, — это крупного проекта, который бы позволил собрать все это вместе.

Работать над новым проектом я решил с нуля, используя язык Crystal. Это удобный инструмент, который к тому же еще и новый. Он быстрый, принципы работы с ним похожи на Ruby. Он статистически типизирован плюс является open source. Но просто нового языка тоже недостаточно, поэтому я решил усложнить свою задачу, и сделать не клон Hacker News, а усовершенствованный вариант этого ресурса.

Кстати, я думал, что создание обычного клона будет легкой задачей. И то, что это не так, я понял чуть позже, начав работу.

Не метьте слишком высоко

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

Я сказал, что не стоит пытаться сразу бросаться на амбразуру выполнения сложной и большой задачи. Выберите то, что вам нужно в конкретный момент для реализации идеи. Далее рекомендую разбить значительные цели на более мелкие. Если у вас слишком много кода, в котором большое количество «мусора», то попробуйте все упростить и структурировать.

Я даже не могу выразить словами, насколько важно разделить большую задачу на несколько более мелких.

В моем случае я столкнулся с различными новыми проблемами, с которыми не встречался ранее. Во-первых, я работал Crystal лишь однажды — когда создавал приложение, сложность которого ненамного превышала сложность программы типа «Hello, world!». В прошлом я использовал Python, Lua, PHP. Новый язык был первым препятствием на пути к реализации проекта.

Вторым стал фреймворк. Crystal, будучи новым языком, пока еще имеет не слишком много фреймворков и документации для них. Я решил использовать Kemal для своего клона. Я надеялся на то, что фреймворк интуитивен, поскольку в своей работе встречал именно такие. Но здесь оказался другой случай — отдельные вещи было нелегко понять. Например, некоторые участки кода выглядели вполне нормально, но почему-то не работали. И найти причину проблемы в интернете было сложно все по той же причине — новизна языка и самого фреймворка. В некоторых случаях мне приходилось подолгу останавливаться и разбираться с причиной проблемы. До настоящего момента я никогда не заглядывал в исходники, например, того же Flask.

Третье препятствие — специфические цели, которые я выбрал для проекта. Для того чтобы сделать мой клон полезнее, я решил добавить ряд функциональных особенностей. Я работал с Hacker News ранее, поэтому знаю многое о достоинствах и недостатках этого ресурса. Мне пришло в голову, что будет хорошо задействовать аналитические данные, предоставляемые GitHub. Используя их, я бы мог добавить статистику по количеству просмотров и активности пользователей на сайте.

Таким образом, я решил, что мой клон должен показывать по крайней мере просмотры и клики для каждого поста. Такая функция, возможно, была бы полезна для пользователей, а ее реализация стала бы хорошей практикой для меня. Но я не думал, что это займет столько времени! Сейчас проект представляет собой скорее proof-of-concept, чем готовый ресурс. Кроме просмотров и кликов, я также решил добавить отображение появляющихся комментариев, чтобы они показывались в real-time. Если бы не эта дополнительная задача, проект был бы завершен гораздо быстрее.

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

Четвертая проблема, с которой я столкнулся, — хаос. Миграции, модели, просмотры, API-контроллеры, CSS и JavaScript-код накапливаются очень быстро. И все это превращается в кашу. Я попробовал решить проблему, и у меня почти получилось. Но отчасти проблемные места в коде моего проекта еще встречаются — вы можете без проблем это заметить. Так, во многих местах код повторяется, эндпоинты не организованы, нейминг усложнен, что приводит к росту объема кода и большому количеству запросов к базе данных. Постепенно я решаю эту проблему.

Во многих местах код повторяется

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

Вообще мне нужно было следовать принципам DRY ^[4] с самого начала. Не повторяйтесь! Мне нужно было написать промежуточную программу, которая бы делала, что необходимо, а затем просто применяла найденное решение в тех случаях, когда это требовалось. В дальнейшем я буду корректировать свой проект исходя именно из этого принципа.

Нейминг эндпоинтов и организация

Раньше я разрабатывал API в команде Pioneer. Мы использовали REST ^[5] — стиль архитектуры, которому я фактически присягнул, будучи новым членом команды Pioneer. В этой команде я работал над небольшими элементами огромного приложения. А вот в своем новом проекте мне все пришлось писать с нуля.

«RESTful API» должен иметь Uniform Interface, так сказано в «Вики». В своем проекте я организовал все так, что эндпоинты определялись в source-файлах, которые назывались соответственно функции или назначению. Регистрация и выход из приложения были прописаны в «auth.cr». Логин пользователя прописывался в «user.cr».

Несомненно, эта часть требует переработки. В дальнейшем я организую все так, чтобы действия относились к эндпоинту "/user", просто потому, что все это имеет отношение к «User». Например, для улучшения структуры проекта разделю код на более удобные и управляемые части с большим числом файлов. Создам папку «src/user/auth/», в которой будут содержаться функции логина, регистрации и выхода пользователя из приложения.

^[6]

Слишком много запросов

В этом проекте я пытаюсь масштабировать свои идеи. В настоящее время к базе данных осуществляется слишком много запросов. Так, если бы у приложения было сто пользователей, я бы просто сошел с ума, пытаясь узнать, сколько запросов к базе данных выполняется каждые несколько секунд. Сейчас клиент обновляет статус сообщений каждые 10 минут. Кроме того, пост циклически определяет, был ли он просмотрен пользователем. Во время каждой проверки происходит запрос к базе, это выполняется в соответствии с текущим фильтром. И все это значительно нагружает сервер.

Все, что описано выше, — лишь примеры проблем, с которыми я все время сталкиваюсь. Я не могу описать их в полном объеме. Тем не менее сейчас я размышляю над тем, чтобы документировать мои проблемы и решения. Надеюсь, что все это поможет другим программистам увидеть и понять мои ошибки и избежать собственных. Я знаю, что если буду использовать комбинацию Redis и MySQL или Postgres, то смогу ускорить выполнение запросов. Но пока что остановлюсь на этом.

Надеюсь, что вам понравилась статья и вы смогли почерпнуть что-либо полезное для себя.

Skillbox рекомендует:

• Онлайн-курс «Профессия frontend-разработчик» ^[7].
• Образовательный онлайн-курс «Профессия веб-разработчик» ^[8].
• Практический курс «Мобильный разработчик PRO» ^[9].

Автор: skillbox

Источник ^[10]