Is symfony2 production ready? - symfony1

I know that Symfony2 has been released, but is it production ready, or are they still finding and fixing so many bugs as to make it impractical?
How is performance in a production environment? Are there current benchmarks anywhere?
I'm looking to build an n-tier web site and am deciding on whether learning sf2 will be time well spent compared to just sticking with sf1.4.
What gaps are there in symfony2 - from what it seems there's no official admin generator. Is anything else missing?

I have released a Symfony 2 based project that was featured in a major newspaper and did well. I'd deem it as production ready. I also did some load tests with jMeter and the man from the hosting company was impressed by the performance.
The only thing lacking IMO is the amount of tutorial and special articles that you have for Symfony 1. Nevertheless, I'll use Symfony 2 for all my future projects.
One slight problem at the moment could be the hosting companies: You absolutely need PHP 5.3 (most companies still offer 5.2 only) and a caching mechanism (APC or memcached) for maximum Doctrine 2 performance.

Symfony2 is definitely production ready. The developers are just fixing minor bugs since the stable release. I know Fabien Potencier published some benchmark tests a while ago, but I can't find them. Maybe you'll have better luck. Anyway, I believe it's faster than any other framwork out there.
You're right when you say there isn't an official admin generator, but you can use SonataAdminBundle, which is absolutely awesome (but a little hard to get to work properly).

See here regarding the admin generator - apparently there is one :)
symfony2 propel crud generator

Related

Effort required to go from Symfony 1.4 to Symfony 2.0

