With coming of the eZ Publish CMS version 5 and introduction of the Public API a new naming convention was established, the version 4 technology was called legacy stack and the new technology, with the Public API as the cornerstone, was called the new stack. Recently by using this new stuff more and more I realised that this naming is a bit misleading.
We should call the version 5 technology the hybrid stack. The word hybrid describes the situation in the best way. You might call it legacy+new stack or dual kernel, but those terms implicate that you can use each stack/kernel independently. Which is not the case, at least not in our projects, they tend not to be simple :)
Of course you could use the legacy stack by it self, but then you loose some good new improvements, not to mention huge feature set available from the Symfony community. Don't forget that the legacy stack is not being significantly improved for a while. On the other side the new stack is still not ready to be used on its own, there are some big parts missing. So you still need to fallback to legacy.
And from the eZ Roadmap (slide 24) we can see that once the new stack is fully implemented and can work on its own it will become version 6. So, going back to the naming issue, I think I have a strong case to call the version 5 a hybrid stack. We need and use both stacks.
And that is tough and challenging. First, it requires solid experience with the legacy code and conventions, secondly, it requires fast adoptions of Symfony knowhow and Public API usage. It could get quite confusing if you miss one of those two things.
With recent minor version (5.2) it started to make sense to use this hybrid approach, as most our projects are not simple ones: we use lot of older extensions, we use ezfind lots of times, etc. So at Netgen, we started to delve deep to master this.
To be more practical I’ll give you few examples:
- One of the good things that is available within version 5 is the HTTP cache that comes with Symfony. In combination with ESI blocks and some reverse proxy you can get significantly better performance but for that you need to at least implement pagelayout templates in twig. The ezdemo bundle has some examples on how to this and some Symfony knowhow is very useful to get it right.
- The other good thing is Symfony and much more features that are now more easier to plug in into an eZ project. For example in one project I needed to integrate with an external system via its API. Luckily for me, there was already a Symfony bundle with a service encapsulating all features I needed. So it was just a matter of using the Composer, injecting the service in my class and start using it. Ain’t that lovely?
- The hybrid approach kicks in especially if you have lots of legacy code, either in the project itself or in extensions you use. Given a very solid fallback mechanism it will all work so you don’t need to rewrite everything. You can just use legacy modules or templates as is. But guess what, there is more to it. With our extension github.com/netgen/ngsymfonytools built by Edi you can now also call new templates or controller actions (subrequests) from old templates which might be very useful in case when you are adding new features but you just don’t want to do it in legacy.
- Even better example of hybrid development is to create a service in the new stack with the Symfony service container which consumes the new Public API and all other sweets like unit testing or Behat, but actually call it from legacy extensions :) Crazy, I know, but it works. The point is to use all good traits of version 5 and Symfony but without rewriting much of the old stuff. E.g. in your module you could do this:
$container = ezpKernel::instance()->getServiceContainer(); $service = $container->get( 'your_symfony_or_ez5_service );
With this approach you could make the transition period less painful. You could develop new features with the new technology but with less refactoring of old code. To do it efficiently you need to know both stacks very well.
Time of hybrids has come :)