Создание веб-приложения: точка зрения новичка

В связи с тем, что волна Covid-19 распространяется по миру, как ночь в вечер быстро заходящего солнца, у меня есть время и вдохновение. Прошло много времени с тех пор, как я что-то публиковал на Medium, и здорово, что снова пишу.

Ссылка на демонстрационный сайт.

Ссылка на репозиторий github.

Размышления

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

В этом посте я буду размышлять над основными выводами / мыслительными процессами, которые происходили в ходе проекта. Итак, чего вы, как читатель, можете ожидать от этого поста? Что ж, если вы изучаете веб-фреймворки, как я, то, возможно, этот пост в какой-то степени поможет вам в том, на что следует обратить внимание в вашем первом проекте. Для каждого вывода, где были источники, из которых я брал ссылки, будут предоставлены ссылки. Попутно я также набирал курс Udemy для дополнительной помощи: Полный курс JavaScript 2020 от Йонаса Шмедтманна.

Кредиты

Огромная благодарность Кевину Хенгу (которого наши друзья нежно называют «Дисней») за его сотрудничество и личную заинтересованность в этом проекте. В посте ниже всякий раз, когда упоминается термин «мы», он будет относиться к комбинации наших многочисленных ночей тяжелой работы.

Фокус

Мы поставили перед собой несколько целей:

  1. Чтобы узнать больше о интерфейсной разработке, внутренней разработке и просто общих значениях веб-разработки.
  2. Чтобы написать код Javascript (учитывая его популярность в настоящее время).
  3. Создать функциональный сайт.
  4. Чтобы развернуть указанный веб-сайт и позволить пользователям использовать его.

Введение и контекст

Вдохновение пришло, когда я думал о подарке на день рождения моей девушке. Во время написания этой статьи мы все застряли дома из-за COVID-19, поэтому я подумал, что лучший подарок будет в форме объединения честных и значимых пожеланий ее друзей и семьи. . У меня был очень сжатый срок (менее двух недель), и у меня почти не было знаний в разработке чего-либо, связанного с Интернетом, поэтому я обратился за помощью к коллеге-энтузиасту веб-разработки, Disney.

Идея проста: это простое приложение CRUD (хотя в приложении фактически отсутствует часть обновления и удаления для пользователей, это могли сделать только Disney и я) позволит пользователям написать пожелание на день рождения и прикрепить изображение. Пользователи также смогут просматривать и искать пожелания / положительные сообщения от друзей и семьи в надежде, что это улучшит мрачное настроение необходимости застрять дома на день рождения.

Вывод 1: Общая архитектура

Вначале это был один из аспектов, который мы сильно недооценили, что было чрезвычайно дорого с точки зрения потерянных человеко-часов. Первая мысль, которая пришла в голову, заключалась в том, чтобы просто использовать CMS, например Wordpress или Wix, но где в этом радость? Мы хотели создать что-то свое и попутно освоить новые навыки.

На нашей чертежной доске первоначальная версия приложения была насыщена Django, где мы соединили наш бэкэнд и фронтенд вместе, используя функции OOB, которые Django предоставляет, такие как его формы и язык шаблонов. Однако по мере того, как мы медленно создавали приложение, мы обнаружили, что функции OOB, предоставляемые Django, были немного жесткими. Например, чтобы отобразить нашу форму публикации, мы могли бы просто использовать теги шаблона, такие как {{form | crispy_form}}. Результат был менее желательным с точки зрения внешнего вида, поэтому мы написали форму сами. Еще одна небольшая проблема заключается в том, что мы не хотели, чтобы страница обновлялась каждый раз, когда пользователь хочет получить дополнительные данные.

На этом этапе мы решили провести еще немного исследований по различным философиям архитектуры и, наконец, остановились на одном: Django и Django REST Framework в качестве автономного API + статический сайт в качестве автономного SPA. Теперь, в этот момент, мы отмечаем, что могут возникнуть опасения по поводу безопасности, если с ними не обращаться должным образом, но мы рассудили, что здесь нет конфиденциальной информации, и ее распространение будет максимально ограничено для семьи и друзей. Кроме того, мы отключаем API после того, как пожелания дня рождения будут сопоставлены. Поэтому, помня об этом, мы решили продолжить и начать перестраивать наше приложение с нуля.

Вывод 2а: Джанго

Здесь особо нечего сказать, документация по Django и DRF настолько зрелая и хорошо написана, что нам почти не пришлось ссылаться ни на что другое.

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

Вау, это довольно лаконично. Мы получили огромное количество бесплатно, и наш код выглядит как хороший, чистый, идиоматический Django. - Документация DRF

Вывод 2b: Хранение файлов изображений на S3

Поскольку мы уже создаем API, почему бы не пойти дальше? Облачные вычисления и AWS сейчас в моде, поэтому это хорошая возможность изучить некоторые связанные с ними функции. В нашем приложении у пользователей есть возможность отправить изображение с пожеланием на день рождения. Вместо того, чтобы хранить его в статической папке / img /, мы решили просто пойти дальше и использовать для этого AWS S3. Вначале весь интерфейс AWS был чрезвычайно сложным, так как было много продуктов. Однако, имея правильные инструкции и документацию, мы довольно скоро начали свой путь.