I have a website written in Symfony 1.4. It was my first symfony website and the learning curve was a bit steep for me. It is a fairly complicated website, and I don't want to 'fix it' if its not broken.
Having said that, since sf 1.4 is now legacy code, I will eventually want to port the site to sf 2.0. as a matter of fact, I am relaunching the site early next year, and I want to know if I might just as well bite the bullet and "port" the site from 1.4 to 2.0 in one go.
So, I need to know answers to the following:
How much of what I already know from 1.4 is applicable to 2.0?
Are there any jobeet or askeet type tutorials out there that show how to build an entire app using the sf framework?
Am I mad, thinking of porting a big website in effectively just over a month (working only part time?) - i.e. is the "big bang" approach the wisest/only approach?
I don't want to 'fix it' if its not broken.
Don't!
Am I mad, thinking of porting a big website in effectively just over a month (working only part time?)
Yes, you are! :)
Symfony2 and symfony 1.4 are wildy different. We're not talking about some updates to symfony 1.x, we're talking about a brand new framework from the ground up. It's really like asking "How hard would it be to switch from symfony 1.4 to Zend Framework/Kohana/Yii/CakePHP/etc...".
I moved a project (in its very early stages) from symfony 1.4 to Symfony2 and found that except for my familiarity of the MVC pattern, not much (if anything) else was transferable from symfony 1.4 to 2. We're talking about new directory structures, new classes, Doctrine 2, the (awesome) Dependency Injection Container, and more.
Symfony2 has its own learning curve, and even though the architecture is better than symfony 1.4, you will be spending a good amount of time going through trial and error and reading the docs.
Symfony2 is great, and I recommend learning it, but do so at a manageable pace. There's a number of tutorials online - check them out and go through the official Symfony2 docs and cookbook when you're ready.
#Arms response is fantastic. Even though the answer has been accepted, I thought I'd add a few of my thoughts to the discussion.
I started work on the development of a personal project about a year ago. I chose symfony 1.4 because Symfony 2 wasn't in a stable phase and I was already an expert in symfony 1.4.
After working for a year in my spare time (I work a full time job) and this is what I have (and it's still growing, about 60% done):
70,000 lines of php code (Doctrine queries, actions, templates)
10,000 lines of custom javascript code
3000 lines of YAML
My schema.yml file for example is 872 lines which consists of 62 table definitions.
My routing file is 500 lines.
Moving a schema definition of that size over to Doctrine2 entities would be a mammoth task. It would take me a very long time. If I were to rewrite what I've done now to Symfony2. It would probably take me a year.
Transitioning over my current authentication system (sfDoctrineGuard) over to a symfony2 implementation would also big a big task. All my command line tasks, doctrine queries, templates would have to change.
In fact, everything would have to change. The only thing that would stay the same is the database username and password.
If I had the resources and time I would consider moving over to Symfony2. One of the biggest advantages I'd get is the performance gain and the better architecture that Symfony2 offers.
I work with symfony2 at the moment in my full time job and I like it a lot but there are still certain things which I'm not sure how to achieve in symfony2 which I know how to do in symfony 1.
For the moment, moving over to Symfony2 for my project is a definite NO. I'd like to but as I have said I don't have the time or resources to and plus the application is working very well indeed. Everything has been re-factured and I've been careful with the development to make sure I'm not repeating code.
Also, maintenance of Symfony 1.4 is due to end in about a year.
If it works well then don't change it. Only change it when you have the resources available and you're knowledgeable in Symfony2 to make sure you don't give yourself any headaches.
Best of luck.
Symfony 1.4 is not legacy code. It is still fully supported by the Symfony team and has a 3 year support promise which ends at the end of November 2012.

New Project: Ruby on Rails or Symfony2 ( or other framework)

I am about to start a new project and I am hung up on which language/framework to use. I've been a PHP programmer professionally, but it wasn't on the scale of this project. I've played around with RoR and i've been very impressed so far. Right now, the two leading candidtates are RoR and Symfony2.
My major hang ups with RoR:
- i don't know ruby, or i hardly do. i can read it ok, but get stuck writing the code.
- i've read complaints about it being slow, and it seems to be slow just at the CLI.
My major hang ups with Symfony2:
- there's practically no documentation for it. Symfony1.x? sure..but not symfony2
- there's also little support. the BB on their site is like 80% spam.
- went to install it on a local dev enviroment haven't been able to even get that running (see my first hang up)
this project will be fairly complex and go beyond the basic CRUD operations. it isn't under a super-tight timeline, but there is one. ~3 months for milestone1 which is basically a calendar, some financial organization stuff (not transactions with financial institutions, just personal finance organization type stuff), and a project manager/cms.
also, i'm open to using other frameworks, but symfony2 seems to be the best right now. if symfony2 had RoR's support/documentation/tutorials/etc it would be a no brainer.
i'm really interested in hearing what the stackoverflowverse has to say on the matter. im constantly impressed with the quality of the answers/replies on this site.
some other sub-questions (that are in my head right now):
- if you recommend a different php framework, why?
- what are you biggest gripes with any of the options mentioned?
i know CakePHP is the closest to RoR, but i've been reading that the models are a bit wonky (Many to many relationships and such).
right now, i'm leaning towards RoR. Simply put, i really want to learn it and it could do the job. i just don't know ruby and i've ready a lot of good about symfony2.
any advice you could offer will be greatly appreciated. thanks!
Personally, I'd recommend that if you're starting a new project which happens to be the largest project you've ever had to do then you should stick with what you know best. This happens to be PHP.
I've used Ruby or Rails. In fact, we have some production apps at our company that use RoR. The best way I learnt RoR was to work on small projects. I would never have considered to choose a programming language which I'm not familiar with and then on top of that learn a new framework to start coding a big project.
As for Symfony2, we started using it a couple of weeks ago. Symfony2 is an excellent framework and looks very promising. It's clean, nicely decoupled and fast. However, we ran into too many bugs/headaches/inconsistencies in Symfony2 to continue using it. We will start working on it again once it has matured and the documentation grows (lots of the docs are now out of date). Hopefully, they'll release some sort of Jobeet tutorial but for Symfony2.
Moving on to CakePHP. CakePHPs code base is old. In fact, it works fine on PHP 4.3.2. It doesn't take advantage of all the goodness that PHP5 has to offer (absract classes, interfaces, private & protected properties, exceptions, magic methods, annotations, pass objects by reference etc.) CakePHPs database abstraction layer, whilst it has had improvements, is not incredibly efficient once your database structures becomes too complex (many joins for example) it crumbles quite badly.
Moving on to Symfony 1.4 which I've used for many large projects
I enjoy using because:
PHP5
Event system
Dependency Injection
Caching system
Forms (nice integration into Doctrine 2) In fact, this is my favourite feature.
Many plugins (sfGuard for user management, for example)
Twig (nice templating language)
Highly configurable
Scalable (although not as fast as Symfony2)
A lot of documentation (Jobeet tutorial is great)
If PHP is for the moment your forte and you need to start working on a large project then start using a PHP based framework as you know the language syntax and functions the best.
Move onto RoR when you have a small project to do.
Just my 2 cents.
Best of luck.
To me Symfony2 has been great so far. Documentation is scarce compared to Symfony1.x but it's much easier to get started in Sf2 and, with things being very explicit, requires less knowledge of how the framework works internally.
There's an app/check.php script that will warn you of any dependency needed to run it, and support mostly happens in their mailing list which is very active (didn't even know there was a BB). Some components, like Twig, also have their own lists.
This is an old topic but things have changed a bit and I would recommend Symfony2. Their current documentation is great (symfony.com) and its much easier to learn for newbies. I did try RoR but with symfony I just got into it much quicker.
I'm amazed of how no one has mentioned the super rich GEM community for Ruby and therefore for Ruby on Rails, there is simply just so much functionality out there, so many people working on some many MIT/open source projects. To me, community is what drives me to go choose one framework over another. The amount of configurations and different template engines, there is just so much out there for ruby on rails.
For a comparison chart check this out:
http://vschart.com/compare/doctrine-php/vs/ruby-on-rails
At the end of the day it all boils down to whatever you know, but do not overlook the community and the functionality that has been written for you already, free of charge...
I'll echo solarc's comments about Symfony 2. I used it for a couple small projects, and am starting something more ambitious with it this week. I would like to see a complete Jobeet-style tutorial, but the main documentation is good enough to get started with IMHO. I'm giving that a thorough read, and have learned a few things that I missed using the documentation as a simple reference.
Finding bundles was my biggest frustration, but the documentation mentions knpbundles.com, and that seems like an excellent resource.

