Wednesday, September 14, 2016

Using Silex and Symfony together in same application

I am testing the idea of having an application using both Silex and Symfony.

Why ?

Maybe because I want for some parts of the application to be really fast, and for the most of the application to enjoy the productivity of using a full stack framework and have access to all the third party bundles.

Of course having 2 application may introduce other kind of problems.

How my application should work:

- receive request
- fast Silex kernel handles the request.
     - if the URL request is not matching any of the routes from Silex, it will return a response with status 404
    -  if the URL is matching a route, execute controller and get response
- check what is the response from Silex
    - if the response has status 404 pass it to the Symfony kernel
   -  otherwise return response

Using the 2 frameworks together is possible because they both use the same abstraction for HTTP Request and Response and the HttpKernel.
There is a project called StackPHP that promotes interoperability between applications based on the HttpKernelInterface.

Implementation:


Create a probject folder under /var/www/public called double: /var/www/public/double
I will be using Symfony Standard Edition and Silex Skeleton project by Fabien Potencier: https://packagist.org/packages/fabpot/silex-skeleton

Install using Composer in two different subfolders:

   composer create-project fabpot/silex-skeleton  silex  ~2.0@dev
   composer create-project symfony/framework-standard-edition symf


Create a virtual host that will point to /var/www/public/double/symf/web
You may want to first save Symfony app.php and app_dev.php before editing them:
app_dev.php :

<?php

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Debug\Debug;
use Silex\Application;



/**
 * @var Composer\Autoload\ClassLoader $loader
 */
$loader = require __DIR__.'/../app/autoload.php';
require_once __DIR__.'/../../silex/vendor/autoload.php';

Debug::enable();

//create request object
$request = Request::createFromGlobals();

//initialize Silex app
$app = require __DIR__.'/../../silex/src/app.php';
require __DIR__.'/../../silex/config/dev.php';
require __DIR__.'/../../silex/src/controllers.php';
//handle request with Silex app
$response = $app->handle($request); if ($response->getStatusCode() === 404) {
    //initialize Symfony app and handle request
    $kernel = new AppKernel('dev', true);
    $kernel->loadClassCache();
    $response = $kernel->handle($request);
    $response->send();
    $kernel->terminate($request, $response);

} else {
    $response->send();
    $app->terminate($request, $response);
}


Into app.php I've added microtime() function to get the loading time in production as I do not have access to the Web Profiler.


<?php

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Silex\Application;

$time_start = microtime(true);
/**
 * @var Composer\Autoload\ClassLoader $loader
 */
$loader = require_once __DIR__.'/../app/autoload.php';
require_once __DIR__.'/../../silex/vendor/autoload.php';


//create request object
$request = Request::createFromGlobals();

//initialize Silex app
$app = require __DIR__.'/../../silex/src/app.php';
require __DIR__.'/../../silex/config/prod.php';
require __DIR__.'/../../silex/src/controllers.php';

$response = $app->handle($request);

if ($response->getStatusCode() === 404) {


    $kernel = new AppKernel('prod', false);
    $kernel->loadClassCache();
    $response = $kernel->handle($request);
    $response->send();
    $kernel->terminate($request, $response);

    $time_end = microtime(true);
    $time = $time_end - $time_start;

    echo "Execution time: $time seconds\n";

} else {
    $response->send();
    $app->terminate($request, $response);

    $time_end = microtime(true);
    $time = $time_end - $time_start;

    echo "Execution time: $time seconds\n";
}


I did some simple tests using the production env (app.php) and generally Silex is 3 times faster than Symfony, which is no surprise as it is lighter.
In Silex I used Doctrine DBAL (not ORM), the provider it is included in the Silex Skeleton project, just needs to be configured in src/app.php:



$app->register(new DoctrineServiceProvider(), array(
    'dbs.options' => array (
        'localhost' => array(
            'driver'    => 'pdo_mysql',
            'host'      => 'localhost',
            'dbname'    => 'symfony',
            'user'      => 'root',
            'password'  => 'root',
            'charset'   => 'utf8',
        )
    ),
));

Thursday, September 8, 2016

Multilingual website with Symfony

If you want to create a multilingual website, Symfony together with the community bundles have the tools for a fast set up.

When creating a multilingual website we need to take in account translating:

  1. Specific routes per language
  2. Menus, labels and forms
  3. The content of the website
  4. Extra: translate FOSUserBundle

1. Routes 

It may be tempting to use the same URL to display a resource in different languages based on the user's locale. For example, http://www.example.com/contact could show content in English for one user and French for another user. Unfortunately, this violates a fundamental rule of the Web: that a particular URL returns the same resource regardless of the user. To further muddy the problem, which version of the content would be indexed by search engines?
A better policy is to include the locale in the URL. This is fully-supported by the routing system using the special _locale parameter, see documentation:

