Какой стек технологий выбрать для разработки веб-приложения по учету успеваемости студентов?

Question

[Booster_AK79]

Разрабатываю веб-приложение по учету успеваемости студентов.
Основные функции:
• регистрация/авторизация пользователей;
• добавление/удаление записей;
• формирование отчета в формате docx.

Это дипломная работа и требований по языку и фреймворку нет. Из-за этого не могу определиться со стеком бэка. Единственное, что выбрал архитектурный стиль REST API.

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

Сейчас рассматриваю следующие технологии: ASP.NET core, Blazor, Django Rest Framework, FastAPI. Почему выбраны они, т.к. на С# и Python делал лабораторные (консольные приложения и т.д.), есть понимание. Также смотрю на Node.js, Laravel и Go. С JS немного знаком, есть ощущение, что пойму его, Laravel и Go не изучал.

У меня следующие вопросы к сообществу:
1) Нужна ли асинхронность, исходя из функций приложения?
2) Что лучше выбрать из перечисленного стека, если необходимо представить приложение в короткие сроки?
3) Исходя из функций приложения, это будет SPA (одностраничное приложение) или PWA (многостраничное приложение)?
4) В случае выбора Blazor, то что лучше Blazor WebAssembly или Blazor Server?
5) Если возвращаться на DRF, то возможно ли создание веб приложения только на нем + фреймворк на фронте (Vue/React)? Или же надо использовать обычный Django + DRF + фронт?

Comments

[Алекс Глебов]

Не поверю, что Django не поддерживает асинхронные очереди

[Adamos]

Алекс Глебов, для школьного автобуса, как правило, вообще неважно, амфибия он или нет.

[DevMan]

Алекс Глебов,зачем там асинхронность вообще?

[Алекс Глебов]

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

Answer 1

[Adamos]

Вам, молодой человек, надо не "что лучше", а "что потяну".
Без фреймворка с никаким опытом шансов сделать что-либо в хоть сколько-нибудь разумные (не то что короткие) сроки тут нет. Так что выбор между Джангой и Ларой. Ни разу не нюхавшему Пых за Лару браться бессмысленно, остается Джанга. Но с опытом "поделал лабы" и отсутствием понимания архитектуры сайта (база, например, не указана вообще) заикаться про "короткие сроки"...

Comments

[DevMan]

как–то странно: не нюхал, но лару налево, джанго зайдет.

[Adamos]

DevMan, прочитайте вопрос. Питон студень хотя бы видел, пых - даже названия, похоже, не знает.
С Джангой уже что-то как-то возится. Есть смысл ему ее бросать ради чего-нибудь другого? Я не вижу.

[DevMan]

Adamos, я не вижу смысла вообще возиться, ибо в любой среде чел ни о чем.

[Adamos]

DevMan, так здесь никого не волнует, чего он в результате добьется.
Мы просто показываем путь тому, кто все-таки хочет идти.
А вы сидите на обочине и экзистенциально плюете в канаву ;)

[DevMan]

Adamos, что есть, того не отнять)

[Дмитрий]

опа, ДевМан вернулся

Answer 2

[Everything_is_bad]

Django и DRF прекрасно подойдут для это задачи, как и всё остальное перечисленное тобой. Так же не понятно, зачем тебе тут асинхронность.

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

то что лучше знаешь.

Исходя из функций приложения, это будет SPA (одностраничное приложение) или PWA (многостраничное приложение)?

без разницы, но PWA это не то что ты описал, а REST API подразумевает, что сервер возвращает данные, а не полностью cгенерированный html

Если возвращаться на DRF, то возможно ли создание веб приложения только на нем + фреймворк на фронте (Vue/React)? Или же надо использовать обычный Django + DRF + фронт?

ну ка расскажи, чем "DRF + фреймворк на фронте (Vue/React)" отличается от "Django + DRF + фронт"?

Answer 3

[alexalexes]

Это дипломная работа и требований по языку и фреймворку нет. Из-за этого не могу определиться со стеком бэка.

Пишите пояснительную записку. Вообще не отвлекайтесь на разработку. Оставьте реализацию на уровне статичных HTML. Для защиты диплома что-то реализовывать, кроме проектной документации - только терять время.

Answer 4

[ThunderCat]

• регистрация/авторизация пользователей;
• добавление/удаление записей;
• формирование отчета в формате docx.

практически все что перечислено в качестве инструментов - хватает или избыточно.

1) Нужна ли асинхронность, исходя из функций приложения?

Нет, тем более для подхода через REST API.

2) Что лучше выбрать из перечисленного стека, если необходимо представить приложение в короткие сроки?

