PHPixie PHP Framework

Why you should try PHPixie and how awesome version 3.0 is going to be

Transcript

1. View Slide

2. Full stack frameworks are too hard for beginners
   Micro frameworks don’t provide enough to work with
   Kohana being discontinued
   Too much boilerplate code
   Questionable design choices in some frameworks
   Mastering a framework requires a lot of experience
   

   View Slide

3. Easy to both learn and master
   High performance ( more on that later )
   Fully unit tested
   Component based ( use only what you need )
   Dependency injection
   No static class members
   Perfect for small to medium projects
   

   View Slide

4. Query builder
   ORM
   Validation
   Authorization and authentication
   PHP and HAML templating
   Cache
   Database Migrations
   Image manipulation
   …and more, out of the box
   Components can be used outside PHPixie
   

   View Slide

5. http://www.techempower.com/benchmarks/#section=data-r9&hw=ec2&test=json&l=sg
   

   View Slide

6. Flexible configuration component
   MongoDB support, with automatic query optimization
   Relationships between objects in separate databases…
   …but still using subqueries wherever possible
   100% code coverage ( some components already covered )
   Full PSR compliance
   Separate Domain layer
   Console API for CLI tasks
   Switch from service location to full constructor injection
   

   View Slide

7. Simplicity is prerequisite for reliability.
   - Edsger Dijkstra
   

   View Slide

8. Instance members
   Static members
   Object instantiation
   B
   class
   A
   class
   

   View Slide

9. Right tool for the wrong job
   

   View Slide

10. Good ones:
    User interfaces
    HTTP Requests
    Real-time updates
    A new USB device is found
    Currently in PHP world:
    ORM model is being saved
    A user has logged in
    Content filtering
    Indirect method call
    

    View Slide

11. Events come from outside the system
    ( user click, API request )
    Application only processes events, but does not trigger them
    Unpredictable by nature
    Have clearly defined subscribers
    

    View Slide

12. Are triggered by the application
    Easily predictable
    Anything can subscribe to anything
    Subscription may occur in the most unexpected places
    

    View Slide

13. Non-linear execution flow
    Possibility of an infinite loop
    Hard to debug ( event hell )
    Should be refactored by injecting dependencies …
    … but the process requires a lot of rewriting
    Once introduced quickly invade all parts of the system
    Observers are a common source of memory leaks
    

    View Slide

14. Some things don’t need simplification
    

    View Slide

15. Requires lookup of
    service identifiers
    Decouples DI from
    implementation
    Multiple formats may
    hurt consistency
    Doesn’t solve injection
    into non-service classes
    

    View Slide

16. Automatic…
    …at first
    Requires another
    dependency
    Reliance on string
    identifiers
    

    View Slide

17. Straightforward
    Transparent
    Easy to understand
    Easy to debug
    Easy to layer
    Verbose
    Why simplify this?
    

    View Slide

18. Heavy use of chaining, shift towards domain languages
    All components support multiple configuration profiles
    V3 components avoid container awareness
    Distinctly separated layers ( V3 ORM is a good example )
    Tests follow class inheritance tree
    

    View Slide

19. http://phpixie.com
    http://github.com/dracony
    http://github.com/phpixie
    

    View Slide