Q: Бэкенд для ReactJS
Прежде всего, я надеюсь, что мне позволено задать такой широкий вопрос (впервые делаю так).
Итак, я очень новичок в React & Мне нужен проект для работы, поэтому я решил воссоздать свое портфолио (в настоящее время созданное в Laravel) в качестве реакции & реагировать родное приложение.
Мои вопросы:
- Будет ли бэкэнд Rest Api NETCORE хорошим выбором для реакции?
- Мой опыт больше в ASPNET MVC, чем в Core, если я просто придерживаюсь
с API MVC на данный момент (я уже начал создавать API-интерфейс NETCORE
в учебных целях)? - Будет ли php Framework, такой как CodeIgniter, лучше для такого рода
работа?
Мой главный вопрос: хороший ли это подход? Я хотел бы иметь базовый бэкэнд (аутентификацию, публикации новостей, элементы портфолио и т. Д.), А затем продолжить работу над своими приложениями реагирования.
Я думал, что создание бэкэнда Rest API избавит меня от многих проблем при попытке создать приложение реакции для ПК, Android или чего-либо еще (тот же бэкэнд, другой клиент).
P.S: я собираюсь разместить свой API на бесплатных веб-сайтах Azure, если это ASPNET, или на общем хостинге, если это PHP, поэтому я и ухожу от laravel (так что laravel — нет-нет).
P.S2: Firebase или другие облака (кроме Azure) мне не нужны. У меня есть доступ ко многим ресурсам, и я хотел бы использовать их & не используйте бесплатные сервисы, такие как Firebase или еще много чего.
Решение
Просто дать мне 2 пенса здесь, так как это действительно основано на мнении!
Что касается бэкэнда, это зависит от вас, с чем бы вы ни чувствовали себя более комфортно — но я бы внимательно следил за архитектурой бэкэнд-системы, которую вы строите.
Мой выбор — создать архитектуру на основе микросервисов, в которой вы создаете простые атомарные сервисы, которые работают только в своей области. Например, вы можете создать «Общие сервисы» — сервисы, которые могут использоваться в качестве зависимостей другими сервисами (событиями, шифрованием, документами и т. Д.), А затем создать атомарные сервисы, которые связаны с аспектом вашего приложения, таким как Сервис пользователя, Сервис оплаты , Продукт Сервис, Корзина Сервис и т. Д.
Идея проста — создать простые сервисы CRUD, управляемые данными, которые являются модульными, атомарными и могут использоваться повторно. Я обнаружил, что изучение новых технологий — это здорово, но понимание и изучение хорошей архитектуры программирования еще более полезно. Вы можете структурировать данные, чтобы сделать их наиболее эффективными для вас.
После того, как вы создали сервис, вы можете использовать такие сервисы, как Swagger UI, для автоматизации документации и создания для них комплектов тестирования. Если вы не использовали Swagger, я рекомендую его вам.
Проведите тестирование для каждой службы и пройдите весь жизненный цикл разработки программного обеспечения. Это действительно далеко пойдет в вашем портфолио.
Вот несколько статей, касающихся построения микросервисов в ASP.NET Core
развязность
Как примечание, я не развиваюсь ни в ASP, ни в каком-либо другом стеке Microsoft — но принцип тот же
ОБНОВИТЬ
Проблема создания монолитных приложений заключается в том, что база кода может становиться все сложнее и масштабнее по мере роста вашего приложения. Некоторые преимущества Micorservices:
- Масштабируемость
- Инсоляция неисправностей
- Устраняет долгосрочную приверженность единому технологическому стеку
- Разработчикам легче понять (и документировать)
Мой тип установки будет использовать Spring Boot (Java) и Eureka Server — но вы в MS Stack, но ссылка, которую я вам дал выше, показывает, как создать базовый микросервис CRUD с Net Core. Я хотел бы попробовать и посмотреть, как это происходит, а затем вы можете перейти на CI / CD для Azure!
Переходя от простого CRUD API, вы можете вводить соединения WS с событиями, управляемыми событиями (сервер-клиент), а не запрашивать новые данные.
Архитектор, с которым я когда-то работал (гениальный парень), сказал мне, что никогда не следует слишком полагаться на «Framework» — они классные, когда у них все хорошо, но отличное приложение должно быть гибким, чтобы менялись, поэтому я бы не стал слишком полагаться на «рамки», но это было только его мнение.
Другие решения
Пытаться Платформа API — dockerized, но развертываемый на хостинг php (на базе Symfony), генерирует react-admin администратор на базе и дополнительные веб / мобильные клиенты (ИМХО самые слабые стороны этого проекта), документы openAPI (swagger), легко используемые с graphQL … просто попробуй.
Создание портфолио с Laravel не очень хорошая идея. Используйте Gatsby — вы можете использовать graphql (WordPress, contentfull) в качестве источника, генерировать статический сайт.