Доброго времени суток.
Ранее, при реализации простеньких проектов у нас было 2 разработчика они же и frontend они и backend они же феи которые настраивали сеть, прокси и т.д.
Код проекта хранился в одном репозитории, соответственно все вьюшки и статика хранились в нем же. Соответственно все разработчики видят весь код. Структура классическая - mvc.
На уровне контроллера решалось рендэрить html или отдавать json. Все логично и понятно. При такой структуре не возникало проблем ни при разработке ни при тестировании, т.к. при внесении изменений в шаблон или вью сразу можно было видеть результат.
В данный момент встала задача реализовать более-менее серьезный проект. Начитавшись интернетов на тему тру разработки вопросов стало больше чем было.
Главный вопрос разделения frontend/backend.
Как реализовать структуру проекта таким образом, что бы frontend разработчик не имел доступа к коду backend сервера.
Допустим, есть 2 репозитория frontend/backend.
С backend все понятно, допустим есть два метода за логином /tasks - который возвращает html и /tasks/list - который возвращает json.
С frontend не очень понятно.
Frontend разработчик собирает шаблоны и вьюшки с помощью грунта, бовера и прочих плюшек у себя на машине. Теперь ему нужно проверить как будет выглядеть /tasks. Мало того, что на его стороне нет шаблонизатора который например накатит данные из сессии (Имя, Фамилия, Аватарка и т.д.) на шаблон так еще и роута до /tasks/list который летит через ajax после прогрузки страницы.
Первый вариант который пришел в голову - писать некий fakeServer для тестирования, который отдавал бы синтетику по роутам аналогичным боевому серверу. Но данный вариант - долгий, "дорогой", и глупый как мне кажется.
Второй вариант который пришел в голову - это сделать фронтенд отдельным http сервером который в свою очередь обращается к backend через api. Не очень кошерный вариант как кажется т.к. часть логики может ухать на фронтенд и весь рендеринг уйдет на этот http сервер соответственно. Но все же хотелось бы услышать мнение по этому поводу.
Третий вариант хочу получить от тех кто уже ел этот кактус.
Спасибо.
> Одна репа
Что одна репа?
> Версионирование АПИ
Что версионирование АПИ?
> Для фронтендера нет никакой проблемы запустить ./manage.py runserver и получить себе работающее приложение.
Это значит что на фронтенде должен быть роутинг?
Это значит что на фронтенде должен быть клиент который ходит на бэкэнд?
> В вопросе слишком много воды и неясностей
Вопрос был специально поставлен таким образом, что бы отсеять тех, кто "льет много воды".
> Нужны названия фреймворков и описание проекта
Зачем, если не секрет. Вопрос не в том на чем писать проекта и с помощью каких фреймворков, вопрос в принципе реализации разделения двух сущностей.
sim3x: Рендер зависит только от данных которые отдает backend на сколько я понимаю. На основе этих данных и производится рендер. Данные может получать ваше ios приложение рендер в котором будет свой.
> И что дает разделение на две и более реп?
Как минимум то что frontend разработчики веба и ios приложения не будет видеть код backend. Который им и не нужен собственно. Это не их песочница.
OnYourLips: те код и настройки рендера хранться во фронтенд репозитории. ок
Как синхронизировать два репозитория?
Как упрощается поддержка, когда у нас есть две (или больше) версии фронта и две (или больше) версии бека? Как они знают, кто и что какой версии использует?
OnYourLips:
Также бек и фронт не смогут шарить код и будут делать работу два раза.
Возможно даже, что будут делать ее по-разному и получать разный результат
OnYourLips: те валидацию на сервер производить не нужно?
Кроме того что нужно делать на разных ЯП, так еще и реализации могут иметь разные ошибки
Для меня решение использовать моно репозиторий хорошо тем, что я получаю весь код для продакшена в одном месте и мне не нужно проводить совещание с двумя (и более) тимами, которые пилят проект
Если у тебя такой проблемы нет или накладные расходы на совещания всех устраивают - отлично.
Я тебе завидую
sim3x, > Для фронтендера нет никакой проблемы запустить ./manage.py runserver и получить себе работающее приложение.
Прошу прощения за некропостинг.
А еще не забывать ./manage.py migrate, pip install -r reqs/dev.txt, развернуть celery (+ redis/RabbitMQ) и БД.
А еще надо учитывать, что многие фронтендеры сидят на винде (птмчт там есть фотошоп,а денег на мак нет) и там с этим есть некоторые проблемы.
Плюс если в миграциях создаются новые таблицы, то надо еще тестовые fixtures или брать дамп бд у кого-либо и уметь его грузить.
Вобщем сложностей для фронтенда очень много создается.
Поэтому мне тоже интересно, как делают другие. Меня не интересует СПА.
Мы попробовали на одном проекте бек на джанго (API), фронт на ExpressJS (Node). Удобно тем, что можно переключаться между серверами (фронт можно направить получать данные из боевого, тестового или дев сервера, просто поменяв переменную в окружении).
Я правильно понял, что вы предлагаете след.структуру:
Есть вагрант, где командой vagrant up поднимается сервер, запускаются pip install, migrate, runserver (хоть скриптом, хоть руками - без разницы) и он находится на локал.компе разработчика.
Но тогда как обновлять данные в БД? этот вопрос мне очень интересен.
У нас вначале еще была проблема с медиа-файлами (их очень много), но мы их перенесли в S3 и теперь этой проблемы нет. Как сделать такое же с БД и надо ли, я не знаю.
sim3x, Эм.. не совсем понял. Допустим след.ситуацию:
Была добавлена таблица в БД. Для примера таблица комментариев. Фронтенду надо сделать вывод списка комментариев - сам список бекендом уже передается в контекст. Для фронтенда надо, чтобы список был непустым, т.е. какие-то тестовые данные, которые не должны попасть на прод.
Заполнять ручками данные - точно не решение.
какое в вашем случае будет решение? Если фикстуры лучше не использовать, то у меня нет решений
Всем спасибо за участие. Собственно ответ на свой вопрос получил от некоторых ораторов в данном тосте и из нескольких статей.
Одна из них, кому интересно: wbtech.ru/blog/frontend-and-backend-collaboration
Простой