node js и php на одном сервере

может ли PHP и node.js работать на одном сервере

У меня есть веб-приложение с Apache и PHP на конце. Я нахожусь в процессе усовершенствования этого со многими новыми функциями и рассмотрением использования node.js для новой работы.

Прежде всего, могут ли PHP и node.js существовать на одной машине? Я не понимаю, почему не. Во-вторых, я могу просто вызвать код node.js непосредственно из Javascript и вернуть обратно JSON?

4 ответа

Да и да. Node и Apache /PHP могут сосуществовать на одном сервере.

Вы можете запустить узел и PHP на одном сервере и даже на одном и том же порту. Ключ заключается в том, чтобы использовать сервер, такой как nginx, во фронтальном режиме прослушивания на порту 80, настроить PHP в Nginx, как вы это обычно делаете (используя php-fpm), и настроить экземпляр Node для локального прослушивания на каком-нибудь высоком порту, например 8081. >

Затем просто сконфигурируйте nginx для передачи всех запросов Node через localhost: 8081, используя имя каталога в качестве фильтра. По сути, вы настраиваете nginx так, чтобы он обрабатывал запросы Node так же, как он обрабатывает запросы PHP: он перенаправляет их другому демону, а затем обрабатывает ответ по мере его возврата. Nginx хорош в этом и хорошо справляется со многими соединениями одновременно.

Еще одним преимуществом этого является то, что вы также можете иметь несколько отдельных экземпляров Node в разных доменах и использовать обычные правила nginx для обработки всего этого. Вы также можете запустить его вместе с другими серверами приложений, такими как приложения, написанные на Go. И вы тоже можете сделать это довольно безопасно.

Кроме того, вы получаете выгоду от настраиваемости Nginx, его поддержки SSL и HTTP /2, а также огромной скорости обслуживания статических файлов и отсутствия необходимости обслуживать статические файлы из приложения Node (если вы этого не хотите).

Да, вы можете сделать это. Если вы используете сервер Ubuntu или Debian, выполните следующие действия:

Откройте свой терминал и напишите:

Если curl не установлен на вашем сервере:

Если ваш сайт загружен, а NPM и Forever настроены правильно, пришло время запустить экземпляр Node.js. Если вы используете Express.js, запустите следующую команду, чтобы запустить экземпляр Forever:

Однако по умолчанию прокси-модули Apache не включены. Вы должны выполнить следующие две команды, если модули еще не включены:

Вам может потребоваться перезапустить Apache после включения этих модулей.

Да, если вы используете php для предоставления клиентам страниц javascript, код javascript может использовать запросы AJAX для доступа к маршрутам, доступным с вашего сервера узлов.

Источник

Node.js и переход с PHP на JavaScript

Больше десяти лет я был PHP-разработчиком, но недавно перешёл на JavaScript, используя его серверные и клиентские возможности. До этого я уже был знаком с JS. Сначала работал с jQuery, потом освоил Angular, и, наконец, начал пользоваться React.

Когда я начинал писать на PHP, я встраивал его в HTML-файлы. Получался не код, а полный бардак. Поэтому, для того, чтобы привести мои разработки в приличный вид, я начал пользоваться фреймворками, в частности, ZF1 и ZF2. Через некоторое время подход, при использовании которого начинают разработку с API, привёл к тому, что у меня оказался сервер, состоящий из сгенерированных REST API и из нескольких сотен строк моего собственного кода.

Так как лишь небольшая и не самая важная часть наших проектов была написана на PHP, возник вопрос о том, можем ли мы от него избавиться. И, если можем, чего нам это будет стоить, и что мы от этого получим. В этом материале я поделюсь опытом с теми, кто, как и я, хочет, понимая, что и зачем он делает, уйти из мира PHP и встать под знамёна JavaScript во всех его проявлениях.

Сегодня я расскажу, в основном, о своём путешествии с серверной стороны PHP на серверную сторону JS в виде Node.js. Здесь я не буду рассказывать о Webpack, React и о других клиентских технологиях JS.

Эволюция стека технологий

Начнём с общей схемы, которая описывает эволюцию используемого нами стека технологий при переходе с PHP на Node.js.

Основные изменения используемого нами стека технологий

Node.js — это основной компонент нашего нового набора технологий. Он отличается высокой производительностью.

Node.js делает своё дело настолько хорошо, что для множества инструментов, ранее написанных на низкоуровневых языках, теперь имеются эквиваленты на JavaScript. Установка обычных программ под используемые нами платформы была такой трудоёмкой, что нам приходилось использовать Ansible для развёртывания рабочей среды. Так как новые инструменты зависят теперь только от Node.js, единственное, что нам приходится устанавливать самостоятельно — это NVM (Node Version Manager) — средство, предназначенное для установки Node.js.

Как правильно устанавливать Node.js с помощью NVM

