New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Short guide explaining how to migrate from Silex to Symfony 4+ Flex #8678

Open
javiereguiluz opened this Issue Nov 16, 2017 · 12 comments

Comments

Projects
None yet
@javiereguiluz
Member

javiereguiluz commented Nov 16, 2017

Silex ends as a project in June 2018. Lots of people still using it. Even if Sf4 + Flex ideas are pretty similar to Silex, it takes some time to learn the new concepts and philosophy.

Could we prepare a short upgrading guide for Silex users? It wouldn't be a comprehensive and ultra detailed guide, just a quick overview of the main changes: where to put the app config, how to define services, controllers + routes with annotations, etc.

If you are a Silex developer, please add a comment here telling us what would be the most important things to explain. Thanks!

@pdelmoral

This comment has been minimized.

Show comment
Hide comment
@pdelmoral

pdelmoral Nov 21, 2017

If you are a Silex developer, please add a comment here telling us what would be the most important things to explain. Thanks!

  • Dependency Injection
  • Routes

pdelmoral commented Nov 21, 2017

If you are a Silex developer, please add a comment here telling us what would be the most important things to explain. Thanks!

  • Dependency Injection
  • Routes
@mathieuimbert

This comment has been minimized.

Show comment
Hide comment
@mathieuimbert

mathieuimbert Dec 1, 2017

  • Security Firewalls
  • Services & autowiring
  • Middlewares

mathieuimbert commented Dec 1, 2017

  • Security Firewalls
  • Services & autowiring
  • Middlewares
@antoniocambados

This comment has been minimized.

Show comment
Hide comment
@antoniocambados

antoniocambados Dec 1, 2017

I should be migrating a project pretty soon. Not that these are particularly hard to migrate in my case, but my main concerns are:

  • Migrating middlewares
  • Turning services and service providers into Symfony services

antoniocambados commented Dec 1, 2017

I should be migrating a project pretty soon. Not that these are particularly hard to migrate in my case, but my main concerns are:

  • Migrating middlewares
  • Turning services and service providers into Symfony services
@GawainLynch

This comment has been minimized.

Show comment
Hide comment
@GawainLynch

GawainLynch Dec 2, 2017

My First Upgrade from Silex 2 to Symfony 4 / Flex

This is just a few notes on the way I approached my first cut-over of a project from Silex to Symfony 4 & Flex. The most important thing I think I would point out for those of us very used to Silex is:

  • Rule #1 … Don't fear the change, embrace it!

Stuff might feel "different" or "unnatural" at first, but you quickly adapt and grow attached to the change.

Before you go too far, give this a good read:

… don't try to "get" everything now, but having some of it in your mental view will help a lot of this "click" pretty quickly.

Next thing I found valuable was to composer create-project symfony/skeleton && cd skeleton && php -S 127.0.0.1:8000 -t public and have a look at what you've got … a very simple starting point.