Как самый простой вариант смотрится лара + 4 готовых модуля, 2 из которых вроде даже идут из коробки, остальные добиваются 1 командой композер инсталл %пакетнейм%.

3) Исходя из функций приложения, это будет SPA (одностраничное приложение) или PWA (многостраничное приложение)?

Это не противопоставление, это вообще не взаимосопоставимые технологии. PWA может быть SPA, может не быть... PWA это вообще не про "многостраничность".

Остальное не скажу, так как не в теме.

Comments

[Василий Банников]

Как самый простой вариант смотрится лара + 4 готовых модуля, 2 из которых вроде даже идут из коробки, остальные добиваются 1 командой композер инсталл %пакетнейм%.

Каждый хвалит своё болото)
В дотнете так вообще всё из коробки, включая фронт и работу с базой. Даже dockerfile тебе сгенерит.

[ThunderCat]

Василий Банников, да не вопрос, я же говорю - я со своей колокольни так вижу, в чем не разбираюсь или плаваю - не лезу с советами )

[Василий Банников]

ThunderCat, кстати недавно имел удовольствие поработать с symfony (с ларой пока ещё нет).
Что-то я больше не верю в ультимативную простоту php.
Очень много пакетов, очень много инструментов в экосистеме, очень много конфигов для них всех, сам конфиг для композера чего стоит, а ведь ещё на уровне системы зависимости есть оооооой.
Сложнее пока что только C++ видел.

А задача была не такая уж и сложная - Dockerfile собирался 10 минут и нужно было его оптимизировать (кстати, таки успешно уменьшил сборку до 2минут с учётом скачивания всяких пакетов и образов)

[ThunderCat]

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

Очень много пакетов,

Так в этом смысл, причем пакеты вполне совместимы между фреймворками, лара кстати кучу пакетов из симфонии таскает.

очень много инструментов в экосистеме,

Всмысле? Я мож сильно отсталый, но в целом мне хватает редактора кода и опенсервера, ну и еще композер нужен. Вроде все, или что-то другое подразумевалось?

[Василий Банников]

ThunderCat,

Всмысле? Я мож сильно отсталый, но в целом мне хватает редактора кода и опенсервера, ну и еще композер нужен. Вроде все, или что-то другое подразумевалось?

Ну вот например конфиги, которые я вижу конкретно в том проекте, с которым я столкнулся:
1. composer
2. Makefile (для того чтобы запускать миграции через bin/console)
3. webpack (считаю справедливым, так как это webpack, который сгенерирован symfony/encore)
4. Какой-то symfony.lock
5. Отдельно в bin лежит phpunit (считаю отдельным инструментом, так как не поставляется из коробки)
6. Некий bin/console с помощью которого запускаются миграции в доктрине
7. И ещё пятьдесят yaml файлов в папке config с помощью которых как-то конфигурируются отдельные модули (twig, monolog, та же доктрина)

Про то что рядом ещё у нас docker в котором 10 строчек занимает установка всех зависимостей только для того чтобы далее можно было запустить докер - я промолчу, как и про конфиги, которые нужны для фронта (который конкретно в этом случае состоит из твига и пары виджетов на реакте).
Опять же аналогичные sudo apt install php-* приходится делать и на машине для разработки, чтобы это всё работало.

Причём проект не очень то и экзотичный - обычный сайт-справочник аля вики со статьями и картинками.

PS: я не говорю, что так абсолютно во всех пхп-проектах. Конкретно этот выглядит скорее как очень переусложнённая аномалия. Но сам факт, что так можно всё усложнить...

[ThunderCat]

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

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

Отдельно в bin лежит phpunit (считаю отдельным инструментом, так как не поставляется из коробки)

Средства для юнит тестов - ну хз, не в курсе как это реализуется в дотнете, но разве там это как-то сильно иначе делается? Кроме того, вы же в курсе, что тестирование мягко говоря делают не все )) Некоторые проекты его вообще игнорируют, а некоторые ограничиваются функциональными тестами. Хотя если уж взялись за разработку под симфони, значит готовы соблюдать рекомендации разработки в максимальном объеме, ибо движок к этому требователен.

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

И ещё пятьдесят yaml файлов в папке config с помощью которых как-то конфигурируются отдельные модули

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

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

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

[Василий Банников]

ThunderCat,

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

Речь не о наличии композера вообще - я то двумя руками за.
Я про его сложность и что он вообще делать может.

Средства для юнит тестов - ну хз, не в курсе как это реализуется в дотнете, но разве там это как-то сильно иначе делается?

Встроено в SDK. Никакие дополнительное файлы в проекте держать не нужно.
Просто ввёл dotnet test и вот у тебя тесты крутятся.

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

Ну это интересный пункт, тк тут что-то как-то не особенно соблюдается)