Symfony 2 or Symfony 1.4? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am starting a new Symfony project that will be very important to my company. My experience is only with Symfony 1.4. and I have 3 months to complete the project.
The project should be around for years and will grow to have many features. I know that many people are already using Symfony 2 in production, but do you think it's a bad idea to go with 1.4?
Every situation is different. I don't see any problem with 1.4, but some people are suggesting I use Symfony 2 because eventually we will need to upgrade and do a lot of rewriting of code.
Plus, there is Doctrine 2. I would be using 1.2.4. Again, I know that Doctrine 2 is really great, but am I going off a cliff by sticking with 1.2.4? It seems to do everything we need.
Thanks for any insight.
Why you should use Symfony 2.0:
Faster. Many Symfony components have seen performance improvements and it also now supports edge side includes.
Fixes weaker design. Symfony 1.x is great, but some components had flaws, like logging (now outsourced) and tasks (more flexible). Forms in 1.x were powerful, but had some flaws; forms in 2.0 are better.
It's the future. Symfony 1.x will expire before the lifetime of your project. You already said you will be rewriting it. It makes no sense to wait.
Cleaner, easier code. Namespaces, more decoupling, generally even more beautiful than Symfony 1.x was.
Doctrine 2.0. Way faster, way easier to use.
The only possible reason to go with 1.x is time concerns. However, if this project is that important, it makes more sense to increase the time limit (if it is unfeasible), then to do it in 1.x and waste all that time rewriting it later.
Well, Symfony 2.0 should really be your bet if you had more time to get the project done. Symfony 2.0 developers are still struggling to learn the right way to use all those nice standards and best practices.
The community using SF 1.4 is already mature and has solved every single problem that all the common (and others not common) scenarios could present.
All those arguments about speed do not apply to 90% (or more?) of projects built on SF. Unless you need a high performance webapp (serving more than 500-1000 requests/minute), you gonna be fine using SF 1.4. If you need to serve more than that you can always using one more server to the scene. An optimized SF 1.4 app can perform pretty good.
I'm trying to say that all the talk about performance is not a problem for most apps. People do not think about it when raising the speed flag.
SF 1.4 is a well structured framework. It really speed things up during development. SF 2.0 is a community under development. People are still developing solutions and plugins for the most common problems.
I'm still using SF 1.4 for all my new projects. Mainly because I got a lot done on it that get my projects done really fast. All my customers don't need a high performance webapp, however I have my own projects that need to be fast and after optimization they really are.
I've struggled with this since 1.0. Ok great i finished my 1dot 0 project wicked fire it up...no wait there is now 1.1...ok upgrade go through all the upgrade troubles... ok cool NOW it's ready to go but no wait 1.2 is out now...FFS... ok upgraded everything to 1.2 struggled through learning this new forms class and plugin issues cuz sfGuard needs a new version blah blah blah... ok now we are ready to go fire it up but no wait...they've release 1.3 AND 1.4 on the same day WTH. Ok how bad is this upgrade going to be??? phpmailer good swiftmailer bad. or is it the other way around this time. Oh FFS what is this symfony2 all about now.....
I'm sure i'm not the only one that has gone through that (or similar scenario)
what matters is what YOU know and what YOU are good at. Symfony 2 i'm sure is great awesome best ever blah blah blah. But if it takes you three months to get up to speed and work all the bugs out that WILL come up. Then you're better to go with 1.4 and build on what you know.
I'm sticking with 1.4 because i have a large code base that i've built up that works just fine. As you can see by the varied opinions though the debate could rage on for a while.
That's my two cents anyway.
I'm still doing my projects in Symfony 1.4, but outlining a strategy for yourself on how to make those changes towards 2.0 would be a good idea. Also, it sounds like there is some frustration with Doctrine, and Propel development seems to have been awakened. There may be a switch in many preferences towards Propel in the future.
Short term:
If you know that sf1.4 allows you to finish the project in the time you have doing all the stuff requested by the customer go with that.
Pro: you know it, no costs for you on technology
Cons: end of support November 2012, Lime for testing (or plugin for PHPUnit), using an "old" solution
Long term:
As you said the project should be around for years so I think that many developers will work on it. Sf2 is much more decoupled and uses PHPUnit for testing. Allows you to use ESI and performs very good with HTTP standards (no application cache).
Pro: brand new tool, very active project, a couple of steps above sf1.4, as web will evolve also Sf2 will embrace that changes and support development
Cons: you don't know it but you can hire someone to help you (GTD and learning a new framework)
Getting things done is more important than using the latest and greatest and although symfony 2 appears to be a better version all round, symfony 1.4 is still a great product, has a greater pool of knowledgeable developers and therefore if you do hit any stumbling blogs, you are much more likely to find a solution in a much shorter time.
For your purposes symfony 1.4 is good enough and will give you a greater appreciation of symfony if and when you decide to move over to symfony 2.
There are enough similarities between the versions to be able to gain useful knowledge through using symfony 1.4 and it means that for now, you get the best of both worlds -- useful experience for later on and getting things done.
Go with Symfony 2.
I'm doing the switch from 1.4 to 2 right now because of the advanced ACL features of Symfony 2.
It will save you a lot of time in the end.
I would go with symfony 2. You have all the feature improvements (faster, doctrine 2, etc etc etc), but that is not why I would go for it.
Symfony 2 has had thorough security testing, which is vital for any real project. Add tot hat the fact that long term support won't cover your projects lifetime, and it really is neccessary to build it in 2.
I just started my first project in SF2, after working for a few years in sf 1.x. There are a lot of changes, but it didn't take too long to adapt.