Then I did a bunch of composer requires to start adding the external dependencies I knew I was going to require and in a few minutes I had the beginning of what I needed to start porting my Silex project, things like:

  • composer.json
    • "require"
    • "require-dev"
    • "config"
    • "scripts"
  • symfony.lock
  • bin/console
  • config/*
  • public/index.php
  • src/Kernel.php
  • .env
  • .env.dist

A huge wall you can hit at this point is copying these over, pressing F5 in your browser and watching everything crash. 😄

What I chose to do at this point was to edit my config/services.yaml file and comment out this section:

    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Repository,Tests}'
    App\Controller\:
        resource: '../src/Controller'
        tags: ['controller.service_arguments']

That stopped the DI compiler from scanning every class in src/ and causing a lot of pain trying to port your service classes over.

HUGE NOTE: This approach circumvents a lot of what makes autowiring awesome, you wouldn't normally do this on a new project, but it also allows you to slowly progress though your migration without too much pain.

Important tip, you two best friends at this point in time:

  • ./bin/console debug:container
  • ./bin/console debug:autowiring

😉

Next, I went through each of my own project's service providers and added the services one by one (as needed) to config/services.yaml

For example, a Twig extension's runtime class:

    App\Twig\Extension\MyRuntime:
        autowire: true
        tags:
            - { name: twig.runtime }

Once you have your base serviced looking like they're wired up, move onto your controllers. I enabled them in my config/services.yaml
one at a time like so:

    App\Controller\MyFirstController:
        tags: ['controller.service_arguments']

The allowed me to step through each one, get it loading and move on. Depending on dependencies you might have to jump through a few iterations of this process.

Depending on the size and complexity of your project, this should get a lot of them close to cut-over. My first one was less than two hours to migrate.

GawainLynch commented Dec 2, 2017

My First Upgrade from Silex 2 to Symfony 4 / Flex

This is just a few notes on the way I approached my first cut-over of a project from Silex to Symfony 4 & Flex. The most important thing I think I would point out for those of us very used to Silex is:

  • Rule #1 … Don't fear the change, embrace it!

Stuff might feel "different" or "unnatural" at first, but you quickly adapt and grow attached to the change.

Before you go too far, give this a good read:

… don't try to "get" everything now, but having some of it in your mental view will help a lot of this "click" pretty quickly.

Next thing I found valuable was to composer create-project symfony/skeleton && cd skeleton && php -S 127.0.0.1:8000 -t public and have a look at what you've got … a very simple starting point.

Then I did a bunch of composer requires to start adding the external dependencies I knew I was going to require and in a few minutes I had the beginning of what I needed to start porting my Silex project, things like:

  • composer.json
    • "require"
    • "require-dev"
    • "config"
    • "scripts"
  • symfony.lock
  • bin/console
  • config/*
  • public/index.php
  • src/Kernel.php
  • .env
  • .env.dist

A huge wall you can hit at this point is copying these over, pressing F5 in your browser and watching everything crash. 😄

What I chose to do at this point was to edit my config/services.yaml file and comment out this section:

    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Repository,Tests}'
    App\Controller\:
        resource: '../src/Controller'
        tags: ['controller.service_arguments']

That stopped the DI compiler from scanning every class in src/ and causing a lot of pain trying to port your service classes over.

HUGE NOTE: This approach circumvents a lot of what makes autowiring awesome, you wouldn't normally do this on a new project, but it also allows you to slowly progress though your migration without too much pain.

Important tip, you two best friends at this point in time:

  • ./bin/console debug:container
  • ./bin/console debug:autowiring

😉

Next, I went through each of my own project's service providers and added the services one by one (as needed) to config/services.yaml

For example, a Twig extension's runtime class:

    App\Twig\Extension\MyRuntime:
        autowire: true
        tags:
            - { name: twig.runtime }

Once you have your base serviced looking like they're wired up, move onto your controllers. I enabled them in my config/services.yaml
one at a time like so:

    App\Controller\MyFirstController:
        tags: ['controller.service_arguments']

The allowed me to step through each one, get it loading and move on. Depending on dependencies you might have to jump through a few iterations of this process.

Depending on the size and complexity of your project, this should get a lot of them close to cut-over. My first one was less than two hours to migrate.

@sedatsevgili

This comment has been minimized.

Show comment
Hide comment
@sedatsevgili

sedatsevgili Dec 4, 2017

We have an enterprise-level silex app and looked a way to convert only the framework layer about 2 weeks ago.

  1. We did not have any problem about composer dependencies. Everything was ok for our 3rd party libs.
  2. Autowiring and autoconfiguring was so helpful.
  3. We had to define a public snc_redis.cache alias in services.yaml (because we had to get it from container directly).
  4. Created a facade for the \Silex\Application. Because of we wired manually so many things into it and used it in our so many controllers & services, we have to create a facade of it.
  5. Translation just did not work. I don't know why but giving path of our resources did not help.
  6. We could not find an easy way to convert and use custom middlewares in the Symfony stack.
  7. We did not use env variables. Instead of it, used our custom config things.
  8. Profiler was ok in our dev environment. However could not profile any dql. There was an issue about that maybe dont exist any more.
  9. You have to check Bundle compatibility

sedatsevgili commented Dec 4, 2017

We have an enterprise-level silex app and looked a way to convert only the framework layer about 2 weeks ago.

  1. We did not have any problem about composer dependencies. Everything was ok for our 3rd party libs.
  2. Autowiring and autoconfiguring was so helpful.
  3. We had to define a public snc_redis.cache alias in services.yaml (because we had to get it from container directly).
  4. Created a facade for the \Silex\Application. Because of we wired manually so many things into it and used it in our so many controllers & services, we have to create a facade of it.
  5. Translation just did not work. I don't know why but giving path of our resources did not help.
  6. We could not find an easy way to convert and use custom middlewares in the Symfony stack.
  7. We did not use env variables. Instead of it, used our custom config things.
  8. Profiler was ok in our dev environment. However could not profile any dql. There was an issue about that maybe dont exist any more.
  9. You have to check Bundle compatibility
@derrabus

This comment has been minimized.

Show comment
Hide comment
@derrabus

derrabus Dec 11, 2017

Contributor

We could not find an easy way to convert and use custom middlewares in the Symfony stack.

Middlewares are just event listeners under the hood. You should be able to convert all of your middlewares to event subscribers before migrating to Symfony.

Examples:

Contributor

derrabus commented Dec 11, 2017

We could not find an easy way to convert and use custom middlewares in the Symfony stack.

Middlewares are just event listeners under the hood. You should be able to convert all of your middlewares to event subscribers before migrating to Symfony.

Examples:

@derrabus

This comment has been minimized.

Show comment
Hide comment
@derrabus

derrabus Dec 20, 2017

Contributor

I have prepared a small script to export routes from a Silex application. Maybe this is helpful for someone here: https://gist.github.com/derrabus/4d7b7b3a6ffc0c1ccc1037ce2a66b13c

Contributor

derrabus commented Dec 20, 2017

I have prepared a small script to export routes from a Silex application. Maybe this is helpful for someone here: https://gist.github.com/derrabus/4d7b7b3a6ffc0c1ccc1037ce2a66b13c

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77
Contributor

lsmith77 commented Dec 22, 2017

@FbN

This comment has been minimized.

Show comment
Hide comment
@FbN

FbN Apr 15, 2018

Learned today about SILEX dead sentece. If you don't like Synfony 4 I think SLIM is a great alternative very similar to Silex. Is micro, is based on Pimple, it's PSR7, has middleware support, have a great community. I think would very easy to migrate from silex to slim, maybe easier than to Symfony 4.

FbN commented Apr 15, 2018

Learned today about SILEX dead sentece. If you don't like Synfony 4 I think SLIM is a great alternative very similar to Silex. Is micro, is based on Pimple, it's PSR7, has middleware support, have a great community. I think would very easy to migrate from silex to slim, maybe easier than to Symfony 4.

@MaPePeR

This comment has been minimized.

Show comment
Hide comment
@MaPePeR

MaPePeR Apr 16, 2018

@FbN not sure about that "easier to SLIM than Symfony 4/Flex":

  • SLIM does not have argument resolving for Controllers if i read the documentation correctly. So one would have to touch every Controller and do the Argument resolving manually.
  • The Syntax for defining routes is similar, but not identical. At least assert and default values are different. So one would need to touch every Route.
  • The "Middleware"-Feature is implemented in a totally different way, so one has to bascially reimplement them.

There are probably a lot more points i'm not even aware of, yet.

EDIT: I'm not really awake, yet, so i forgot to think about how these "difficult" migration steps actually compare to what one has to do to migrate to Symfony 4/FLEX.

MaPePeR commented Apr 16, 2018

@FbN not sure about that "easier to SLIM than Symfony 4/Flex":

  • SLIM does not have argument resolving for Controllers if i read the documentation correctly. So one would have to touch every Controller and do the Argument resolving manually.
  • The Syntax for defining routes is similar, but not identical. At least assert and default values are different. So one would need to touch every Route.
  • The "Middleware"-Feature is implemented in a totally different way, so one has to bascially reimplement them.

There are probably a lot more points i'm not even aware of, yet.

EDIT: I'm not really awake, yet, so i forgot to think about how these "difficult" migration steps actually compare to what one has to do to migrate to Symfony 4/FLEX.

@derrabus

This comment has been minimized.

Show comment
Hide comment
@derrabus

derrabus Apr 16, 2018

Contributor

Please don't turn this thread into a framework battle.

Contributor

derrabus commented Apr 16, 2018

Please don't turn this thread into a framework battle.

@p3x-robot

This comment has been minimized.

Show comment
Hide comment
@p3x-robot

p3x-robot Aug 31, 2018

I was thinking I would migrate to Symfony 4, but it so much complex just a few routes and I have to add in yml, services, console, do not need it at all, it is already overloaded by using twig anyway, I will keep Silex, it is complete as it is.
Silex = microframework
Symfony = macroframework

p3x-robot commented Aug 31, 2018

I was thinking I would migrate to Symfony 4, but it so much complex just a few routes and I have to add in yml, services, console, do not need it at all, it is already overloaded by using twig anyway, I will keep Silex, it is complete as it is.
Silex = microframework
Symfony = macroframework

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment