CakePHP и Rails: медленно переносят старую функциональность php на новые rails

#ruby-on-rails #cakephp

#ruby-on-rails #cakephp

Вопрос:

Я разработчик rails, работающий над сайтом cakephp. Чем больше работы они мне присылают, тем больше php-кода я пишу и, следовательно, тем большую зависимость от php мы вводим. Чего я хочу, так это прекратить писать новые функции в php и начать писать их в rails. Наши ресурсы ограничены, а существующий php-сайт огромен, поэтому полный перенос cake на rails невозможен.

Есть ли какой-нибудь способ написать новые функции в приложении rails, сохраняя при этом и предоставляя доступ ко всем функциям старого php (и наоборот)?

Кажется, мне понадобилось бы приложение с поддержкой маршрутизации для передачи запросов либо на php, либо на rails, но затем мы сталкиваемся с проблемой, например, того, что существующая пользовательская функциональность, написанная на php, недоступна для приложения rails и наоборот.

Как насчет чего-нибудь для перевода ruby на php? Таким образом, я мог бы начать писать материал для своей модели на ruby / rails, а не на php.

Я чувствую, что мой вопрос запутан тем фактом, что я не знаю, как задавать вопросы, на которые я хочу ответить, поэтому, надеюсь, это понятно.

Как всегда, заранее спасибо!

Ответ №1:

Один из подходов, который вы можете счесть полезным, заключается в использовании возможностей вашего веб-сервера для правильной перезаписи и делегирования запросов двум разным системам. Если вы можете спроектировать свое новое приложение Rails так, чтобы оно использовало те же записи базы данных, что и старое, с моделями, напрямую сопоставляющимися со старыми таблицами, и гарантирующими, что сеансы, установленные одним, действительны в другом, у вас есть большая свобода действий в том, как вы это делаете.

Apache имеет очень полнофункциональную систему перезаписи URL-адресов и прокси-сервера, которую можно настроить так, чтобы направлять «устаревшие» части вашего сайта на существующий набор PHP-скриптов, направляя весь остальной трафик в новое приложение Rails. Вам нужно быть осторожным, чтобы дизайн обоих приложений был почти идентичным, иначе это может показаться пользователям странным.

Другой подход, который помогает обеспечить согласованный внешний вид, заключается в удалении большей части темы из вашего PHP-приложения. Создавая очень простые страницы, которые предоставляют только необходимую функциональность на каждой странице, Rails может извлекать их, передавая любую соответствующую информацию об аутентификации сеанса, и повторно оформлять их в нужном формате.

Таким образом, вы можете сохранить существующую функциональность и встроить ее в свое новое приложение. Вы можете использовать что-нибудь такое простое, как open-uri или curb gem, для обработки этого делегирования на уровне HTTP.

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

 class PaymentController < ApplicationController
  def index
    @content = fetch_legacy_url('/payments/index.php'))
  end
end
  

fetch_legacy_url Метод создаст HTTP-запрос на выборку, который включает требуемые заголовки, файлы cookie и так далее, и вернет тело ответа. Затем ваш вид будет выглядеть примерно так:

 <%= @content =>
  

Оттуда вы можете передавать части PHP-макета в приложение Rails по частям. Например, удаление больших кусков статического HTML и помещение их в шаблон Rails уменьшило бы объем фактического PHP-кода, который вам нужно портировать.

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

Первым шагом было бы поэкспериментировать и посмотреть, сможете ли вы создать среду Rails, которая использует ваши существующие данные или, по крайней мере, данные, относящиеся к новой функциональности, которую вы собираетесь создать.

Комментарии:

1. Спасибо @tadman. определенно, похоже, что есть несколько серьезных мин, которых следует избегать, и проблемы с обслуживанием, которые могут возникнуть очень быстро, особенно при работе в гибкой команде из нескольких разработчиков. Тем не менее, это имеет смысл и звучит как огромный шаг в правильном направлении, поэтому спасибо за ваш подробный ответ. Это ценится.