Какой инструмет выбрать для бэкенда?

Question

[be9st]

Хочу создать сайт для дизайнеров, в котором будет возможность выкладывать фото, писать комментарии, оценивать фотографии, авторизация пользователей и т.д. На фронте предпочитаю React. Что выбрать для бэка, чтобы сделать быстро, без идеи глобального масштабирования(личный проект), на небольшую нагрузку, ну и желательно как-то удобно с react'ом контактировать? Пожалуйста, опишите плюсы и минусы предлагаемого решения.

P.s. что угодно, кроме php

Comments

[Михаил]

Любой язык бэкенда + SQL, с этими навыками вы все что угодно напишите

Answer 1

[Дмитрий Свиридов]

Если ты предпочитаешь React и не хочешь PHP, я бы посоветовал тебе пилить API на Go (микрофреймворк Gin/Gonic) либо на Python (FastAPI, например). Чисто для API юзать огромных монстров типа Django избыточно. Но в то же время, как я понял, ты не хочешь прямо сильно заморачиваться, так что я посоветую тебе все же взять Django в такой связке:

1. Django + django-rest-framework в качестве бэкенда
   
2. React с тайпскриптом для фронтенда
   
3. NextJS для рендеринга JS на сервере, чтобы с твоим сайтом "дружили" поисковые системы
   

Почему именно Django? Да, для API она, возможно, избыточна, но в ней все равно много штук, которые нужны и работают из коробки. Те же миграции, например, ORM-ка, sitemap, какая-никакая админка и т.п. Все встроено, особо настраивать не надо. Поскольку ты предпочитаешь на фронте React, тебе django-rest-framework для этого очень пригодится.
Минусы:

1. Говорят, Django медленная. Ну, тут смотря с чем сравнивать. Питон весь сам по себе медленный. Да и все равно у нормальных проектов почти все отдается из кеша, так что разницы особой нет.
   
2. Django в плане архитектуры не фонтан, "толстые модели" (модели, в которые впихивают логику на кучу строк кода) - такое себе.
   
3. Если будут высокие нагрузки, то Django ORM тебе будет мешать. А если из Django убрать ORM, то смысла в ее использовании станет сильно меньше.
   

Comments

[DevMan]

Hellayas, если правильно использовать, проблем вообще никаких. вне зависимости от языка/фреймворка/платформы/технологии.
но говорят.....

[Евгений Ромашкан]

Django в плане архитектуры не фонтан, "толстые модели" (модели, в которые впихивают логику на кучу строк кода) - такое себе.

Стоит различать Active Record модели и Rich Domain Model.
AR(совмещение в сущностях и доступа к хранилищу и БЛ) - действительно считается антипаттерном и не предназначен для сложных приложений со сложной БЛ.

Rich Domain Model - модель с логикой и без доступа к БД как раз хорошо масштабируется и во всех планах лучше вынесения логики в сервисный слой (инкапсуляция, меньше связность = можно тестировать юнитами, более явно выражены требования), только она тоже требует проектирования и декомпозиции, "кучи кода" там быть не должно.

А разделение на модель данных(в которой часто делают геттеры/сеттеры) и сервисы с логикой называется анемичной моделью, и так же считается антипаттерном.

[Дмитрий Свиридов]

Hellayas,

Медленная для чего?

- не для чего, а в сравнении с чем. Для приложений с высокой нагрузкой я бы Django точно не взял.

В чем проблема если все правильно использовать?

- может быть, в случае с Django это и правильно, но, на мой взгляд, бизнес-логику нужно держать изолированно в сервисном слое, которого в django по умолчанию нет. Можно использовать, конечно, django-service-objects, но даже такой сервисный слой получается приколоченным к Django намертво, т.к. использует для валидации формы Django.

[Дмитрий Свиридов]

Евгений Ромашкан,

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

Под моделью с логикой и без доступа к БД подразумевается модель + хелперы всякие типа форматтеров и т.п.? Если да, то я не не против, т.к. я не про такую логику писал, а про различные методы, работающие с моделями.
А что, кстати, мешает юнитами тестировать сервисный слой? По-хорошему, сервисный слой пилят так, чтобы было наглядно видно, что туда передается, поэтому нет никаких проблем покрыть это тестами и передавать туда мок-объекты (например, чтобы в юнит-тесте не выполнялся какой-нибудь, скажем, заход в редис, запрос куда-то по API и т.п.).

А разделение на модель данных(в которой часто делают геттеры/сеттеры) и сервисы с логикой называется анемичной моделью, и так же считается антипаттерном.

Сколько людей - столько мнений

[Евгений Ромашкан]

Под моделью с логикой и без доступа к БД подразумевается модель + хелперы всякие типа форматтеров