Когда мы устанавливали Node.js вручную, или используя менеджер пакетов операционной системы, это быстро создало массу проблем при попытках переключаться между версиями Node. В итоге мы пришли к использованию NVM.

Этот инструмент очень легко установить и использовать:

После его установки нам стали доступны следующие возможности:

JavaScript в 2017-м году

Начиная изучать JavaScript, я воспринимал его как второсортный язык, без которого «к сожалению, не обойтись» при создании динамических веб-сайтов. В результате я никогда и не пытался как следует в нём разобраться. Я учил JavaScript, в основном, по постам в блогах, да по ответам на Stack Owerflow. Теперь я об этом сожалею.

Учите матчасть!

Я был не готов начать использовать современные фреймворки и инструменты JavaScript. В 2017-м JavaScript стал совсем другим благодаря новым возможностям. Среди них можно отметить следующие:

Переход с Composer на Yarn

Composer — отличный, но медленный инструмент. У NPM есть тот же недостаток, поэтому мы, вместо него, выбрали Yarn. Это — самая быстрая альтернатива NPM.

В прошлом проекте у нас было около тысячи зависимостей. Команда разработчиков состоит из 10 человек, папка node_modules меняется, как минимум, 2 раза в день. Прикинем, сколько времени займёт установка пакетов за два месяца по следующей формуле:

(10 разработчиков + 3 окружения) * 2 установки в день * 60 дней * 3 минуты на установку = 78 часов.

Оказывается, две недели рабочего времени было потрачено на наблюдение за ходом загрузки пакетов и на чтение Reddit. Три минуты — достаточно длинный отрезок времени, который способен вылиться в большие потери, но слишком короткий, чтобы, пока идёт установка, можно было бы переключиться на какую-нибудь другую задачу.

Благодаря Yarn нам удалось снизить время установки с 3-х минут до одной минуты. Это позволило сэкономить 46 часов рабочего времени. И, я вам скажу, это — отличный результат.

Создание API в JavaScript

Пожалуй, вместо того, чтобы рассказывать об этом самому, дам слово коду. Вот минимальный пример API, основанного на следующих пакетах:

Несколько строк кода — и у нас есть REST API, которое поддаётся настройке и расширению.
После того как мы создали более 50 конечных точек API с помощью Apigility, мы поняли две вещи. Во-первых — это возможно, во-вторых — эффективно.

Например, Epilogue без проблем генерирует 10 конечных точек. Имеется и возможность подключать собственный код к стандартному каркасу для поддержки сложных условий, вроде прав пользователей. То, что нельзя сгенерировать автоматически, создаётся в виде простых конечных точек Express RPC с помощью Sequelize.

Не спорю с тем, что Zend Framework 2 обладает гораздо большими возможностями, чем Express. Но Express оказался экономичным и простым решением, которого было достаточно для всех наших нужд. При переходе на него нам не пришлось от чего-либо отказываться.

Flow: спасательный круг для тех, кто утонул в море типов данных

В PHP можно было добавлять подсказки типов данных только тогда, когда это было нужно. Это — одна из моих любимых особенностей PHP. Здесь имеется мощная, но гибкая система типов.

Многие годы я думал, что нечто подобное в JS невозможно, что единственный выход — переход на TypeScript. Однако, я ошибался.

Я обнаружил библиотеку Flow, так же известную как Flow-type, и смог без проблем добавлять информацию о типах в мои JS-тексты.

Установить библиотеку Flow несложно:

Так же просто её подключить, добавив одну строчку кода в верхнюю часть файлов, которые необходимо контролировать:

Затем команда flow check позволяет получить отчёт, основанный на выведенных типах.

Если ваш проект использует транспилятор, вроде Babel, для поддержки подсказок типов Flow в JS можно добавить новые правила. В результате, с типами можно будет работать так же удобно, как и в PHP.

Подсказки Flow

Падение серверов и мониторинг с помощью PM2

В мире PHP сбой скрипта означает необработанный запрос. В случае с Node.js, если падает сервер, перестаёт функционировать весь веб-сайт. Поэтому процессы необходимо мониторить.

В поиске хорошей системы мониторинга мы перешли с Supervisord на его конкурента, написанного на JavaScript. Вот он:

Мне так нравится PM2, что я просто не могу удержаться от того, чтобы вставить сюда пару сердечек.

PM2 можно устанавливать с помощью Yarn, что само по себе очень хорошо, но и у самого PM2 есть немало сильных сторон. Так, в плане возможностей, он превосходит Supervisord. Он умеет отслеживать нагрузку, которую каждый процесс создаёт на систему, и занимаемую процессом память, его можно настроить так, чтобы он перезапускал процессы при изменении их кода.

Команда pm2 list позволяет вывести сведения обо всех управляемых PM2 процессах

