search

shaarli / Shaarli

The personal, minimalist, super-fast, database free, bookmarking service - community repo
https://shaarli.readthedocs.io/
Other
3.44k stars 295 forks source link

Use a PHP micro-framework #655

Closed ArthurHoaro closed 7 years ago

ArthurHoaro commented 8 years ago

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:

A few have been mentioned:

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

I'll look into it and post my feedback here

ArthurHoaro commented 8 years ago

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:

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
-------------------------------------------------------------------------------

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 commented 8 years ago

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.

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:

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:

Coverage:

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

+1 for using Slim, as:

ArthurHoaro commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 7 years ago

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