LINUX.ORG.RU

Flask-RESTful vs. Flask-Marshmallow

 , ,


0

1

Мне сказали что стильно можно молодёжно разделить бэк и фронт пока не поздно, поэтому я тут что бы спросить кого что.

Или может GraphQL? Что бы запастить модностью, стильностью и молодёжностью на пару лет.

Если что, рофлоразработку можно посмотреть тут https://github.com/07th-expansion-ru/wtc-site

Сам сайт вот https://www.whentheycry.xyz/

ПЫСЫ Или я отстал от жизни и все уже на гошке переписывают бэк?

ПЫСЫСЫ На peewee не жалуюсь, но использовать в других проектах не буду


Сам сайт вот https://www.whentheycry.xyz/

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

bvn13 ★★★★★ ()

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

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

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

Итог: разделение даже простого приложения, которое сделано на php, python или чём угодно, но с помощью генерации разметки на сервере на бек и фронт приводит к росту количества запросов от браузера к серверу в десятки раз. Если на обычном php с генерацией на стороне сервера можно отдавать клиенту хоть сразу всё в виде одного index.php и потом частями обновлять по одному запросу на действие, при том что сможет так даже мидл, то достичь подобного уровня оптимизации на любом современном фреймворке для фонта и rest api - так ещё задачка.

PS: в топку всех, кто будет тебе кричать про то, что http/2 и прочие, мол они что-то решают. Просто не знают о чём трещат и никогда им не приходилось оптимизировать приложения под мобилки так, чтобы они работали адекватно. Отсюда и просто вал приложений, которые даже на нормальном 4g работают мягко говоря неудовлетворительно. Добро пожаловать в ад.

ixrws ★★★ ()

Мне сказали что стильно можно молодёжно разделить бэк и фронт пока не поздно, поэтому я тут что бы спросить кого что

Сам сайт вот https://www.whentheycry.xyz/

Не нужно тут GraphQL или JSON API совсем, формируй HTML своим пистоном на сервере.

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

в топку всех, кто будет тебе кричать про то, что http/2 и прочие, мол они что-то решают

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

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

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

Я поспрашивал несколько своих одногруппников (нб! выборка не репрезентативная!), и они пожали плечами, когда посмотрели как у меня рисуется страница. Говорят, мол в нашей вуешке всё не так, у нас вообще на одной странице всё и разметка и стили и скрипты. Вот. Я просто хочу сделать более френдли разработкой для тех, кто не хочет вникать «как быстрее».

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

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

вызову милицию

И как ты меня раскусил, я же не подписывался? Я о тебе стихи пишу, а ты меня опять в тюрьму хочешь отправить… Обидно очень.

Владимир

anonymous ()

Если не секрет, зачем тебе что-то делить? Твой сайт настолько прост, что ему даже php/python-то не нужен. Возьми GoHUGO и нагенери страницы из markdown-файлов в готовые html-файлы - и всё. Просто, легко, быстро, модно и надёжно.

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

Но я вообще я бы выбрал Symfony или Slim.

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

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

ага а потом сиди дублируй функционал для AJAX…

если авторка захочет на работу устроиться, то наличие в порфтолио работающего высера на Vue/React сделает его на голову выше чем дебилов, окончивших говнокурсы

tz4678 ★★ ()