CakePHP Multiple Applications On A Single Server

Image

CakePHP is a wonderful PHP framework, but it can be serious pain in the butt when trying to get a multi application setup working. This post is just a simple redirect to a forum thread that solved a problem I had been experiencing for over a month whiles in the testing phase of an app.

The application is basically in two parts:

  1. /public_html/app  <— main application
  2. /public_html/api   <— cross application api

Both apps are running CakePHP 2.4.5 and work extremely well on my local WAMP setup without any issues. The main app makes HTTP requests to the API for virtually all data related calls and in the future the api would be made public via http://api.domain.com and would supply data to a mobile app as well.

The issue however that arose was that as requests are being made, the application would suddenly crash and throw a MissingActionException, with an error like

NOT FOUND

the action at /controller/action could not be found.

This was strange and after a whole month of researching, the issue all boiled down to the the CakePHP APC cache settings, which were causing a conflict between the two apps, simply because they were using the same value of “myapp_”.

The solution to the problem is recommended here: http://cakephp.1045679.n5.nabble.com/Help-Multiple-Apps-Shared-Core-Dispatch-Errors-CakePHP-2-0-3-td5009614.html

I seriously wonder why the CakePHP team could not come up with a simple process that ensured that with each app on the same system, the $prefix for the Cache.config.prefix setting would be unique, or better yet, force the value to be changed for each app installation so this error does not occur and leave one scratching their head.

Oh well. I’m glad I found that link and hopefully someone else would be spared a month searching for it simply because it is referenced here.

Advertisements

2 thoughts on “CakePHP Multiple Applications On A Single Server

  1. I’m curious, why did you decide to run 2 apps. You could have dedicated a controller for API (typically, http://domain.com/api/resource) then have your other endpoints which consumes the API. So that, at the end of the day, you have a single app which still conforms to a SOA.

    With all honesty, I try so hard to maintain the discipline to use the API once it’s written. Sometimes, the temptation to grab data directly from the models intensifies. You start thinking, is it really worth it to go over the wire for this data when I can call a method on an object that returns the same data.

    Personally, I think API driven apps becomes useful when you need multiple clients (web/mobile browser, native apps, etc.) accessing the data.

    1. We chose to use two apps because we intend for the API to grow and accommodate a lot and we do not want to limit that growth by tying the code to the main application. Secondly, we will have a mobile app (HTML5 or Android) in the very near future, and lastly possibly open up the API to third parties as well, and in all cases, we hope that they would not need to redevelop core functionality again. In addition, the API design has multiple controllers for various end points and this is still being fleshed out, so it will be a while before its where we need it to be.

      The application is being written to use the API for almost everything and just a few developers are feeling like you and not using the API when they have to, but the application is small enough now that refactoring would be quick when we need to clean up the code.

      Stay tuned for more updates as and when I post here on our challenges with this project.

Comments are closed.