We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Refactoring from Slim to Phalcon

Hi,

We are running a medium sized website called kollekt.fm which is currently build on top of the Slim framework which is used as a RESTfull backend. I've been the only backend developer working on the project thus far and we’re currently in the process of getting more developers to join the team. I’ve been reviewing our current architecture to see if this is futureproof and will holdup as the project grows.

The slim framework; As the name dictates, is a very slim framework :). It does not include an ORM for example and we only use it for handling the REST calls. I decided to write my own persistence layer which implements the data mapper pattern and repository pattern. I’m quite fond of these patterns as they don’t break the single responsibility principle. I must say however, I’m not very familiar with the active record pattern, but from what I understand, the models usually map to a table in the database, which is not the case in our project.

The website runs fine on the following system:

  • OS: Ubuntu 12.04
  • Document server: Ngnix
  • Lanuage: PHP5.5 (FPM)
  • Database: MySql
  • Caching: Memcached

Phalcon and Zephir got my attention a couple of weeks ago and I couldn't get it out of my mind. I really like the idea of it being compiled into C. Things I like about phalcon:

  1. Performance
  2. Database migrations
  3. Similar to Slim (easy to do a refactor)
  4. Logger

I'd like to know if this performance is still noticable if I decide not to use the ORM and where phalcon can prove its qualities?

-Cheers



51.2k

@boedy, first of all, let me tell you that the the kollekt.fm idea is very very cool ! I will use it for sure ! Then ...

Is strictly my opinion: using ANY ORM without powerfull hardware resources, will be a pain in the ass. If you want performance, use plain / raw sql ! If you are going to have X developers working on the backend, then the ORM is a must, if you don't want to cry later.

You mentioned that you like the DB migrations from Phalcon. I am not sure if you can use them without ORM - maybe @phalcon can answer to that. As for your question "where phalcon can prove it qualities" my answer is: we have developed an API application that handles 97 tables (and growing) and we are expecting > 1.000.000 transactions / day very soon. The server specs are like yours but we are using Redis - way better than Memcached. The DB and Redis storage are on a sepparated machine (16 cores and 48 GB of RAM).

Hope it helped and good luck.

The ORM will always be a bottleneck as Calin pointed out. Based on your requirements you can fix that by either using elastic services (AWS) setting up memory servers, slaves and master etc.

DB Migrations cannot be used without the ORM - they are all part of Phalcon. Once you have it installed everything is there for you. If you don't like the migrations the way Phalcon does it, there is a project dedicated to migrations https://drarok.com/ladder/ which I have used successfully in the past.

Thanks Calin, Great to hear!

I'm thinking of using doctrine 2 as it uses the datamapper pattern. Would it make sense to swap out slim for phalcon just to handle the REST calls?