The term locale refers roughly to the user's language and country. It can be any string that your application uses to manage translations and other format differences (e.g. currency format). The ISO 639-1 language code, an underscore (_), then the ISO 3166-1 alpha-2 country code (e.g. fr_FR for French/France) is recommended.

In config.yml add the following:

parameters:    locale: en_GB
    app.locales: en_GB|es_ES|fr_FR

framework:
    translator:  { fallbacks: ["%locale%"] }

By declaring the list of accepted as parameter you can easily use it in all routes declarations:

/** 
 * @Route("/{_locale}/product",  
 *     name="product",  
 *     requirements={ "_locale" = "%app.locales%" }) 
 */
public function productAction(Request $request)

By doing this, a route will look like this : www.mysite.com/en_GB/product

 2. Translations - labels, menus etc.

Translation of text is done through the translator service (Translator). To translate a block of text (called a message), use the trans() method, or in Twig using trans and transchoice tags.
The recommended way is to have message placeholders which will be translated using a translation file (one per each language).  An example would be a menu button that in english should show "About". We can create a placeholder named:  "menu.about" which will be translated in Twig:

     {{ 'menu.about'|trans }}

The translation files can have different formats (like YAML of XLIFF) and they live usually in app/Resources/translations, or under Resources/translations in your bundle.

I will be using YAML,  so I will create the files "messages.en_GB.yml" , "messages.es_ES.yml" etc.
Inside I add the placeholder and the translation:

button.product.view_detail : View detail

3. Content translation

One solution would be to create yourself the entities and handle the process. Imagine having a Product entity containing fields that do not need translation, like Id, Price and another entity ProductTranslation containing translatable fields like Name and Description. These two will be in a relation (example: OneToMany).

Another way is to use some community bundles that handle these process for us. I will be using KnpLabs/DoctrineBehaviors  and A2Lix TranslationBundle

Install DoctrineBehaviors and add translatable: true to config.yml  :

knp_doctrine_behaviors:    ...
    translatable:   true


Create your entities following the tutorial from documentation. Be careful that there are two different traits to be used in Entity and EntityTranslation classes.Do not add id field to the EntityTranslation class as it will be taken care by the traits. Update database structure:  php bin/console doctrine:schema:update  --force
I am using DoctrineFixturesBundle to add some data. For adding an apple(fruit) product the code is:


$product = new Product();
$product->translate('en')->setName('Apple ');
$product->translate('es')->setName('Manzana ');
$product->translate('en')->setDescription('Sweet apple');
$product->translate('es')->setDescription('Manzana dulce ');
$product->setImage('apple.jpeg');
$product->setCurrency($currency);
$product->setPrice(1.00);
$product->setActive('1');
$manager->persist($product);
$product->mergeNewTranslations();



In the database, I have a product_translation table where the information is saved. 
In controller I am retrieving the product object just as usual:


    $product = $em->getRepository('AppBundle:Product')->find($id);

In order to display the translatable fields in the current language in Twig I use:

    {{ product.translate(app.request.locale).name }}


For handling translation from the website interface you can use A2Lix TranslationBundle which will create a form with tabs for each translation (I've installed the version 3.x)

I've generated a ProductType class and added another line in code after adding my non translatable fields:  


use A2lix\TranslationFormBundle\Form\Type\TranslationsType;
...
$builder    ->add('active')
    ->add('price')
    ));
$builder->add('translations', TranslationsType::class);


4. Extra: translate FOSUserBundle

FOSUserBundle is one of the most popular Symfony bundles. You can easily activate translation by following the instructions from the link below:

https://codereviewvideos.com/course/getting-started-with-fosuserbundle/video/translations-and-internationalisation-in-fosuserbundle

Friday, September 2, 2016

Replace Symfony reverse proxy with Varnish

In my last post I've presented how to start caching pages with the reverse proxy shipped with Symfony Standard Edition. But as it is mentioned in the documentation the built in PHP proxy is not as fast as Varnish for example. So today I will do a small test with Varnish instead of the Symfony reverse proxy (AppCache).

First install Varnish on virtual machine with Ubuntu (I am using https://box.scotch.io ):

    sudo apt-get install varnish -y

Edit Varnish configuration file found at: /etc/varnish/default.vcl. I have a virtual host called myshop.dev, I will put that as host.

Example of Varnish configuration file for Symfony:

backend default {
    .host = "myshop.dev";
    .port = "80";
}

sub vcl_fetch {
    /* By default, Varnish3 ignores Cache-Control: no-cache and private
      https://www.varnish-cache.org/docs/3.0/tutorial/increasing_your_hitrate.html#cache-control
     */
    if (beresp.http.Cache-Control ~ "private" ||
        beresp.http.Cache-Control ~ "no-cache" ||
        beresp.http.Cache-Control ~ "no-store"
    ) {
    return (hit_for_pass);
    }

}

sub vcl_recv {
     unset req.http.Forwarded;

   if (req.http.Cookie) {

        set req.http.Cookie = ";" + req.http.Cookie;
        set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
        set req.http.Cookie = regsuball(req.http.Cookie, ";(PHPSESSID)=", "; \1=");
        set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
        set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
        if (req.http.Cookie == "") {
            unset req.http.Cookie;
        }
    }


    // Add a Surrogate-Capability header to announce ESI support.

    set req.http.Surrogate-Capability = "abc=ESI/1.0";
}

sub vcl_fetch {

    if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
        unset beresp.http.Surrogate-Control;
        set beresp.do_esi = true;
    }
}