Domain model и репозиторий + Data Mapper для сохранения.
На чтение отдельные модели, и никакие форматтеры в первых не нужны.

А что, кстати, мешает юнитами тестировать сервисный слой?

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

Сколько людей - столько мнений

Анемичная модель уже лет 20 как вполне себе признанный антипаттерн.
И её недостатки явно выводятся из общепризнанных, опять же, кмк, coupling/cohesion и банально идей Инкапсуляции/Information hiding.

Другое дело что есть пара препятствий к их использованию:
1. Люди до сих пор мыслят и проектируют процедурно(отдельно данные, отдельно логика). Понять что данные об одном пользователе можно хранить в нескольких сущностях, а не в одной на 20 полей, где и имя с соц. Профилем, и данные аутентификации, и рекламные идентификаторы, уже серьёзный майндшифт
2. Проектировать хорошую доменную модель сложно, плюс нужна инфраструктура, иначе можно сделать только хуже
3. Люди пытаются втащить модные штуки в проект без надобности, делают это плохо и дискредитируют их

[xfg]

Евгений Ромашкан, Фаулер считает анемичную модель анти-паттерном, но бизнес-логику в сервисах без модели вообще - он считает нормальным решением и называет это transaction scripts. Такую же мысль в своих книгах доносят и другие известные инженеры. Посыл следующий или пишите процедурно или пишите объектно-ориентированно. Не делайте нечто среднее, то есть анемичную модель + процедуры в сервисах, так как не получите никаких преимуществ перед transaction scripts, но получите всю сложность domain model. Ну и тот же Фаулер ничего против rich model с использованием Active Record не имеет, указывая в своей книге PoEAA на то, что это некий компромисс между transaction scripts и domain model.

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

Answer 2

[Владимир Коротенко]

Попробуйте net core.

Из коробки умеет
* базы данных mssql mysql pgsql oracle
* Entity framework core
* oauth авторизацию, причем все уже написано, вам только переписать немного
* кучу пакетов для поддержки всего на свете
* возможность работать в линуксе и маке (и конечно в windows)
* отличная среда разработки, для большинства сценариев достаточно версии Community

Поддерживает реакт и целую кучу плюшек для клиентской сборки.

Comments

[Дмитрий Свиридов]

Добрый день! Пользуясь случаем, хотел бы задать Вам несколько вопросов по поводу этого всего.

1. Есть ли, на Ваш взгляд, смысл осваивать .Net, если знаю (несколько лет в разработке использую) php, python и go?
   
2. Удобно ли разрабатывать на .Net из-под Линукса? Какую IDE лучше юзать для этого?
   
3. С чего лучше начать?
   

[Владимир Коротенко]

1. каждому гвоздю свой микроскоп. Не поймите не правильно, но фэйсбук написан на PHP и неплохо себя чувствует. В принципе на чем гонять rest или graphql разницы никакой. Пишите на чем умеете

2. Нет. Но это мое мнение. Впрочем я не особо люблю линукс, есть куча претензий, в качестве десктопа он никакой, даже SUSE или RedHat. Впрочем IDE Visual Studio Code или Sublime. Что то слышал что сделали Jet Brain но не пробовал

3. С любого реального проекта. Я например подзабил на вполне готовый проект, https://github.com/vkorotenko/ChatApplication/ моя ошибка, но о клиентах либо хорошо, либо ничего

[Дмитрий Свиридов]

Владимир Коротенко, огромное спасибо) Насчет "есть куча претензий, в качестве десктопа он никакой" считал так же, пока не попробовал Linux Mint - оказалось очень удобно.

[Владимир Коротенко]

Дмитрий Свиридов, Там свои заморочки, которые очень сильно раздражают.
Вот например
Нет перевода в менюшке


Сравните с дефолтовым в виндоуз

Answer 3

[Denis Kiselev]

Особенно чего то никто Node не советует - а есть определенная логика: будет fullstack js.

Ну и express.js или любой фреймворк ноды для бэка. Пакетов в npm для всего - достаточно, тьюториалов в гугле - навалом, коммьюнити - огромное.

Comments

[Дмитрий Свиридов]

есть определенная логика: будет fullstack js

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

[Denis Kiselev]

Дмитрий Свиридов, Будет общий язык разработки - подходы и фреймворки, понятное дело, будут свои. Просто если бэк будет на другом языке - всё то же самое, подходы будут тоже другие, а вот общего языка уже не будет.

Однако если фронт на реакте, можно сделать мобильные приложения на React Native / Expo, web версию просто на рекате, и бэк - на ноде. По описанному ТЗ - ничего сложного нет, обычный CRUD который на экспрессе делается легко, плюс есть куча модулей для автоматизации - я ля генераторы CRUD роутов (finale например). Всё нагуглить легко