Неудивительно, что существует множество руководств по использованию S3 с Django. Опять же, Django выполняет большую часть работы, абстрагируя низкоуровневые вещи и просто предоставляя нам максимальную функциональность для как можно меньшего количества строк кода (хотя наши первоначальные опасения, изложенные в выводе 2а, все еще остаются в силе).

Мы нашли этот учебник Кори Шафера очень полезным (у Кори есть хороший учебник по использованию Django).

Вывод 3а: HTML / CSS / Javascript

Теперь, когда у нас есть работающий API, нам нужно было интерфейсное приложение, которое могло бы подключаться к нему. Когда мы начали перестраивать приложение с новой архитектурой, у нас почти не было практических знаний о HTML / CSS / Javascript. Наш первоначальный CSS обрабатывался в основном с помощью Bootstrap, часть HTML была просто нам интересно, как центрировать div внутри div, и мы мало что знали о Javascript с самого начала. Так началось трудное путешествие, чтобы узнать практически все. Многие ночи были потрачены на изучение концепций, передовых практик и, в основном, того, как писать красивый, чистый и лаконичный код на этих языках.

Для нас было очень важно сделать общий макет и дизайн адаптивным. Мы предвидим, что многие пользователи будут получать доступ к нашему приложению через свои телефоны или планшеты, поэтому были тщательно продуманы условия, чтобы дизайн статической страницы мог справиться с этим. Для этого мы в основном использовали css flexbox и поиграли с атрибутом media. Дизайн был вдохновлен лентой Twitter. Наш главный ресурс по изучению CSS - это различные видео от Traversy Media.

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

Говоря о Javascript, мы также приложили некоторые усилия, чтобы понять версии Javascript, выходящие за рамки ES5. Например, работа с Promises и async / await для асинхронных задач, let и const для определения переменных, а также с Array.prototype.includes (что очень удобно).

Вывод 3б: Github

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

Переход на Github на удивление довольно плавный. Да, некоторые конфликты необходимо было разрешить, пока мы продвигались через процесс отправки и выполнения запросов на вытягивание из наших различных веток для управления, но в целом это было значительным повышением производительности, и мы были очень благодарны за то, что испытали это. Вот ссылка на Гарвардский курс CS50, где гениальный Брайан преподает Git и Github.

Вывод 4a: Архитектура MVC для нашего веб-интерфейса

После вывода 3а, мы были очень взволнованы тем, что начали кодировать на Javascript, это все равно что подружиться с самым крутым ребенком в городе. Не имея опыта в этом вопросе, через некоторое время наши файлы .js стали выглядеть как спагетти, как в чистой карбонаре с кусочками бекона. Это нас не устроило, и мы вернулись в комнату для исследований, чтобы выяснить, как лучше всего это сделать. В конце концов мы нашли шаблон проектирования, который соответствовал нашим потребностям: Модель-Представление-Контроллер.

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

Мы нашли курс Udemy (упомянутый выше) и этот ресурс особенно полезными.

Вывод 4b: Webpack, Babel, немного Node / NPM

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

Это была особенно трудная тема для нас, поскольку требовала от нас некоторого знакомства с инициализацией и использованием диспетчера пакетов узлов. С одной стороны, документация по webpack и babel была очень полезной, и оттуда нам очень помогли. Еще один ресурс, который очень помог в понимании этих технологий, - это видео Traversy Media.

Вывод 5: Развертывание нашего приложения

Есть множество способов сделать это. Мы провели небольшое исследование и выбрали следующее: развернуть наш API на Heroku, который по умолчанию поставляется с его базой данных PostgreSQL, а для нашего статического сайта мы просто собираемся развернуть его с помощью Github Pages. В целом процесс развертывания прошел без сбоев (уф), а подробная документация / учебные пособия только помогли нам облегчить нашу жизнь.

Ресурс для развертывания приложения Django на Heroku (Кори Шафер).

Ресурс как пользоваться страницами Github (опять же от замечательного Traversy Media).

Заключительные замечания

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

Со своей стороны, мы очень внимательно отслеживаем некоторые аспекты приложения, которые определенно можно улучшить.

  1. Аутентификация / безопасность - мы читали о таких вещах, как JWT, OAuth2, но поняли, что ради этого приложения мы оставим их в стороне и вместо этого исследуем их в будущем.
  2. Последние библиотеки JS - в этом приложении мы использовали обычный JS, но, конечно же, мы будем стремиться применить наши новые знания в Javascript для адаптации новейших веб-технологий в наших будущих проектах.
  3. База данных - в этом проекте мы использовали sqlite (в процессе разработки) и PostgreSQL по умолчанию, используемый Heroku для хранения наших данных. Не было написания кода SQL, так как это уже было обработано ORM Django. Это удобно, но для того, чтобы углубить наши знания о разработке полного стека, мы определенно хотим подробно изучить настройку и работу технологий баз данных.

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