LINUX.ORG.RU
Форум — Development  

Fastapi, Django или комбинация - выбор инструмента

 , , ,


0

1

У меня есть идея веб аппликации. Условно, чатгпт. Я знаю питон и FastAPI, и могу обернуть свое решение в рабочий rest API. Но, не API единым. Нужно построить сайт, с юзерами, обработкой платежей, галереями, и т.п. Я понимаю, что для этого подходит django, который мне надо будет выучить. Как я понимаю, django умеет и rest API. Передо мной выбор:

  1. Логика решения проблеммы - FastAPI, а веб-сайт на отдельном сервисе django
  2. Делать всё в django.
  3. Так ка я совсем не знаю как делать фронтенд: FastAPI + какой-то ноукод, типа bubble.io (на первое время, он мне хватит, в принципе)

Какие плюсы и минусы есть у этих подходов? Что стоит гуглить и читать? н

★★

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

Если предполагается работа с базой данных, то придётся синхронизировать изменения структуры БД между кодом джанго и фастапи. Потому что в джанго свой ОРМ прибитый гвоздями и вряд ли ты будешь его же использовать в фастапи.

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

Не в пользу, а против опции использовать джанго и fastapi в одном проекте.

допустим джанго работает с базой данных через свои orm. Что мешает фастапи дёргать эту базу через тот-же sqlalchemy?

Ничего не мешает. Но синхронизировать изменения структуры БД придётся вручную, как я уже сказал.

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

Делать всё в django.

Нормальный вариант, но обрати внимание, что DRF - это очень объектно-ориентированный фреймворк в стиле Java. Это может быть как преимуществом, так и недостатком, в зависимости от того, к чему ты привык. Впрочем при желании несложные API можно делать на джанго и без DRF.

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

Приходилось работать в проекте, где админка, схема БД и миграции были на Django, а остальные сервисы на использовали sqlalchemy. В принципе сложностей не было, главное не забывать менять описание схем БД в сервисах.

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

Читать стоит документацию от Джанги, она хорошая.
Если ты не знаешь как работают фронты — читай документацию про HTML и держить подальше от всякого JS говнища, оно тебе не нужно и только добавит сложностей.

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

Это плохое решение. Зачем плодить интеграции, когда можно не плодить? Выбери что-то одно.

  • Если весь фронт реактивный, тебе нужен только REST. Подойдёт FastAPI.
  • Если весь фронт реактивный и нужен серверный рендеринг (например, чтобы поисковые системы индексировали), то NodeJS. Или костыли (крутить chromium на бэкенде, кэшировать из него html).
  • Если фронт не реактивный, бери Django — в нём хороший шаблонизатор и вообще всё нужное из коробки. Для REST API есть django rest framework.

Если no-code конструктор генерирует на выходе web app, т.е. на реактивном фреймворке, то тебе нужен первый вариант.

InterVi ★★★★
()
Development