PM2 визуализирует вывод служб и может отслеживать заданные пользователем метрики

Скажу больше. В то время, как сфера возможностей Supervisord ограничена управлением процессами, PM2 может заменить некоторые скрипты, используемые для развёртывания проектов, простыми конфигурационными файлами:

Конфигурационный файл, который позволяет удобно описывать и разворачивать процессы

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

В наших проектах Phing использовался для решения трёх задач:

Те задачи, которые решались благодаря скриптовым возможностям Phing, больше не требуют от нас использования специальных инструментов. Раньше все наши скрипты были либо привязаны к конфигурированию ПО за пределами мира PHP, такого, как Supervisord, либо могли быть оформлены как независимые сценарии командной строки.

В итоге, единственная роль, которую мог бы выполнять Phing, заключается в хранении команд и создании для них сокращений. Эту задачу отлично решает Yarn (или NPM):

В итоге мы смогли полностью избавиться от Phing и вызывать наши команды примерно следующим образом:

Поиск и использование хорошего опенсорсного редактора

Разрабатывая на PHP, я пользовался PhpStorm, платной IDE, так как те, что распространялись бесплатно, либо казались медленными, либо страдали от недостатка плагинов.

В мире JavaScript выбор достойных редакторов кода гораздо богаче. Мы остановились на VS Code. Этот редактор написан на JavaScript, его поддержкой занимается сообщество энтузиастов и Microsoft.

Логотип VS Code

До сих пор всё в VS Code нам нравится. Работает он быстро, обладает замечательной системой автозавершения кода, за ним стоит отличное сообщество.

Здесь мне очень нравится возможность задавать то, какие плагины использовать в проекте, и делиться конфигурациями. Благодаря ей можно подготовить рабочее место программиста буквально за пару кликов.

Избавление от ручного линтинга с помощью Prettier

В PHP у нас была одна замечательная штука. Это — стандарты PSR. Эти стандарты по-настоящему полезны при подготовке правил оформления кода.

Мы настроили наши IDE так, чтобы код соответствовал стандартам PSR 1 и 2. Так как не было функции автоисправления, каждый был ответственен за то, чтобы самостоятельно их применять. Это было не так уж и хорошо.

При переходе на JavaScript неоценимым помощником в этой области стал для нас Prettier. Prettier — это средство форматирования кода, основанное на правилах. Оно, при каждом сохранении файла, удаляет всю самодеятельную стилизацию и приводит код к виду, соответствующему единому стилю.

Prettier в действии

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

Все в команде используют и любят Prettier. Программисты делают свою работу, а Prettier отвечает за детали форматирования.

Итоги

Рассмотрим плюсы и минусы, с которыми мы столкнулись при переходе с PHP на JS:

Если вы подумываете о переходе с PHP на JS, желаем вам успеха и надеемся, что наш рассказ поможет вам сориентироваться в мире JS и выбрать именно то, что вам нужно.

Уважаемые читатели! Если вы пользуетесь PHP, расскажите пожалуйста, как вам живётся, планируете ли переходить на JavaScript?

Источник

А насколько нормально использовать Node.JS и PHP в одном большом проекте?

> Помните о том, что поддерживать проще продукт на 1-2 языках/технологиях, а не на большем их количестве!

1) PHP
1.1) Laravel
1.2) Html/Blade/Twig/Jade
2) Nginx/Apache
3) Postgres/MySQL
4) NodeJS
4.1) Webpack/Gulp
4.2) ES2017+/TypeScript/Coffee/Dart
4.3) Css/Sass/Stylus/Less
4.4) Angular/Vue/React/Ember/Aurelia/Knockout/JQuery

И как мне этот совершенно дефолтный (я не включал в него: Vagrant/Docker, Redis/Tarantool, WebDAV/S3 и проч., т.к. без них можно обходиться, хоть и с трудом) список из 10ти элементов сократить до 2х? Может есть идеи? +))))

> Помните о том, что поддерживать проще продукт на 1-2 языках/технологиях, а не на большем их количестве!

1) PHP
1.1) Laravel
1.2) Html/Blade/Twig/Jade
2) Nginx/Apache
3) Postgres/MySQL
4) NodeJS
4.1) Webpack/Gulp
4.2) ES2017+/TypeScript/Coffee/Dart
4.3) Css/Sass/Stylus/Less
4.4) Angular/Vue/React/Ember/Aurelia/Knockout/JQuery

И как мне этот совершенно дефолтный (я не включал в него: Vagrant/Docker, Redis/Tarantool, WebDAV/S3 и проч., т.к. без них можно обходиться, хоть и с трудом) список из 10ти элементов сократить до 2х? Может есть идеи? +))))

Источник

Node.js + PHP — интеграция

