LINUX.ORG.RU

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

 , , , ,


2

3

Хочу сделать несколько простых веб сервисов (или как это правильно называется, когда есть веб фронт с заполнением чего-то, вычислением и представлением каких-то результатов?). Хочу именно сам, потому что и полезно, как вспомогательная деятельность, и интересно.

Более подробно: под мои задачи сделать веб страницу с полями, куда я ввожу какие-либо данные, которые заносятся в БД (sqlite, наверное, данных не так много, может на пару десятков тысяч строк), потом производятся некоторые расчеты, которые выводятся на страницу. Динамического обновления не надо, просто статика. Нажал - обновилась страница - результат показался. Ввел данные - нажал кнопку - данные отправились в БД. Красивостей особых не надо. По сути - заполнение бд, расчет, предоставление результата. Одна из крайне желательных фич, которую хочу внедрить, - выпадающий список с авто дополнением некоторых полей. Например, вводишь «карт», а тебе предлагают для дополнения из базы (это для связанных полей many-to-many), варианты «карта», «картошка», «картина» и т.д.

Что я немного умею: баш, питон (пара скриптов с простыми классами на пару тысяч строк).

Вопрос: что взять в качестве инструмента (вроде у питона есть фреймворки (джанго, фласк и т.п.)), но мне не хватает знаний/опыта понять, подходят ли они)? Оставить питон или взять какое-нибудь php? Может БД тоже другую? Мне не нужно перспектив разработчика, нужно чисто для себя и решить свои задачи при этом.

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

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

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

Перемещено hobbit из general

я делал в формате похожем на твой на связке фласк+мариадб. у последней даже есть своя библиотека для питона. хотя у питона по-моему «свои библиотеки» есть отовсюду. без каких-то лютых нагрузок всё будет чётко. вот только за выпадающие списки не подскажу. простой поиск сделать несложно, а автодополненние… думаю, тоже несложно, но я никогда не интересовался

flant ★★★
()

Оставить питон

this

взять какое-нибудь php?

Брось каку. На этом уже давно никто не пишет.

А так, Flask - хороший вариант. Базу данных можно любую, хоть sqlite, если нагрузки никакой не планируется. Можно и на Django замахнуться, если гулять дак гулять :)

th3m3 ★★★★★
()

Возможно, Django будет проще, т.к. в отличие от Flask есть встроенная админка.

И да - только не PHP. Ограниченная технология, пик популярности которой давно пройден, дальше предвижу только медленное угасание, как в своё время у Perl.

emorozov
()
Последнее исправление: emorozov (всего исправлений: 1)
Ответ на: комментарий от ggrn

fastapi - совсем не то же самое, что Flask. Общего у них только идея некоего минимализма и «конструктора».

Django — гораздо проще для новичка, т.к. не надо собирать конструктор, не зная, какие существуют варианты.

Магии в Django нет уже лет 14, но все ещё продолжают критиковать какой-то Django 0.95, выпущенный в 2006 году.

emorozov
()

Раз знаете питон, нечего трогать пыху, берите flask + sqlite

выпадающий список с авто дополнением некоторых полей

Какой-нибудь Ajax

Раз всё-равно придётся ковыряться с js, я бы сделал просто статичную html+css+js страничку и интеграцию с какой-нибудь бесплатной DBaaS типа fauna.com. Соответственно расчёты бы проводились на клиенте. А то вам ещё надо будет свой сервер настраивать, фу, не надо так в 21 веке.

mydibyje ★★★
()
Последнее исправление: mydibyje (всего исправлений: 3)

Звучит как будто Python ок :) Работа с sqlite (модуль sqlite3) есть в Python3 из коробки. Flask - весьма неплохая штука, хорошо документированная, думаю, разберетесь при желании. Кажется это все решает вашу задачу, кроме вот этой части:

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

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

PHP можно, но зачем? С Python будет быстрее и проще разобраться, имхо.

paddlewan
()
Ответ на: комментарий от mydibyje

Расчет на клиенте на JS? А какая мотивация? Чтобы что?

И второй вопрос: а зачем тут монга? Какую проблему она решит лучше sqlite3 при условии, что мы говорим о «нескольких десятках тысяч строк»? Модно - молодежно, конечно, NO SQL :) Но по сути, зачем тут «документы». Вопрошающий ничего такого про особенность хранимых данных не рассказывал, кажется.

paddlewan
()
Последнее исправление: paddlewan (всего исправлений: 1)
Ответ на: комментарий от mydibyje

Обойтись без JS с Django в простых случаях можно: https://github.com/adamchainz/django-htmx

Возможно, подобные интеграции есть и для Flask и для FastAPI, не проверял.

