Цель дипломного проекта — создать веб-приложение, которое будет работать как облачное хранилище. Приложение позволит пользователям отображать, загружать, отправлять, скачивать и переименовывать файлы.
Вам предстоит:
- Создать комплексное веб-приложение, включающее:
- бэкенд на языке Python с использованием фреймворка Django и СУБД PostgreSQL;
- фронтенд на языках JavaScript, HTML, CSS с использованием библиотек React, Redux, React Router.
- Развернуть созданное веб-приложение на платформе reg.ru.
В результате выполнения этого задания вы:
- получите опыт разработки комплексного приложения, включающего в себя бэкенд и фронтенд;
- примените знания языка Python и фреймворка Django при разработке бэкенда;
- примените знания языка JavaScript и библиотек React при разработке фронтенда;
- получите опыт развёртывания приложения в облачной инфраструктуре reg.ru;
- получите возможность использовать этот проект в своём портфолио разработчика.
- Освоены все модули профессии в объёме обязательных требований по сдаче ДЗ и курсовых работ.
- Освоена самостоятельная установка и настройка инструментов, перечисленных в следующем разделе. Имеются навыки работы с ними, необходимые для проекта.
- Техника и базовое ПО, которые используются при выполнении задания, соответствуют требованиям необходимых инструментов.
Если все этапы чеклиста пройдены, то вы можете начинать работу над проектом. Желаем успехов.
- Для работы над различными частями проекта возможно использование единой IDE, например PyCharm или VS Code, а также текстового редактора по вашему выбору.
- Можно применять отдельные инструменты для разработки бэкенда и фронтенда: например, PyCharm для бэкенда и VS Code для фронтенда.
- В проекте рекомендуется использовать версии фреймворков и библиотек, актуальные на момент создания разработки: например, Python версии не ниже 3.10, Django не ниже 3.0, Node.js не ниже 18.0, React не ниже 18.0, Webpack не ниже 5.0.
- Работа над проектом ведётся с использованием системы контроля версий Git с размещением результатов в публичном(ых) репозитории(ях) автора на github.com.
- Публиковать в репозитории необходимо не только окончательные версии файлов, но и промежуточные результаты с возможным тегированием стадий разработки.
- Проект может быть опубликован как в едином монорепозитории, содержащем код бэкенда и фронтенда, так и в двух отдельных репозиториях. Разбиение кода на большее количество репозиториев (например, с выделением библиотек и модулей) не рекомендуется, поскольку это существенно усложнит работу на стадиях разработки, развёртывания и проверки результатов.
- Допускается использование дополнительных инструментов и модулей, не перечисленных в задании, если это необходимо для реализации требуемой функциональности и существенно не усложняет ведение проекта и его дальнейшее развёртывание на открытых платформах.
- Не допускается применение инструментов и библиотек, требующих оплаты или заключения лицензионных договоров при использовании в открытых проектах такого масштаба.
- Не допускается привлечение дополнительных ресурсов, которые потребуют существенных трудовых и финансовых затрат на их организацию и развёртывание при проверке работоспособности проекта.
Вам необходимо разработать приложение, состоящее из следующих основных блоков пользовательского интерфейса:
1. Основная страница приложения.
Основная страница должна содержать:
- общую информацию о приложении, необходимую пользователю;
- кнопку или ссылку для перехода на форму регистрации пользователя с заданием минимального набора данных: логин, полное имя, email, пароль.
При этом должны проверяться основные ограничения на значения указанных полей:
- логин — только латинские буквы и цифры, первый символ — буква, длина от 4 до 20 символов;
- email должен соответствовать формату адресов электронной почты — для проверки можно использовать регулярные выражения;
- пароль — не менее 6 символов: как минимум одна заглавная буква, одна цифра и один специальный символ.
При несоответствии требованиям в форме должны отображаться определённые информативные сообщения с возможностью исправления данных и их повторной отправки на сервер;
- кнопку или ссылку для перехода на форму аутентификации с вводом логина (проверяется его наличие в БД) и пароля (проверяется его правильность). Результат неуспешной проверки должен отображаться в форме с возможностью повторной отправки на сервер. При успешной аутентификации необходимо осуществить переход на страницу в зависимости от прав пользователя в системе.
2. Административный интерфейс системы для настройки её параметров и управления пользователями и их файловыми хранилищами.
В эту часть приложения могут войти только пользователи, имеющие признак «администратор» в списке пользователей:
- список пользователей с выводом признака «администратор» и информации, указанной пользователем в форме регистрации (кроме пароля). В списке должна быть возможность удаления пользователей и изменения значения признака «администратор»;
- в списке пользователей также должна отображаться информация об их файловых хранилищах: количество и размер файлов, ссылка для перехода к интерфейсу управления этими файлами.
3. Интерфейс управления файловым хранилищем.
Вход в интерфейс доступен для любых пользователей. При этом администратор должен иметь право управления хранилищами любых пользователей, включая своё собственное. Обычные пользователи должны иметь доступ только к своему хранилищу:
- в интерфейсе необходимо отображение списка файлов, загруженных пользователем в хранилище, с основной информацией о них: имя файла, комментарий, размер, дата загрузки, дата последнего скачивания;
- для каждого файла должны быть доступны следующие операции: удаление, переименование, просмотр (в браузере или через загрузку на локальный диск), копирование специальной ссылки на файл для предоставления доступа другим пользователям или использования его в качестве ресурса в веб-приложениях;
- необходимо реализовать возможность загрузки нового файла в хранилище с указанием комментария.
Общие требования к интерфейсу приложения:
- должна быть максимально реализована концепция SPA (single page application) — весь переменный контент на странице (списки пользователей и файлов и т.п.) формируется кодом на JavaScript с использованием библиотеки React. Для получения данных необходимо задействовать асинхронные API-вызовы к серверу приложения;
- все страницы приложения должны содержать навигационное меню, формируемое в зависимости от состояния аутентификации пользователя: кнопки «Вход», «Выход» и «Регистрация»;
- время, отводимое на дипломную работу, не предполагает существенных усилий по оформлению приложения с использованием графики, внешних библиотек элементов и т. п. Однако интерфейс приложения должен быть логичным и интуитивно понятным пользователю, имеющему опыт работы с аналогичными веб-приложениями.
-
Реализация на Python с использованием фреймворка Django и СУБД Postgres для хранения информации.
-
Настройки приложения, такие как параметры подключения к БД, размещения файлового хранилища и т. п., выделены в коде в отдельный модуль.
-
Загрузка статических ресурсов (HTML, CSS, JS-файлы фронтенда), а также API-вызовы обрабатываются единым сервером.
-
В проекте созданы все миграции, необходимые для инициализации БД в работоспособное состояние, — создание БД, таблиц, пользователя admin с правами администратора.
-
Все API-вызовы соответствуют семантическим правилам для REST API, для обмена данными между фронтендом и бэкендом используется формат JSON.
-
Сервер содержит реализацию бэкенда для двух основных блоков приложения: административный интерфейс и работа с файловым хранилищем.
-
Административный интерфейс включает следующие функции (конкретные API-вызовы вам необходимо спроектировать самостоятельно):
- регистрация пользователя — с валидацией входных данных на соответствие требованиям, описанным выше;
- получение списка пользователей;
- удаление пользователя;
- аутентификация пользователя;
- выход пользователя из системы — logout.
Общие комментарии к этому блоку:
- данные о пользователях должны храниться в таблице(ах) БД в полях, имеющих соответствующие им типы: логин, полное имя, email, пароль, признак администратора, путь к хранилищу пользователя относительно общего пути к хранилищу файлов;
- все вызовы, кроме регистрации пользователя, требуется защитить проверкой аутентификации пользователя в системе;
- функция удаления пользователей должна быть доступна только пользователю, имеющему признак администратора;
- ошибки должны возвращаться из API в виде соответствующих статус-кодов, а также в формате JSON.
- Блок работы с файловым хранилищем содержит следующие функции (конкретные API-вызовы вам необходимо спроектировать самостоятельно):
- получение списка файлов пользователя;
- загрузка файла в хранилище;
- удаление файла из хранилища;
- переименование файла;
- изменение комментария к файлу;
- скачивание файла;
- формирование специальной ссылки на файл для использования внешними пользователями;
- скачивание файла через специальную ссылку, используемую внешними пользователями или веб-приложениями.
Общие комментарии к этому блоку:
- все функции работы с хранилищем должны проверять права доступа пользователя к хранилищу;
- необходимо, чтобы администратору была доступна работа с хранилищем любого пользователя — функция получения списка файлов должна принимать параметр с указанием хранилища, если пользователь — администратор;
- файлы должны сохраняться на диске сервера под уникальными именами в системе папок, не допускающей конфликтов имён в случае, если разные пользователи загружают файлы с одинаковыми именами;
- для каждого файла в БД должна сохраняться следующая информация: оригинальное имя файла, размер, дата загрузки, последняя дата скачивания, комментарий, путь к файлу в хранилище, специальная ссылка, по которой файл может быть скачан внешним пользователем;
- необходимо, чтобы базовая папка для хранения файлов настраивалась как параметр системы;
- специальная ссылка на файлы должна формироваться в максимально обезличенном виде, т.е. не содержать в себе имени пользователя, информации о его хранилище и оригинальном имени файла;
- необходимо, чтобы при скачивании файла по такой ссылке он выгружался сервером с указанием оригинального имени.
Общие требования к серверу:
- состояние аутентификации пользователя должно отслеживаться через сохранение информации о сессии;
- все API-вызовы должны проверять права доступа пользователя и возвращать соответствующие ошибки через HTTP-статус и сообщение в формате JSON;
- все события сервера должны логироваться путём вывода на консоль сообщений «debug», «info», «warning», «error» с указанием даты и времени, содержать информацию, достаточную для анализа работоспособности и отладки сервера.
Примечание
Для лучшего понимания задачи рекомендуем ознакомиться с функционалом существующих аналогичных проектов, например Google Drive, Яндекс Диск, Dropbox и т. п. Поскольку время, отводимое на работу над проектом, ограничено, предполагается реализация только основных функций в упрощённом варианте.
- Опубликуйте все изменения в файлах проекта в публичном(ых) репозитории(ях) на github.com. Убедитесь, что репозитории содержат действительно последние версии со всеми изменениями.
- Попробуйте самостоятельно с нуля развернуть приложение, следуя инструкции, описанной вами в README.md. Убедитесь, что приложение разворачивается успешно, что оно работоспособно, протестируйте основные функции.
- Приложите в личном кабинете ссылки на репозиторий(ии) и развёрнутое приложение или укажите, что приложение может быть развёрнуто вами в течение 1 рабочего дня по запросу проверяющего.
- Отправьте дипломную работу на проверку.
- В случае возвращения проекта на доработку и устранения замечаний выполните необходимые действия в короткий срок и повторно сдайте работу. Если потребуется что-то уточнить и задать какие-либо вопросы по результатам проверки, свяжитесь с руководителем вашего дипломного проекта.
-
Результаты работы должны быть сданы в виде ссылок на публичный(е) репозиторий(и) с кодом на github.com, а также на развёрнутое приложение на reg.ru.
-
В корневой папке репозиториев должны обязательно содержаться файлы README.md с детальным описанием структуры папок и файлов проекта, а также инструкции по его развёртыванию и запуску, достаточно подробные для выполнения специалистом, прошедшим профессиональное обучение.
-
В случае применения дополнительных инструментов, которые не изучались в программе, должны быть приложены ссылки на документацию по их установке и использованию.
-
Если код фронтенда и бэкенда опубликован в раздельных репозиториях, общие инструкции по развёртыванию приложения должны быть описаны в README.MD в репозитории с бэкендом, а в репозитории с фронтендом должны быть инструкции по сборке и подготовке артефактов фронтенда, необходимых для развёртывания.
-
Для минимизации затрат на использование ресурсов платформы reg.ru в период проверки работ допускается развёртывание приложения на reg.ru в момент, согласованный с руководителем диплома, при условии, что такое развёртывание было заранее отработано и не занимает продолжительное время.
-
В сданной работе должен быть полностью реализован соответствующий требованиям функционал из разделов, помеченных как обязательные, и может быть частично или полностью реализован дополнительный функционал.
-
Поскольку профессия fullstack-разработчика предполагает владение всеми технологиями, используемыми при разработке комплексных приложений с пользовательским интерфейсом, оценке подлежит также внешний вид приложения и удобство пользования им. Недостатки, которые ведут к существенным трудностям в работе пользователя с приложением, могут быть основанием для отправки проекта на доработку и устранения замечаний. При этом дипломный руководитель будет исходить из того, что оцениваемое приложение не является коммерческим продуктом для конечного пользователя, его использование предполагается опытными ИТ-специалистами. Рекомендуется, чтобы все элементы интерфейса приложения, которые могут вызвать сложности у такого пользователя, были снабжены явными или всплывающими подсказками, а также описаны в README.md.
-
При проверке развёрнутое приложение должно быть работоспособным в объёме реализованного обязательного функционала.
-
Развёртывание приложения должно повторно осуществляться не его разработчиком по инструкциям, содержащимся в README.md, без использования каких-либо инструментов или зависимостей, не описанных в README.md. Результатом такого развёртывания должно стать работоспособное приложение, реализующее обязательный функционал.