MangaDB, моя собственная система отслеживания записей манги.

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

Предыстория:

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

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

Было сложно угнаться за более чем 6 сериями, особенно когда некоторым требовалось даже месяцы, чтобы выпустить новую главу!

Моя первая попытка управлять своим цифровым чтением:

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

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

Я попытался связаться с владельцем моего любимого сайта после того, как узнал, что некоторые веб-разработки предлагают мои услуги бесплатно, чтобы найти решение этой проблемы. Я так и не получил ответа.

Моя попытка решить проблему:

Если у вас есть проблема и навыки работы над ее решением, вам следует работать над ее решением самостоятельно!

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

API:

Я создал свой простой сервер, который будет подключаться к базе данных Mongo, размещенной на mlab, поэтому мне не придется беспокоиться и о размещении базы данных. В то время я был влюблен в Windows 10, поэтому я использовал cloud9 со своим собственным репозиторием для проекта, чтобы упростить среду, поскольку я предпочитаю кодировать в среде Linux. . Я создал файл .env для конфиденциальных данных и начал читать, как добавить информацию в базу данных.

Схема

В итоге я использовал MongooseJS и научился выполнять операции CRUD (создание, чтение, обновление, удаление) с помощью Mongoose. Я узнал о схемах и впервые их использовал. Мне пришлось пару раз обновить схему, когда я узнал о ней больше. Используя схему, я в основном выполнял проверку ввода с сервера до того, как данные действительно попадают в базу данных; если введены неверные данные, они не попадут, что было очень важно и круто.

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

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

Если вы можете добавить поддержку для одного пользователя, вы также можете добавить поддержку для двух; если вы добавите поддержку для двоих, то сможете добавить поддержку для всех, которые вам понадобятся в будущем.

Скороговорка архитектуры

Организация файлов - это то, чему я научился, когда создавал задачи микросервисов для FreeCodeCamp, я пытался узнать о модели, представлении, архитектуре контроллера (MVC) и других способах организации кода, и я просто пошел дальше и использовал то, что я нашел полезным от каждого метода, который позволил мне лучше организовать и сделать мой код читаемым не только для меня в будущем, но и для других возможных разработчиков, которые хотели внести свой вклад или просто проанализировать мою работу.

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

Я разделил код на контроллеры, тесты и модели, при этом сервер соединял все части вместе.

Каталог контроллеры содержал код, выполняющий действия. Я использовал разные файлы:

  • auth.js: для обработки аутентификации.
  • manga.js: для обработки функций, связанных с мангой, таких как операции CRUD.
  • user.js: для обработки всех операций, связанных с пользователем.
  • dbHelper.js: это специальный файл, поскольку название предполагает, что это файл, который содержит вспомогательные функции для всех операций в других файлах. Он содержит пользовательские функции, которые обрабатывают повторяющийся код, и разные функции.

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

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

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

Сервер

Изучение того, как аккуратно организовать свой код, позволило мне иметь одинаково организованный сервер / приложение. Хотя некоторые люди отделяют код сервера от остального кода, я храню свой сервер и маршрутизирую вызовы в одном файле. Это позволяет мне просматривать изображение всего приложения в одном файле, не оглядываясь по сторонам, что очень полезно, когда вы являетесь ведущим разработчиком и нет предыдущей документации, только комментарии, которые вы добавляете в код по мере того, как придумаете. Это.

Это действительно прекрасная вещь! Я объявляю и импортирую файлы и зависимости, экспресс, монго и т. Д. Затем я подключаюсь к базе данных. Строка 26 предназначена для целей безопасности, секретная переменная, не видимая в коде во избежание взлома, она не должна быть единственной мерой безопасности, которую вы реализуете в своих проектах.

Затем я настраиваю bodyparser и CORS, и как только все остальное настроено, я начинаю добавлять свои маршруты, они работают следующим образом:

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

наконец, я настраиваю и запускаю сервер внизу файла. Я всегда использую эту структуру.

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

Серверное тестирование

На более позднем этапе разработки я уже использовал почтальон для тестирования своего API, но я хотел попробовать автоматическое тестирование, поэтому я создал простой тестовый файл для сервера, который проверяет соединение для корневой каталог и путь / api. в основном он должен иметь код статуса 200, а тип содержимого должен быть файлом json. Это потому, что весь API возвращает файлы json в следующем формате, несмотря ни на что:

{
 success: success_status_code, 
 message: Custom_message_about_results,
 data: data_requested
}