Автокомплит также есть из коробки в админке Django (по сообщению автора неявно, но возможно, этого будет достаточно в его задаче)

emorozov
()

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

firkax ★★★★★
()
Ответ на: комментарий от emorozov

Я выше указал: пхп - самый простой язык для случаев когда не нужна высокая нагрузка или высокая сложность. И твои «пики популярности» на это никак не влияют.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Чаще всего на выбор языка/технологии влияет более, чем один параметр. В пользу Python в данном случае говорит:

  1. Автор вопроса его уже знает на каком-то уровне
  2. Автор вопроса сможет получить новые знания, которые пригодятся ему дальше. Раз он уже использовал Python, значит планирует использовать дальше.
  3. Область применения PHP сильно ограничена, изучение его ради одного проекта не принесёт каких-либо выгод в будущем

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

Кроме того, я бы поспорил, что тот же Django сильно сложнее. Или даже вообще сложнее. Ну да, придётся научиться отделять мух от котлет, то есть не совать код в HTML и наоборот. Но это то, как оно и должно быть, потому что смешивание кода с представлением - это дорога в адский ад и эта «простота» потом очень дорого обходится, вплоть до полного переписывания проекта.

emorozov
()
Последнее исправление: emorozov (всего исправлений: 1)

питон (пара скриптов с простыми классами на пару тысяч строк).

Классы совсем не простые, но это так, отвлечение.

Python подходит отлично, посоветовал бы aiohttp + sqlalchemy, но сейчас есть альтернатива в виде fastapi + sqlalchemy с приличной документацией. Останется только набросать html-шаблоны.

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

aiohttp + sqlalchemy

Новичку предлагать сразу в асинхронщину? В неё и опытные-то не сразу вникают. Хотя не помню, м.б. aiohttp и синхронный код позволяет писать, использовал aiohttp раз в жизни, несколько лет назад.

emorozov
()
Ответ на: комментарий от emorozov

Автор вопроса его уже знает на каком-то уровне

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

Область применения PHP сильно ограничена, изучение его ради одного проекта не принесёт каких-либо выгод в будущем

Тут суть в том что пхп изучать не нужно, чтоб на нём писать.

придётся научиться отделять мух от котлет, то есть не совать код в HTML и наоборот

На простых одностраничных формах это одна из самых больших сложностей. Потому что всё остальное делается по принципу «пишу что думаю».

смешивание кода с представлением - это дорога в адский ад и эта «простота» потом очень дорого обходится, вплоть до полного переписывания проекта.

Он напишет свой одностраничник и он будет автономно работать ещё 15 лет вперёд, безо всяких доработок и переписываний.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от vvn_black

Новичку предлагать сразу в асинхронщину?

Кстати, это слова того, кто застал исторический процесс.

А, сейчас, состояние такое, что можно с этого и начинать вхождение, например, с Фаулер М. Asyncio и конкурентное программирование на Python.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)

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

Infra_HDC ★★★★★
()

Останусь на питоне, буду смотреть на джанго и фласк. БД оставлю sqlite. По поводу асинхронщины - не знаю, нужна ли будет. Если будет нужна, буду осваивать. Хотя ее наверняка надо как-то сразу внедрять, поэтому посмотрю заранее, что это такое.

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

Спасибо за советы, лор.

Entmatix
() автор топика
Ответ на: комментарий от Infra_HDC

Это неизбежно. У меня питон и так в последнее время постоянный инструмент для моделирования и расчетов (много всего перенес из excel в python+pandas). Так что я буду стараться быть в курсе изменений. А то, что хочу сделать, засуну в контейнер, так что обновление версии питона, модулей, бд не проблема. Как поправлю код, создам новый контейнер и вперед. Если это вообще потребуется, конечно.

Entmatix
() автор топика
Ответ на: комментарий от Infra_HDC

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

Почему? Python сейчас на пике популярности, спадать со временем она наверное будет, как и у всего на свете, но какие объективные причины что придётся переписывать?

Я пишу на Python 22+ года, сам язык существует более 30 лет. И никаких предпосылок к умиранию нет: кода и батареек написано столько, что отказаться уже будет сложнее, чем от FORTRAN.

emorozov
()
Ответ на: комментарий от firkax

Он напишет свой одностраничник и он будет автономно работать ещё 15 лет вперёд, безо всяких доработок и переписываний.

Увы, как человек, видевший, во что превращаются эти одностраничники с мешаниной PHP и HTML (и JS) спустя 15 лет… Нет, лучше уж сразу писать правильно.

Это реально путь в никуда. Через 15 лет сам автор не сможет сказать, что он написал, зачем, как оно работает, и как поменять логотип или добавить ещё одно поле ввода.

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

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

