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