Хм, а как конфигурируется дотнеты?

То что нужно конфигурировать - через файл или переменные среды.
Но не пятьдесят же штук.

Константные вещи вообще в коде записываются.

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

Это крайне непривычно, ведь когда ты берёшь какой-нибудь FROM microsoft-dotnet-runtime:8.0 - ты получаешь абсолютно все необходимые зависимости.
А тут тебе нужно ещё

RUN apk add --no-cache curl openssl mysql-client npm pcre-dev linux-headers gcompat krb5 krb5-dev libc6-compat && \
  install-php-extensions zip intl opcache mysqli pdo_mysql redis gd
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

Это я ещё не рассказал про то что ENV=dev composer install работает нормально, а ENV=prod composer install - падает.

[ThunderCat]

Я про его сложность и что он вообще делать может.

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

То что нужно конфигурировать - через файл или переменные среды.
Но не пятьдесят же штук.

Это опять же больше особенность фреймворка, нежели пыха в целом, в той же ларе по умолчанию 90% конфигов берется из енв файла, а мелочи прописываются в 2-3 конфигах в виде массивов, то есть это не типичное пыховое поведение ) Просто в симфонии ты можешь тонко настроить все компоненты какие только есть. По умолчанию их и трогать вроде особо не нужно, если окружение стандартно настроено... Думаю в дотнете это тупо скрыто в каких-то недрах, где в случае чего все это тоже как-то тюнится.

когда ты берёшь какой-нибудь FROM microsoft-dotnet-runtime:8.0 - ты получаешь абсолютно все необходимые зависимости.

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

Встроено в SDK. Никакие дополнительное файлы в проекте держать не нужно.
Просто ввёл dotnet test и вот у тебя тесты крутятся.

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

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

Answer 5

[Василий Банников]

1. Раз дипломная работа, а не продакшен, то совершенно не важно, что лучше/хуже.
Отказ от DRF в рамках дипломки просто из-за того что в нём нет async/await - это странное решение.

1) Нужна ли асинхронность, исходя из функций приложения?

И уж тем более странным выглядит последующий вопрос после такого отказа.

Асинхронность в вебе - это большой плюс, но точно не решающий фактор.

2) Что лучше выбрать из перечисленного стека, если необходимо представить приложение в короткие сроки?

То что лучше знаешь, либо обладаешь собственной внутренней мотивацией изучить в эти самые кратчайшие сроки.

3) Исходя из функций приложения, это будет SPA (одностраничное приложение) или PWA (многостраничное приложение)?

1. PWA - Это не "многостраничное приложение". Иди гугли и снова читай, но уже внимательнее.
2. SPA и PWA ортогональны и выбирать между ними - это как выбирать между тёплым и мягким.

Исходя из функций - совершенно не важно, как вообще будет работать это приложение, SPA/PWA/SSR или вообще по классике с полной перезагрузкой.
Исходя из функций - это может быть даже полностью консольное приложение. Других требований я не вижу.

4) В случае выбора Blazor, то что лучше Blazor WebAssembly или Blazor Server?

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

5) Если возвращаться на DRF, то возможно ли создание веб приложения только на нем + фреймворк на фронте (Vue/React)?

Можно, разрешаю.

Comments

[Booster_AK79]

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

"лучше" по какому параметру?

Если использовать Blazor WASM то с одной стороны это автономность, т.е. можно работать offline, с другой это медлительность, т.к. большой размер файлов, загружаемых в начале при запуске. Blazor Server же полностью зависим от сервера. Поэтому соглашусь, что гибрид лучше.

C# и Python знаю, с JS как вы говорите есть "внутренняя мотивация", что смогу изучить. Поэтому думаю, что лучше будет. Все-таки этим приложением будут пользоваться.

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

[Василий Банников]

Booster_AK79,

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

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

[Василий Банников]

Booster_AK79,

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

Проблема blazor wasm далеко не в этом.
Если на твоём сайте есть картинки, то их размер многократно превысит размер этих wasm-ов.
Главная проблема в том, что это не seo-friendly, что является очень критичным для некоторых проектов.

Answer 6

[tyxeo]

проще всего и быстрее на чистых языках - js php

фреймворки используют в проф индустрии для определенных целей
тебе это не нужно совсем

Comments

[alekssamos]

Ну как это не нужно?
Берём ту же самую регистрацию и авторизацию.
Во фреймворках это уже есть из коробки, ничего придумывать не нужно.
А на чистых языках, естественно, это надо будет тоже самому писать.

[tyxeo]

alekssamos, таклентяи думают

регистрация и авторизация это как 2 х 2
ради этого впадать в это безумие нет смысла