emorozov
()

Если с БД, бери Джангу.
Если без БД, бери Фласк.
Эскулайт для небольших проектов — отличное решение.

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

Goury ★★★★★
()
Ответ на: комментарий от emorozov

Я бы всё что было до 1.7 включительно покритиковал.
Потом количество костылей стало приемлемым и, особенно после 2.0, стало совсем нормально.

Goury ★★★★★
()
Ответ на: комментарий от firkax

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

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

Goury ★★★★★
()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от Entmatix

как-то сразу внедрять

Можешь потом внедрить.
Хоть той же флаской, хоть сбоку отдельным микросервисом.
Свободные технологии, свобода решений.

Goury ★★★★★
()
Ответ на: комментарий от Goury

Это о том, что для того, чтобы задействовать динамику на странице, необязательно знать JS, если не требуется что-то очень сложное.

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

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

emorozov
()
Ответ на: комментарий от emorozov

Нет, JS знать обязательно.
Иначе получаются сайты со страницами по сто мегабайт загружающиеся по пять минут.
И тормозящие на чём угодно слабее топа под жидким азотом.
Без преувеличений.

Лучше просто пару вечеров потратить на изучение основ и потом гораздо проще и быстрее написать нужные функции на JS.
Благо для автодополнения списка не особо много нужно.

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

Goury ★★★★★
()
Ответ на: комментарий от Goury

контейнеры не добавляют оверхед в Linux.

И для того, о чём говорит автор, использование контейнеров оправдано, venv не является альтернативой контейнерам даже с натяжкой.

В больших развесистых проектах, разработка в контейнерах не добавляет оверхед, а снижает его за счёт того, что каждому разрабочику не приходится строить окружение с нуля, в котором строго прописаны зависимости (и как быть, если проект с древних времен работает на Postgres 10, а в твоём дистрибе уже Postgres 16, и она у тебя используется для другого проекта, которые не стартанет на Postgres 10?)

emorozov
()
Ответ на: комментарий от emorozov

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

Во-вторых это не большой и не развесистый проект.

В-третьих вот свой постгрес и клади в контейнер.
Или вообще хости снаружи.
А тут эскулайт, у него таких проблем нет.

Goury ★★★★★
()
Ответ на: комментарий от no-dashi-v2

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

Скорее всего, это не то, что сделает новичок.

Ну и насчёт не отличается, все-таки PHP - не general purpose язык. Он родился и развивался много лет как язык, ориентированный на быстрое создание простых веб-страниц, и это до сих пор наверняка торчит из всего.

Но последний раз я смотрел на PHP четыре года назад, и не в курсе последних тенденций. Вижу только, что количество публичных упоминаний PHP заметно снизилось в последние годы, на мой взгляд, он проиграл конкуренцию старым и новым языкам, и потихоньку умирает (субъективно, по рейтингам популярности он всё ещё на 5-10 месте, но вангую, что дальше будет опускаться ниже).

emorozov
()
Последнее исправление: emorozov (всего исправлений: 1)
Ответ на: комментарий от emorozov

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

Goury ★★★★★
()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от OSBuster

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

Докеру надо учиться, и там много неочевидных вещей, и мало хороших руководств. Например, как организовать получение сертификата LetsEncrypt с nginx в докере? Без проброса сокета докер в контейнер, что полностью уничтожает безопасность.

emorozov
()
Последнее исправление: emorozov (всего исправлений: 1)
Ответ на: комментарий от emorozov

Докеру надо учиться, и там много неочевидных вещей, и мало хороших руководств. Например, как организовать получение сертификата LetsEncrypt с nginx в докере? Без проброса сокета докер в контейнер, что полностью уничтожает безопасность.

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

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)
Ответ на: комментарий от emorozov

Он родился и развивался много лет как язык, ориентированный на быстрое создание простых веб-страниц, и это до сих пор наверняка торчит из всего.

Как можно так всё выворачивать наизнанку? Да, он делался как язык для быстрого создания простых веб-страниц, и это не «торчит», это его центральная фича, ради которой его и надо выбирать для этой задачи.

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

firkax ★★★★★
()
Ответ на: комментарий от OSBuster

Ну вот и я о том же.
Лучше просто venv+gunicorn+nginx собрать и никаких проблем не будет.
И масштабируется это всё прекрасно и обучить нового девелопера в команде можно максимум за день.

Goury ★★★★★
()
Ответ на: комментарий от firkax

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

Покажи пример «мути».

Заодно, как по-твоему, всё это появляется потому что просто кто-то издевается над всеми, придумал это назло, а все не поняли и подхватили? Или всё-таки потому что несёт также и [не всегда очевидные] преимущества?

emorozov
()