A New Framework Architecture for 2016

Posted by John Arroyo on 5/13/2016

Why a new architecture?

PHP is the most popular language on the net and has a wide array of frameworks, apps and packages available.  Most of the best ones are open source, free or have a freely available version of their paid app.

That being said, it’s only more recent that the frameworks are being made, or attempts are made, to make them work together as components.  I thinks its about time to rethink or re-imagine how a developer or architect can create complex systems in an incremental and meaningful way.

I spoke a bit about the history and features of PHP previously.  Folks like Facebook and Baidu use it extensively. Some of the PHP platforms that are widely adopted are Drupal, WordPress, Magento, Joomla, Media Wiki, Symfony, Laravel, and Yii.  All have considerable user bases and impressive feature sets.  They all however, have very different conventions, coding styles and theming styles.

Speaking of theming, the way developers create a UI these days is dramatically different than how it was done in the past.  Browsers are more powerful and devices are more diverse.  JavaScript is much more powerful and more uniformly supported than it was a decade ago when PHP 5 came out (don’t forget about the V8 engine too).

  • Theming: Not everything has to be PHP anymore.  We now have
    • Bootstrap, & Material
    • Pre-compiling theme & components
      • Less/Sass
      • Gulp, bower, & grunt composition and code prep
    • Powerful JS frameworks and libraries: Angular, React, & more
      • Many more options than just jQuery these days

What’s missing from existing frameworks

  • Modularity
    • Some frameworks handle it well, but often the modularity is very limited to a smaller ecosystem, or at least an isolated ecosystem.
  • Composibility
    • Things are too often configured (db and config file) and not composed.  That is very convenient, but leads to slow production code and is more limited than a composable system
  • Security
    • Code should be outside the web root
    • Should work with and without a reverse proxy
    • Protect against common attacks
  • Models / ORM
    • The framework should work with any composer based (or modular) ORM
      • With so many rich ORMs and data connection tools available I don’t believe the framework should be relegated to only one ORM or model paradigm
      • Different scenarios call for different model approaches.  How can the framework facilitate the right data tool for the job?
  • Mashability
    • Create components that can easily be used together
    • Easy to add to any framework including erdiko
      • Leverage more code across and between frameworks
        • e.g. Use Eloquent in Slimphp
  • Routing
    • Symfony Request & Response
    • Symfony Router
    • Easy Compiled Routes
      • PhpMatcherDumper
    • Via plugins
      • Database routes (cms content)
      • Application specific routes
        • e.g. Magento, WordPress, Drupal
  • Server Automation
    • Work well with containers, modern deployments and popular coding workflows

The Developer / Architect paradox

This does however have a downside and that is what I call the developer / architect paradox.  This is developers wanting a complete solution and picking a tool that gets them 80% of the way there very quickly but they struggle with the 20% and have to make too many sacrifices and concessions to make the full system work.