CakePHP, CodeIgniter or Rails for multi-user Tumblr clone?

I'm about to start building a tumblr clone that handles multiple users (so premade clones like Gelato won't cut it) and I'm not sure which framework I'd like to build this is.
Right now, I'm only intending to build a prototype. Something I can get a dozen friends on to test the concept and grow to maybe a couple hundred users to prove the market, so I'm not worried about long term scale. My biggest concern right now is quick deployment. I'd like to get from zero to signups in as short a time as possible, with as little customization to the framework of choice as possible.
I have experience with PHP, but not Ruby. However, I don't think the learning curve would be too steep so I'm not ruling out rails. I just want the framework that is most appropriate for a system like a multi-user tumblr clone so that I can build it with as little hassle, and as quickly, as possible.
If anyone has experience with a similar project, or with these frameworks and can offer an insightful perspective, I'd be very appreciative.
Thanks for taking the time to read.
Cheers,
~Jordan Feldstein
Definitely Rails. It'd much faster to develop project like this in Rails.
As far as I saw, PHP is lightyears behind from Rails in ORMs. And Rails routing is much better than any PHP framework's as well.
I have been developing in PHP since 2000, and still have a bunch of PHP systems in production (using both CodeIgniter and CakePHP).
I have found Rails to be incredibly more efficient to develop in ... easily 50% more productivity, depending on the use-case. Faster, higher quality. Easy choice for me.
+1 for Rails.
I can't speak about Codeigniter. My general understanding echoes the above statements. Lightweight and no fully object oriented.
I have developed in CakePHP since Jan 2006, after trying to get Rails deployed on my own server and failing badly. Rails was not easy to deploy back then...at least not for me. At the time Cake was the best alternative, and still is in many ways.
Cake is a very competent framework. However, I agree with the statements that it is in many ways far "behind" Rails. Some features are not as well designed, less integrated or simplified in comparison.
A few months ago I spent a couple of day porting one of my Cake apps to Rails2. Just as an exercise. The learning curve was very shallow for someone like me (with a decent grasp of the concepts that Cake and Rails are built on). We recently started porting one of our apps at work to Rails (also from Cake) because we found that support for a lot of things that are important to us are available in Rails or Ruby but not available or as complete in Cake and PHP.
If you are unsure about switching to Ruby you might want to look at Lithium (previously CakePHP v3). It is PHP 5.3 only and still a good way from 1.0 but the community is active and generally it looks like what Cake might have been if it had been started today and not 2005.
CodeIgniter is very lightweight, which is probably to the detriment of this project if you want to code as little as possible.
CakePHP is pretty much an attempt to port Rails to PHP, so choosing between those two frameworks will depend on other factors.
One factor would be whether you want to learn Ruby or not. I have dabbled in it, and feel it is superior to PHP, but more practical concerns keep me from experimenting with it more (have to use PHP at work).
Another concern would be hosting. I use Dreamhost, and the fee is the same for PHP and Rails. However, a friend of mine just got a GoDaddy hosting account, and he actually has to pay a higher monthly fee to have a Passenger-enabled host.