С каждым днём технологии развиваются всё интенсивнее. Новое приходит на смену старому либо дополняет его. Так происходит и в мире веб-разработки. Старый-добрый PHP порой не может справится с поставленными задачами, либо справляется, но не так легко и элегантно, как новые технологии (например, Node.js).

Но решение можно найти всегда. Можно полностью погрузится с головой в новшества, можно писать костыли, а можно привлечь для помощи новшества.

В этой статье я хотел бы рассказать как-раз о третьем варианте. Думаю, если Вы читаете эту статью, то, наверняка, интересовались что же за зверь такой этот Node.js, и мне нет смысла об этом рассказывать.

Поговорим лучше об интерации Node.js с PHP. В частности статья будет об интеграции с PHP модуля для Node.js под названием socket.io, но думаю любой другой энтузиаст сможет применить описанные решения для себя.

Чтобы не писать слишком абстрактно, поставим задачу: написать проект на PHP (на фреймворке или своими руками) с личными кабинетами пользователей и межпользовательской системой сообщений, т.е. “Диалогами”.

В ходе разработки всплывает две основные проблемы.

Проблема №1 — авторизация

Представим что Вы сделали авторизацию и личные кабинеты на вашем сайте. И вот подходит момент когда пора писать “Диалоги”. Первым делом Вы устанавливаете node.js и модуль socket.io, пишете server-side для “Диалогов”.

Тут и появляется вопрос… Как же идентифицировать нашего авторизованного через PHP пользователя в Node.js? Ведь у него есть вполне определённый id. Но как нам его получить. В большинстве случаев, для этого используются cookies. Они служат своего рода указателями на php-сессию хранимую на сервере.

Идея первая (ошибочная)

Сразу всплывает вариант получить cookies и с помощью них получить php-сессию. К сожалению, решения я не нашёл. Даже не предполагаю, что такое возможно.

Идея вторая

Идея заключается в том, чтобы хранить сессии не native-методом, а, например, в базе или memcached, или redis. Соглашусь что решение элегантное. Но давольно-таки сложное для новичков. Используя его всплывёт ряд проблем: установка и настройка хранилища сессий и конечно же сериализация сессий на стороне PHP (все сохраняемые сессии автоматически сериализуются и требуют десериализации после их получения). Одно из таких решений представлено здесь: Integrating Node.js with PHP. И ещё презентация с парой схем и полезными ссылками.

Идея третья (простая)

По неизвестным мне причинам, в интернете ничего похожего не нашёл. Идея заключается в том, чтобы (утрирую) “спросить у PHP авторизован ли у тебя пользователь с таким вот cookie 1234?”. Для этого мы воспользуемся “аналогом cURL для Node.js” — requestify. Систаксис этого модуля схож с ajax запросами в jQuery. С помощью него мы будем посылать запрос PHP, подделывая кукисы на кукисы пользователя. Модуль Socket.io имеет встроенную функцию авторизации, что значительно упрощает нам жизнь.

Метод get_user_array() в PHP:

Проблема №2 — работа с базой

Конечно же выбор способов за Вами. Я же предпочёл метод запросов.

Был бы рад получит Ваши отзывы, вопросы, замечания!

Источник

Nginx: PHP и Node. js под одним доменом

#devops #backend #frontend

Планируя архитектуру веб-сервиса с SPA и RESTful API, мы часто применяем несколько разноуровневых доменных имен. Например, на домене some-site.ru размещаем основное клиентское приложение, а на поддомене api.some-site.ru — backend-приложение с API. Это могут быть два различных веб-сервиса на абсолютно различном стеке.

Рассмотрим, как организовать общую маршрутизацию http-запросов между двумя сервисами под одним доменом. Разделять запросы по сервисам будем с помощью префиксов в части URI. Например, http-запросы, поступающие на адрес some-site.ru/api/some-method-route, будут проксироваться на сервис php-fpm, остальные запросы, без префикса api, будут уходить на upstream c Node.js.

Для решения такой задачи необходимо написать правила для веб-сервера Nginx, который должен выступать в виде fastcgi- и http-прокси-сервера одновременно, а также маршрутизировать соответствующие запросы по двум различным upstream-целям.

Для наглядности и понимания общей архитектуры мы собрали небольшой проект. В директории ci располагаются инструкции по сборке Docker-образов для доставки их, например, на серверы с Docker Swarm.

Отдельного внимания заслуживает файл конфигурации Nginx.

Стоит отметить, что представленный проект лишь демонстрирует возможность объединения разнородных апстримов под одним доменным именем и не несет большой прикладной пользы.

Все исходники проекта располагаются в директории src, внутри которой они делятся на два изолированных типа, которые впоследствии будут собраны в два различных образа — PHP и Node.js. Таким образом, финальная поставка продукта будет состоять из трех образов: Nginx, PHP-FPM и Node.js.

25 декабря 2020 • Скопировать ссылку Ссылка скопирована

Источник