sub vcl_deliver {

  if (obj.hits > 0) { # Add debug header to see if it's a HIT/MISS
    set resp.http.X-Cache = "HIT";
  } else {
    set resp.http.X-Cache = "MISS";
  }
  # show how ofthe the object created a hit so far (reset on miss)
  set resp.http.X-Cache-Hits = obj.hits;
}

Configure Symfony config.yml file:

framework:
    esi:   { enabled: true }
    trusted_proxies: [127.0.0.1]
    fragments:  { path: /_fragment }

With these configuration in place you can open the browser and  call your page via Varnish on port 6081:

http://myshop.dev:6081/

If is not working you can try to restart Varnish service:  sudo service varnish restart


One source of information:  http://by-examples.net/2014/12/19/speeding-up-symfony-with-varnish.html

Introduction to Symfony HTTP Cache

You can start using the HTTP Gateway Cache that is shipped with Symfony by editing app.php file:

    $kernel = new AppKernel('prod', true);
    $kernel->loadClassCache();
    // wrap the default AppKernel with the AppCache one
    $kernel = new AppCache($kernel);

I've put the debug mode to be able to see the X-Symfony-Cache header in Firebug. You may want to delete the cache for prod environment before  refreshing the page. When loading the page, you can see in Firebug the Response headers:

    Cache-Control       no-cache
    X-Symfony-Cache   GET /: miss

So we do not have any Cache control directives set and our reverse proxy says it cannot find the path "/" in the list of cached information.

Let's make the response cacheable using Cache Expiration strategy.

In controller:

    $response =  $this->render('default/index.html.twig');
    $response->setSharedMaxAge(30);

    // (optional) set a custom Cache-Control directive
    $response->headers->addCacheControlDirective('must-revalidate', true);
    return $response;

Delete the cache and reload the page:

 First time: loading time is 4.28s according to FireBug
 Response headers:

     Age 0
     X-Symfony-Cache GET / : miss, store

 Reload second time: loading time is 82ms

     Age 9
     X-Symfony-Cache GET/ : fresh

 Reload third time loading time is 1.86 s

    Age 0
    X-Symfony-Cache GET / : stale, invalid, store

Things work as expected, the response time lowered to 82ms.


Now I will be testing the HTTP Cache Validation strategy.

     /**
     * @Route("/", name="homepage_symfony")
     */    
    public function indexAction(Request $request)
    {
        $text = "Welcome!";
        $response = new Response(); 
        $response->setETag(md5($text)); 
        $response->setPublic(); // make sure the response is public/cacheable
        if ($response->isNotModified($request)) { 
            return $response; 
        };

        $response->setContent($this->renderView('default/index.html.twig', array('content'         => $text)));
        return $response;
   }


First delete cache. Than reload page in browser:

First time:
X-Symfony-Cache  GET /: miss, store

Second time:
X-Symfony-Cache  GET /: stale, valid, store

At this moment there is not a big improvement as we are not avoiding any complex logic, just that instead of rendering the page with Twig we are serving it from cache.


Expiration and Validation 

You can of course use both validation and expiration within the same Response. As expiration wins over validation, you can easily benefit from the best of both worlds. In other words, by using both expiration and validation, you can instruct the cache to serve the cached content, while checking back at some interval (the expiration) to verify that the content is still valid. (from Symfony doc)

I will add setSharedMaxAge(30)to the controller resulting:

public function indexAction(Request $request)
{
    $text = "Bun venit pe pagina";
    $response = new Response();
    $response->setETag(md5($text));
    $response->setPublic(); // make sure the response is public/cacheable
    $response->setSharedMaxAge(30);
    if ($response->isNotModified($request)) {  
          return $response;
    }; 
   $response->setContent($this->renderView('default/index.html.twig', array('content' => $text)));
    return $response;
}

For 30 seconds the cache will be fresh and the page will be served from cache. After that using the ETag the freshness of the cache will checked and if it is still fresh the controller will return a 304 status with an empty content to the HTTP Cache which will serve again the response from cache.

First time loading the page:

Age               0
Cache-Control  public, s-maxage=30
Etag    "9c8751de832e5a472655e87731c49419-gzip"
X-Symfony-Cache  GET /: miss, store

Second Time:

Age   5
X-Symfony-Cache   GET /: fresh

After more than 30s

Age     5 
X-Symfony-Cache GET /: stale, valid, store