What (if any) technical debt am I incurring with Ruby on Rails?

I'm a big fan of ruby on rails, and it seems to incorporate many of the 'greatest hits' of web application programming techniques. Convention over configuration in particular is a big win to my mind.
However I also have the feeling that some of the convenience I am getting is coming at the expense of technical debt that will need to be repaid down the road. It's not that I think ROR is quick and dirty, as I think it incorporates a lot of best practices and good default options in many cases. However, it seems to me that just doesn't cover some things yet (in particular there is little direct support for security in the framework, and plugins that I have seen are variable in quality).
I'm not looking for religious opinions or flamewars here, but I'd be interested to know the community's opinion on what areas Rails needs to improve on, and/or things that users of Rails need to watch out for on their own because the framework won't hold their hand and guide them to do the right thing.
Regardless of framework the programmer needs to know what she's doing. I'd say that it's much easier to build a secure web application using something as mature, well designed and widely adapted as Ruby on Rails than going without the framework support.
Take care with plugins and find out how they work (know what you do, again).
I love Rails too, but its important for us to understand the shortcomings of the framework that we use. Though it might be a broad topic addressing these issues wont hurt anyone.
Aside from security issues, one other big issue is DEPLOYMENT on Shared Hosts. PHP thrives in shared hosting environments but Rails is still lagging behind.
Of course most professional Rails developers know that their apps need fine-tuned servers for production and they will obviously deploy on Rails-Specific hosts.
In order for Rails to continue success the core team should address this issue, especially with Rails 3.0 (Merb +Rails) coming..
An example of this is simple: I have a bluehost account, and i noticed the Rails icon in my cpanel. I talked to the bluehost support and they said its more or less a dummy icon, and that it doesn't function properly.
Having said that any professional who wanted to deploy a Rails App would not use bluehost. , but it does hurt Rails, when hosts say that they support it and then users run into problems which their support know nothing about..
The article you refer to defines technical debt as
[the] eventual consequences of
slapdash software architecture and
hasty software development
With rails, any development that is not test driven incurs technical debt. But that is the case with any platform.
At an architectural level Rails provides some deployment challenges. A busy site must scale with lots of hardware or use intelligent caching strategies.
My advice to anyone adapting Rails would be to:
use TDD for all your development
verify the quality off any plugin
you use by reading its tests. If
they are not clear and complete,
avoid the plugin
read "Rails
Recipes" and "Advanced Rails
Recipes" (Advanced Rails Recipes has
a good recipe for adding
authentication in a RESTful way)
be prepared to pay for hardware to scale your site (hardware is cheaper than development time)
From my experience, by far the biggest tolls you end up paying with RoR are:
Pretty big default stack (not counting plugins you might be using)
Updating models tends to be a pain in the ass, at least in production servers.
Updating Rails or Ruby themselves is a bit more complicated than it should, but this differs depending on your server setup.
As ewalshe mentioned, deployment is sometimes a drag, and further down the road, should you require it, scaling gets a bit iffy, as it does with most development frameworks.
That being said, I'm an avid user of RoR for some projects, and with the actual state of hardware, even though you do end up paying some tech debt to using it, it's almost negligible. And one can hope these issues will be reviewed eventually and solved.
With any level of abstraction there is a bit of a toll you pay - genericized methods aren't quite as fast as those specific to something built just for your purpose. Fortunately though, it's all right there for you to change. Don't like the query plans that come out of the dynamic find methods? write your own, good to go.
Someone above put it well - hardware is cheaper than developers. I'd add "at a sufficiently low amount of hardware"
I'm reading Deploying Rails Applications and recommend it highly to answer your concerns.
The book is full of suggestions to make life easier, taking a deployment-aware approach to your Rails development from scratch, rather than leaving it to later.
I don't think the choice of RoR implies a technical debt but just reading the first few chapters alerted me to practices I should be following, particularly on shared hosts, such as freezing the core rails gems so you can't be disrupted by upgrades on the host.
The 30-page chapter on Shared Hosts includes memory quote tips such as using multiple accounts (if possible) with one Rails app per account. It also warns about popular libraries such as RMagick possibly pushing your memory size to the point where your processes are killed (such as a 100MB limit, which it suggests some hosts periodically apply).

Resources