Этот стандартизированный вывод был одним из последних изменений, которые я внес, когда работал над клиентским приложением, и мне приходилось обрабатывать различные типы json-объектов, которые я получал в зависимости от действия, это была проблема, которую мне пришлось вернуться и исправить сразу, до того, как кодовая база расширится.

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

Аутентификация пользователя

Сначала я использовал базовую auth0 для аутентификации пользователя, но затем я столкнулся с некоторыми проблемами с поддержанием активности сеанса. Я прочитал и осмотрелся, и у меня просто не получилось, я создавал API, мне не нужны были состояния, вот тогда я понял, что мне нужен RESTful API, а не просто программа на сервере. Я быстро наткнулся на JWT благодаря товарищу из лагеря, который показал мне быструю демонстрацию. Мы транслировали этот сеанс сопряжения, но сейчас он может быть потерян.

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

Смотрите код в auth.js.

Я использовал соль и разные секретные коды, в зависимости от того, где запущен код, там я попадал в безопасность.

Подтверждение адреса электронной почты

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

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

Вещи, которые я хочу реализовать

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

  • Обновления сервисов.
  • Подтверждение электронной почты при регистрации.
  • Приветственное письмо после успешной проверки учетной записи.
  • Токены сброса пароля.
  • До свидания, спасибо по электронной почте, когда пользователь решил удалить свою учетную запись.

Мне также пришлось бы создать механизм сброса пароля, который я не создавал из-за отсутствия поддержки по электронной почте, что в настоящее время означает, что если вы потеряли свой пароль, вам не повезло, если вы не убедите меня, что это на самом деле ваш аккаунт, тогда я могу помочь вам восстановить ваши данные.

Подробнее о безопасности

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

API был построен для проверки аутентифицированного пользователя и сравнения с пользователем из пути и переменной среды администратора, содержащей имя учетной записи администратора. Это позволяет API отказывать в доступе аутентифицированному пользователю, пытающемуся просмотреть данные другого пользователя; если только запрашивающий его пользователь не является администратором. Здесь абсолютные права администратора.

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

Технологии, используемые для API:

  1. Node.js
  2. Expressjs
  3. Git
  4. Heroku
  5. Облако 9
  6. MongoDB / Мангуст
  7. JSON
  8. Веб-токены JSON (JWT)
  9. ESLint
  10. Трэвис-Си
  11. NPM, Nodemon
  12. QuickEmailVerification
  13. bycrypt для узла
  14. Почтальон

Клиент

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

Здесь я должен был ответить на вопрос, как добавить интерфейс в свой API? Ответ был: нет! Просто создайте отдельный клиент, который будет использовать API как любое другое интерфейсное веб-приложение, которое я создавал ранее. Это означало, что мне понадобится мой собственный сервер, поскольку сайт не будет одностраничным приложением.

Я запустил сервер узла и решил использовать Jade, который позже был переименован в Pug, еще до того, как я закончил работу с клиентом. Для этой роли я хотел работать в команде, поэтому я создал комнату чата, чтобы попытаться набрать добровольцев, так как у меня было достаточно разработчиков, заинтересованных в том, чтобы я захотел создать клиента, в первую очередь, и все они были интерфейсными разработчиками, поэтому мне сказали, что они не могут помочь с моим списком дел для самого API.

Мне все еще не повезло, я начал сам и проработал прототип, используя sass и bootstrap, позже переключился на MaterializeCSS, а затем получил несколько советов и соединил несколько раз пытался работать некоторые изгибы. Однако я узнал там структуру файлов sass.

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

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

Я решил попробовать шаблон или генератор, поэтому в итоге я использовал Express Application Generator для создания сервера и начал с него.

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

Когда я начал работать с клиентом, я имел в виду следующее, что также было моим «коммерческим» шагом:

Мы можем создать столько клиентов, сколько захотим, используя любую технологию, о которой мы можем, мозги службы позаботятся, это API! у нас даже может быть несколько активных разных клиентов, чтобы удовлетворить предпочтения друг друга.

Имея это в виду, я сохранил свою первую версию в ветке, чтобы я мог переключить ветку на использование разных клиентов с помощью heroku. Я подумываю о создании нового маршрутизатора на основе реакции, редукции и реакции с рендерингом на стороне сервера. Раньше я хотел, чтобы с сервера выполнялось как можно меньше работы, и чтобы большая часть работы выполнялась в браузере, это позволило бы использовать офлайн-режим, который мне еще предстоит реализовать.