Use a PHP micro-framework

[ArthurHoaro]

There has been discussions leading to the proposal of using a PHP micro-framework to improve Shaarli's architecture. See #616 (API) and #631 (using proper controllers).

This framework should be able to handle:

• routes,
• a middleware with dependencies injection (PluginManager, ConfigManager, RainTPL, etc.),
• and be "micro", we need to keep Shaarli fast.

A few have been mentioned:

• Silex: based on Symfony components.
• Slim.
• Flight, which I noticed while looking for an API framework.

Pro: this would help us to go further with the refactoring while relying on heavily tested and stable tools (and finally tear down this huge index.php).
Con: I'm a bit concerned about our current URLs, especially permalinks.

I'd like everyone opinion on this.

[ArthurHoaro]

I'm for using one of these, it's going to help up greatly with the maintenance and code readability when done.

About the framework choice, they seem pretty similar. Slim documentation seems to be a bit clearer and complete, so +1 for Slim.

[kalvn]

I'm also in favor of a micro-framework. They are becoming more and more popular and have for most of them a big community which ensures sufficient durability. And clearly the gain would be huge in terms of organisation (also to make it easier for people to help on the code).

Although my choice would clearly go for Slim, which I use already a lot (great documentation, already a few security middlewares, nice skeletons, etc.), it might be interesting to gather more information about their performances and communities.

I was able to find this comparative study (but I've no idea if it's trustworthy). I also had a look at Google Trends to have an idea of the popularity of those frameworks.

[virtualtam]

Some points we might want to take into account to keep Shaarli simple and lightweight:

• number of PHP dependencies (this could grow fast)
• documentation quality
• test coverage ;-)

I'll look into it and post my feedback here

[ArthurHoaro]

Good points. I took a look at SLOC and dependencies. SLOC isn't really an indicator about performances, but still, it gives an idea of the project size.

I don't think we need to worry too much about test coverage since they're all popular framework (and tested, I didn't look too much into it).

Silex

requires PHP 5.5

Silex git:(master) cloc src
      61 text files.
      60 unique files.                              
       2 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.10 s (591.6 files/s, 53446.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             57            768           1503           2994
JSON                             2              0              0             65
-------------------------------------------------------------------------------
SUM:                            59            768           1503           3059
-------------------------------------------------------------------------------

Dependencies:

• pimple: dependency injection container, part of SensioLabs.
• symfony/event-dispatcher
• symfony/http-foundation
• symfony/http-kernel
• symfony/routing

Slim

requires PHP 5.5

Slim git:(3.x) cloc Slim 
      45 text files.
      45 unique files.                              
       0 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.08 s (552.7 files/s, 100022.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             45            799           4015           3329
-------------------------------------------------------------------------------
SUM:                            45            799           4015           3329
-------------------------------------------------------------------------------

• pimple: dependency injection container (part of SensioLabs).
• PSR HTTP Message: PSR standard (interfaces).
• nikic/fast-route: the router is actually a dependency.
• container-interop/container-interop: just an interface to define the container format.

Flight

requires PHP 5.3

flight git:(master) cloc flight 
      11 text files.
      11 unique files.                              
       0 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.03 s (354.3 files/s, 72923.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             11            286            988            990
-------------------------------------------------------------------------------
SUM:                            11            286            988            990
-------------------------------------------------------------------------------

Dependencies: None.

---

Ping #599 - if we want to use Slim or Silex, we need to drop PHP 5.3/4 compatibility first.
Also, Flight seems to be a bit more light than the two others.

[virtualtam]

if we want to use Slim or Silex, we need to drop PHP 5.3/4 compatibility first.

+1, #599 could be shifted to the next milestone

---

I was able to find this comparative study (but I've no idea if it's trustworthy).

No idea either :)
The article doesn't seem to be based any relevant metrics, e.g.

• number of requests served over a given duration
• resource (CPU, memory) overhead when processing and routing requests

Such a benchmark can be found here: https://github.com/kenjis/php-framework-benchmark

---

#266 updated as both Slim & Silex provide integrations with HTML template engines:

• https://github.com/slimphp/Twig-View
• https://github.com/slimphp/Slim-Views
• http://silex.sensiolabs.org/doc/master/providers/twig.html

---

Hereafter are (in no particular order) some things I noticed while fiddling with the frameworks' sources, documentation and test suites.

Silex comes with plenty of dev dependencies, which, in turn, come with even more dependencies.

Workspace size after prod+dev dependency resolution:

• Flight: 9 MiB
• Silex: 220 MiB (!)
• Slim: 20 MiB

Coverage:

• Flight: 57%, 73 tests, 534 LLOC
• Silex: 95%, 288 tests, 1223 LLOC
• Slim: 98%, 557 tests, 1438 LLOC

Note: @ArthurHoaro I think the cloc stats from the previous comment include test code :)

---

+1 for using Slim, as:

• Flight has a very small community (compared to Silex/Slim)
• Silex comes with way too many dev dependencies (probably inherent to it being a Symfony app)

[ArthurHoaro]

Nope I ran it on Slim subfolder.
Note regarding size that you included test dependencies. Slim is somewhere around ~750kB for its code and --no-dev dependencies and not 20MB thankfully.

as both Slim & Silex provide integrations with HTML template engines:

We can probably make RainTPL work with Slim. I definitely don't want to switch engine now.

[virtualtam]

Yup, my comment was specifically targeting the number and size of test deps (took around 2min with a DSL connection to resolve them for Silex O_o)

It should be easy to hook Slim with RainTPL, I'll experiment with it over the weekend (kinda related to #613 as well).

[ghost]

I like where this is going. +1 for Slim, used it quite a bit in the past.
Writing a View Adapter for RainTPL should be relatively easy, although I'm a bit of a Smarty guy myself.
So this looks like a complete rewrite, huh?

Update: RainTPL was not updated for about two years, might have been abandoned. Should not be a problem today, but might become one in the future.

[ArthurHoaro]

@virtualtam Composer update takes me forever anyway with xdebug enabled.

@thomaswormann Not really a full rewrite, thanks to everyone work, but a lot of copy-paste, variable/call replace and tests.

[kalvn]

Twig-View and PHP-View projects might be good starting points for creating a RainTPL view.

+1 for @thomaswormann point about the current status of RainTPL. But there is no emergencies right now as it still works perfectly with PHP 7. And also because it would completely break compatibility with existing themes and it would require a lot of additional work for the redesign branch. It could be something to keep in mind for when custom themes will be officially supported.

[virtualtam]

Closing as we've settled on using Slim for the REST API (and internal routing in the future)