Listen and Learn:
- How Zend was originally envisioned
- Zend Framework's competitors and what they're doing 'right'
- Predictions surrounding the introduction of Middleware
- Zend Framework's scalability and relationship with different environments
- Various release strategies over time
- How to take part in the community and become a contributor
Interested in learning more about open source frameworks options? Visit our stacks page for available apps and what's in the pipeline!
Stuart Langridge: These are the Bitnami Open Source Leaders Series of
Interviews. I'm Stuart Langridge, and
I'm talking to Matthew Weier O'Phinney, who is technical lead for the Zend
Framework Project. So, the obvious
question to start out with here is, who
is Zend, and what's the Zend
Framework?
M. Weier O'Phinney: Zend is Zend Technologies. It was founded by Zeev Suraski and Andi
Gutmans, two Israeli students at the Technion University. They were working on PHP because they were
trying to finish a project for school (for college actually) and they
discovered that they really enjoyed working on the language rather than the
project. They contributed what was called the Zend engine at the time, which is
still today if you look at PHP (say PHP Version) you're going to see the PHP
powered by Zend engine.
So, Zend is a combination of their two names. The Z-E from Zeev and N-D from Andi. Zend Technologies does a variety of tooling around the PHP language, so we have an IDE called Zend Studio. We have an application server called Zend Server, which provides things like monitoring, debugging, and it provides application insights/deployment. All sorts of features that you might look at.
In addition to that, we also are involved in a number of open source projects and sponsor a few, one of which is the PHP language itself. We have developers who work on the language pretty much full time, including Dmitry Stogov, who is very, very active on internals, and then Zend Framework and Apigility, which I work on and lead.
And these are open source projects, Zend Framework is an open source PHP MVC stack, or at least that's how it was originally envisioned. It provides a whole bunch of different components that can be used separately, but also when used together form a complete MVC stack you can use to build applications, particularly Web applications and APIs.
Apigility is another project that actually builds on top of Zend Framework Version 2 and provides open API engine and a builder for you, so you can go in to describe your API and provides the configuration and code that you need in order to run it using Zend Framework 2.
So, Zend is a combination of their two names. The Z-E from Zeev and N-D from Andi. Zend Technologies does a variety of tooling around the PHP language, so we have an IDE called Zend Studio. We have an application server called Zend Server, which provides things like monitoring, debugging, and it provides application insights/deployment. All sorts of features that you might look at.
In addition to that, we also are involved in a number of open source projects and sponsor a few, one of which is the PHP language itself. We have developers who work on the language pretty much full time, including Dmitry Stogov, who is very, very active on internals, and then Zend Framework and Apigility, which I work on and lead.
And these are open source projects, Zend Framework is an open source PHP MVC stack, or at least that's how it was originally envisioned. It provides a whole bunch of different components that can be used separately, but also when used together form a complete MVC stack you can use to build applications, particularly Web applications and APIs.
Apigility is another project that actually builds on top of Zend Framework Version 2 and provides open API engine and a builder for you, so you can go in to describe your API and provides the configuration and code that you need in order to run it using Zend Framework 2.
Stuart Langridge: That makes perfect sense. Who are the sorts of people who are
currently using Zend Framework? Is it
aimed at a particular kind of organization or a particular kind of Web
application or site? Or is it very, very
generalized?
M. Weier O'Phinney: We’ve always thought of this as a general
purpose Web application framework, and so it fits the entire gamut of applications
that you can envision on the Web, whether that's viewing a single Web page,
doing a complex shop, such as Magento (Magento was built on Zend Framework 1
largely) to content management systems and APIs.
That said, what we've found, especially when we were going from Zend Framework 1 to 2 was that we had a lot of inroads particularly into enterprises and large content companies. If you think of media companies such as Disney and Fox and NBC, a lot of them are using Zend Framework within their applications.
What we ended up targeting primarily were these enterprise applications. We have a lot of enterprise-y sorts of bits and pieces in the framework that suit those very large-scale needs that you have, as well as the large complexity that you might have to manage within your application.
That said, what we've found, especially when we were going from Zend Framework 1 to 2 was that we had a lot of inroads particularly into enterprises and large content companies. If you think of media companies such as Disney and Fox and NBC, a lot of them are using Zend Framework within their applications.
What we ended up targeting primarily were these enterprise applications. We have a lot of enterprise-y sorts of bits and pieces in the framework that suit those very large-scale needs that you have, as well as the large complexity that you might have to manage within your application.
Stuart Langridge: You mentioned there that the framework is deliberately built
as a set of reusable separated components.
There's been a lot of work recently in the PHP world to push everyone
towards working in that kind of way, building components which work across
multiple different framework, share standard interfaces, that sort of
thing. Is that the sort of thing that
Zend Framework is working on?
M. Weier O'Phinney: Yes.
Actually it's kind of a funny thing. The Zend Framework, we started it almost ten
years ago, and it was actually very components-first with the framework sitting
on top of it, and over the years morphed to more of a framework first that
happens to have a bunch of components.
We're actually changing that story actively right now. One of the features that you talk about with moving towards components, we have a very nice feature in the PHP language that is built by people using PHP called Composer. This allows you to go and patch in the libraries you need and the dependencies you need in order to build your application.
What we've seen in the last two to three years since Composer was introduced is that everybody started building their applications this way, which means that they can kind of go and choose exactly the bits and pieces that they like. Then they can code directly to those. Now instead of using the full-stack framework because it has most of what you need, they can go and cherry-pick exactly where needed.
What we have decided to do going into Zend Framework 3 moving forward and something we're doing this year is we're going to be separating our components out of the main framework repository and they're going to live in their own repositories. They will have their own life cycles and everything. We're retaining the history as part of that, which is rather challenging.
But, we're actually going to have all of their own versioning and history so that people can evaluate the individual components just for them and not think of it in terms of this monolithic framework that people have been primarily thinking of when they think of Zend Framework.
So, we are actively working towards that. Part of it also is looking at different ways that we can deliver what you consider an MVC. When we look at traditional frameworks like Zend Frameworks and Symfony, when you look at the MVC it basically is this big glue that brings in everything, from your pagination to all the little bits and pieces that you might want to have in there.
The problem is that, quite often you don't actually want all of that, especially if you know exactly your needs. You might only need a subset of that portion. So, one of the things we're looking at is targeting Middleware, with that we have a very slim runtime that we can be looking at, and so it's really I get a request and response and I do something with that and return the response when I'm done.
That’s what we're going to be looking at as an alternative runtime so that you don't necessarily have to consume the enterprising MVC we have currently if it doesn't suit your needs. At the same time we're going to make it so that the MVC can consume that same Middleware and also be processed as Middleware, so it can start composing things in different ways. That’s what we really see as a future. It’s having this idea of individual components that work really, really well and do one specific thing, so you go and glue them together in a way that you can then deliver your application on time and with quality.
We're actually changing that story actively right now. One of the features that you talk about with moving towards components, we have a very nice feature in the PHP language that is built by people using PHP called Composer. This allows you to go and patch in the libraries you need and the dependencies you need in order to build your application.
What we've seen in the last two to three years since Composer was introduced is that everybody started building their applications this way, which means that they can kind of go and choose exactly the bits and pieces that they like. Then they can code directly to those. Now instead of using the full-stack framework because it has most of what you need, they can go and cherry-pick exactly where needed.
What we have decided to do going into Zend Framework 3 moving forward and something we're doing this year is we're going to be separating our components out of the main framework repository and they're going to live in their own repositories. They will have their own life cycles and everything. We're retaining the history as part of that, which is rather challenging.
But, we're actually going to have all of their own versioning and history so that people can evaluate the individual components just for them and not think of it in terms of this monolithic framework that people have been primarily thinking of when they think of Zend Framework.
So, we are actively working towards that. Part of it also is looking at different ways that we can deliver what you consider an MVC. When we look at traditional frameworks like Zend Frameworks and Symfony, when you look at the MVC it basically is this big glue that brings in everything, from your pagination to all the little bits and pieces that you might want to have in there.
The problem is that, quite often you don't actually want all of that, especially if you know exactly your needs. You might only need a subset of that portion. So, one of the things we're looking at is targeting Middleware, with that we have a very slim runtime that we can be looking at, and so it's really I get a request and response and I do something with that and return the response when I'm done.
That’s what we're going to be looking at as an alternative runtime so that you don't necessarily have to consume the enterprising MVC we have currently if it doesn't suit your needs. At the same time we're going to make it so that the MVC can consume that same Middleware and also be processed as Middleware, so it can start composing things in different ways. That’s what we really see as a future. It’s having this idea of individual components that work really, really well and do one specific thing, so you go and glue them together in a way that you can then deliver your application on time and with quality.
Stuart Langridge: That's actually going to be a really great thing for PHP
developers everywhere, when things like EABS
and framework as an example instead of being, as you say, the monolithic
framework, you build the components and then Zend Framework itself is just a particular
arrangement of those components.
M. Weier O'Phinney: Exactly.
Stuart Langridge: So, I can switch in different things, and it means that you
can share a lot more code without the frameworks (well, you're not all
re-implementing a whole bunch of fairly standard stuff the same way just to fit
in your own framework) so you can get on with doing things that really
differentiate you or you feel you can do better.
M. Weier O'Phinney: Right. The
other part is that we're seeing implication between the different
frameworks. For instance, if I want to
go and build an authentication scheme that includes a login form and that sort
of thing. There's a solution in Zend Framework called Zend SC User. There's a similar solution in Laravel. There's a similar solution in Symfony.
The fact of the matter is, under the hood they're doing the exact same thing, and the only reason that they have to be separate is because they need to work within that MVC. This is where the Middleware part comes and it's an important bit. We talked about the interoperability of components. One of the things I've been working on personally is with the Framework Interoperability Group, we call ourselves FIG, or PHP FIG is the name of it.
I've been working on that with a proposal called PSR-7, PHP Standards Recommendation #7. It is for http methods interfaces, and it's giving an abstraction around http requests and responses. The end goal of this is that people will start writing to those interfaces and be writing these reusable Web widgets that they can then drop into any one of the frameworks. They do not have to worry about everything else. They’re just worrying about whether they're self-contained and they can handle the request to do something with it and spit something back out.
Then, you can go and compose that into any given framework as needed. That’s the real goal for me is if we can get to a point where our components can be decoupled, not just at the individual layer (like a database or pagination or caching or something like that) but also at the Web widget interface.
That means that we can share the stuff throughout the community much better and hopefully end some of this duplication that's been happening.
The fact of the matter is, under the hood they're doing the exact same thing, and the only reason that they have to be separate is because they need to work within that MVC. This is where the Middleware part comes and it's an important bit. We talked about the interoperability of components. One of the things I've been working on personally is with the Framework Interoperability Group, we call ourselves FIG, or PHP FIG is the name of it.
I've been working on that with a proposal called PSR-7, PHP Standards Recommendation #7. It is for http methods interfaces, and it's giving an abstraction around http requests and responses. The end goal of this is that people will start writing to those interfaces and be writing these reusable Web widgets that they can then drop into any one of the frameworks. They do not have to worry about everything else. They’re just worrying about whether they're self-contained and they can handle the request to do something with it and spit something back out.
Then, you can go and compose that into any given framework as needed. That’s the real goal for me is if we can get to a point where our components can be decoupled, not just at the individual layer (like a database or pagination or caching or something like that) but also at the Web widget interface.
That means that we can share the stuff throughout the community much better and hopefully end some of this duplication that's been happening.
Stuart Langridge: Yeah, absolutely. You'd
be able to say, "I want Facebook
authentication," and just go and get the Facebook authplugin rather
than the one for your particular framework, so you're not – if you shift from
Symfony to Zend or from Zend to Laravel or whatever, then you're still using a
whole bunch of the similar components, you're just switching out the parts that
you need, which would be fantastic.
We’re talking about Zend in the context of other frameworks in there, without wishing to do your competition down or anything, what do you see Zend Framework as providing that the competition do not? Where do you think you're stronger?
We’re talking about Zend in the context of other frameworks in there, without wishing to do your competition down or anything, what do you see Zend Framework as providing that the competition do not? Where do you think you're stronger?
M. Weier O'Phinney: Like I said earlier, we focused very much on
the enterprise layer when we went to Zend Framework 2, and I think we did an
excellent job. We have a very nice
decoupled mechanism with both our service manager and our event manager that
make it really, really flexible in
ways that I've not been able to see in any of the other frameworks.
You can kind of get to it with Symfony. They have similar capabilities, but what I'm seeing is that it's much easier to introduce the flexibility within your applications especially if you have a lot of complex needs. So, that's great. Unfortunately, that means that it comes at a bit of an impact to performance and usability, and I like to think of frameworks as trying to balance performance usability and flexibility. Typically you get one of them really wrong and then you suffer.
That’s what we've seen in Framework 2 is flexibility, but we suffer a bit in performance and usability. I would say Symfony does a very nice job of usability. They've actually been spending a whole lot of time on that in the past year. They have what they call their “DX Initiative”, which is developer experience. They’ve been doing a lot with that.
But, it means that they're not quite as flexible, and it means that they're not quite as performing. It's the same thing with Laravel. They have been really focused on the initial experience with going in there and making it really easy for you to get up and running, but again, it's at the expense of flexibility and performance in this case.
You have others, like Slim, that are very performanant, very easy, but you need to go into something complex, and all of a sudden you've got growing pains as it doesn't give you a whole lot of guidelines about how to do a complex application architecture. It gives you a lot of guidelines about how to do something streamlined.
Those are the sorts of tradeoffs that you look at. So, I would say Zend Framework excels at the flexibility side, and that's what I'd say we really, really focused on for Zend Framework 2. We succeeded at that, but now we really need to focus on those other two aspects, and that's what we're looking at for Zend Framework 3, particularly with the Middleware solutions.
You can kind of get to it with Symfony. They have similar capabilities, but what I'm seeing is that it's much easier to introduce the flexibility within your applications especially if you have a lot of complex needs. So, that's great. Unfortunately, that means that it comes at a bit of an impact to performance and usability, and I like to think of frameworks as trying to balance performance usability and flexibility. Typically you get one of them really wrong and then you suffer.
That’s what we've seen in Framework 2 is flexibility, but we suffer a bit in performance and usability. I would say Symfony does a very nice job of usability. They've actually been spending a whole lot of time on that in the past year. They have what they call their “DX Initiative”, which is developer experience. They’ve been doing a lot with that.
But, it means that they're not quite as flexible, and it means that they're not quite as performing. It's the same thing with Laravel. They have been really focused on the initial experience with going in there and making it really easy for you to get up and running, but again, it's at the expense of flexibility and performance in this case.
You have others, like Slim, that are very performanant, very easy, but you need to go into something complex, and all of a sudden you've got growing pains as it doesn't give you a whole lot of guidelines about how to do a complex application architecture. It gives you a lot of guidelines about how to do something streamlined.
Those are the sorts of tradeoffs that you look at. So, I would say Zend Framework excels at the flexibility side, and that's what I'd say we really, really focused on for Zend Framework 2. We succeeded at that, but now we really need to focus on those other two aspects, and that's what we're looking at for Zend Framework 3, particularly with the Middleware solutions.
Stuart Langridge: That's exactly what I was about to ask. You've now got not only what Zend Framework 2
does but also who's using it and how
they're using it. What changes are you
making for Zend Framework 3 from a conceptual point of view? You're adding the Middleware stuff, and
there's a lot of work to componentize everything and corporate with other
frameworks. What do you see as being the big changes in Zend Framework 3?
M. Weier O'Phinney: The introduction of Middleware is going to be,
I think, the bigger change. Components-
we've actually been able to ship the components separately for quite some time-
it's just been in a semi-manual, semi-automated fashion as we tag. We go in to
update the various component repositories and everything gets taken care of.
But, it means that they're never up-to-date. You always have to go back to the main repository for that to work. So, the component change is going to be nice, but it's not a huge thing. The Middleware introduction is going to be a huge one because it gives us those two different aspects of performance and the usability.
Middleware is a really simple pattern to explain, and I can go up and actually show a single function signature, and people can understand how that works. Then I can start drawing on that and showing how you layer it or how you might run it in the stack, that sort of thing, and people can grasp it very easily.
That gives us a really nice thing in terms of usability because it becomes very much simpler to build some sort of framework, especially for those smaller applications that might not be as complex. It also gives us a little bit of added flexibility in terms of building workflows.
One of the things with Apigility we discovered is that we had to go and map out what exactly we were doing. We knew that we were doing invalidation, we knew that we were doing content negotiation, authentication, authorization, routing and all these different pieces, and I actually went through and figured out where in our event system the various priorities and figured it out, and I was able to create a flowchart.
And when I created the flowchart it was a very linear process. I knew exactly what needed to be done, so we went and created a prototype of Apigility in Node just to see if we could do it. In order to do this, we started using a lot of nodisms, and one of those is Middleware is very prevalent on that paradigm.
What it ended up being was simply a literal list of all these different Middlewares, which meant that if somebody wanted to, say, swap out the authentication layer, all they had to do was write their own authentication Middleware and replace that line in the application workflow, that was it, and it's very simple.
So, we get some flexibility like that that it's present in the Zend Framework 2 and we see, but it's harder to understand and harder to figure out where it fits. I'm excited about that in terms of usability and flexibility.
The other part though is performance. There are some things that we can do with Middleware to optimize for performance that we simply cannot do easily with Zend Framework 2. We do a lot of it already in terms of lazy loading services only if we know that they have been requested, but we can do that at a much more granular level and much earlier Middleware solution than we can with Zend Framework 2.
So, that's the other part that I'm looking at is the performance aspects. So, Middleware I think is the really big story about Zend Framework 3. It's a part that I'm really excited about because I think it's going to change the paradigm, both in terms of reuse across frameworks as well as how we start structuring our applications and thinking of them as more of an application workflow, “How do I transform this request into a response”?
But, it means that they're never up-to-date. You always have to go back to the main repository for that to work. So, the component change is going to be nice, but it's not a huge thing. The Middleware introduction is going to be a huge one because it gives us those two different aspects of performance and the usability.
Middleware is a really simple pattern to explain, and I can go up and actually show a single function signature, and people can understand how that works. Then I can start drawing on that and showing how you layer it or how you might run it in the stack, that sort of thing, and people can grasp it very easily.
That gives us a really nice thing in terms of usability because it becomes very much simpler to build some sort of framework, especially for those smaller applications that might not be as complex. It also gives us a little bit of added flexibility in terms of building workflows.
One of the things with Apigility we discovered is that we had to go and map out what exactly we were doing. We knew that we were doing invalidation, we knew that we were doing content negotiation, authentication, authorization, routing and all these different pieces, and I actually went through and figured out where in our event system the various priorities and figured it out, and I was able to create a flowchart.
And when I created the flowchart it was a very linear process. I knew exactly what needed to be done, so we went and created a prototype of Apigility in Node just to see if we could do it. In order to do this, we started using a lot of nodisms, and one of those is Middleware is very prevalent on that paradigm.
What it ended up being was simply a literal list of all these different Middlewares, which meant that if somebody wanted to, say, swap out the authentication layer, all they had to do was write their own authentication Middleware and replace that line in the application workflow, that was it, and it's very simple.
So, we get some flexibility like that that it's present in the Zend Framework 2 and we see, but it's harder to understand and harder to figure out where it fits. I'm excited about that in terms of usability and flexibility.
The other part though is performance. There are some things that we can do with Middleware to optimize for performance that we simply cannot do easily with Zend Framework 2. We do a lot of it already in terms of lazy loading services only if we know that they have been requested, but we can do that at a much more granular level and much earlier Middleware solution than we can with Zend Framework 2.
So, that's the other part that I'm looking at is the performance aspects. So, Middleware I think is the really big story about Zend Framework 3. It's a part that I'm really excited about because I think it's going to change the paradigm, both in terms of reuse across frameworks as well as how we start structuring our applications and thinking of them as more of an application workflow, “How do I transform this request into a response”?
Stuart Langridge: We’re going to see a lot more people who are using it start
implementing a lot more of their stuff as Middleware functions. This builds a function which sits in your
request pipeline
M. Weier O'Phinney: Right.
Stuart Langridge: That handles almost everything apart from the actual core
purpose of whatever your Web app is. All
the ancillary stuff or the authentication and headers and checking can all
happen with Middleware.
M. Weier O'Phinney: Exactly.
This I think is going to be a very big thing. The other part is that we're not getting rid
of the current MVC because we recognize that there are those use cases. You even noted a few minutes ago that we came
into Zend Framework 2 with a very discrete idea of who the user base was and
what they wanted. We built towards that.
We're saying that's still perfectly valid, and we still see these people using it. They have very good reasons to be using it so we don't want to make that go away either. That’s one of the aspects with the Middleware solution. We can actually balance both of those and keep them both maintained and going forward.
We're saying that's still perfectly valid, and we still see these people using it. They have very good reasons to be using it so we don't want to make that go away either. That’s one of the aspects with the Middleware solution. We can actually balance both of those and keep them both maintained and going forward.
Stuart Langridge: Talk a bit about scaling here. Obviously, one of the things
that has come about in recent years is the rise of the Cloud, so instead of
having one enormous, epic server that you just throw RAM at, you've now got
lots and lots of individual Cloud instances that you can spin up and spin down
as load requires. How does Zend
Framework fit into that kind of environment?
Or is that something that you see happening outside your framework of
being done on the Apache and http level?
M. Weier O'Phinney: So, Zend Framework works great in this
situation. I have deployed many times to
a variety of different clouds without any problems, and it's because PHP works
very well in the Cloud. PHP was really built
with the idea of horizontal scaling because it has a shared-nothing
architecture.
If you need any sort of persistence, you have the somewhere else and you communicate to it which means that it fits very well in this particular case of, “I want to go and put it in the Cloud” and, “Oh, wow, we're going to get a whole bunch of traffic” Then, press a button and load up a bunch of instances. They’re all intercepting traffic and then only bottleneck at that point is your persistence engine.
That part is never going to be something that the framework directly addresses. There are tools to help address it, like caching layers, but it's an application architecture aspect. You're going to have to go in and say, "Hey, you know what? We're expecting a million hits this week, so we'd better make sure that have something like Memcached or Redis sitting in the database so that we can reduce the number of calls to it with something that's much faster."
So, that's really the crowd story. Now one of the cool parts (like I said earlier, I work for Zend) is Zend's server actually makes it really easy to deploy. I can go and create a package and shove it out there to deploy. If I have Zend's server on the various instances on my cloud, then I can fire up a new server and it's going to deploy the package automatically.
That's one thing that Zend has thought about quite a lot, and so we actually have partnerships with a lot of the major cloud providers: AWS, I'm trying to remember all – I can't remember if Digital Ocean is one of them. IBM – I can't remember all the names.
If you need any sort of persistence, you have the somewhere else and you communicate to it which means that it fits very well in this particular case of, “I want to go and put it in the Cloud” and, “Oh, wow, we're going to get a whole bunch of traffic” Then, press a button and load up a bunch of instances. They’re all intercepting traffic and then only bottleneck at that point is your persistence engine.
That part is never going to be something that the framework directly addresses. There are tools to help address it, like caching layers, but it's an application architecture aspect. You're going to have to go in and say, "Hey, you know what? We're expecting a million hits this week, so we'd better make sure that have something like Memcached or Redis sitting in the database so that we can reduce the number of calls to it with something that's much faster."
So, that's really the crowd story. Now one of the cool parts (like I said earlier, I work for Zend) is Zend's server actually makes it really easy to deploy. I can go and create a package and shove it out there to deploy. If I have Zend's server on the various instances on my cloud, then I can fire up a new server and it's going to deploy the package automatically.
That's one thing that Zend has thought about quite a lot, and so we actually have partnerships with a lot of the major cloud providers: AWS, I'm trying to remember all – I can't remember if Digital Ocean is one of them. IBM – I can't remember all the names.
Stuart Langridge: There's an awful lot of them.
M. Weier O'Phinney: I know for a fact that we're on seven or eight
different cloud platforms, so as a result, if you can deploy to Zend's server
and you want to go onto the Cloud you can probably find cloud platforms that
meet your needs and go in and do it. That's one thing that you can do.
But, the fact of the matter is that you can deploy to any cloud platform because it's PHP, and PHP is ubiquitous, and it's something that we thought about for scaling in terms of decades at this point.
But, the fact of the matter is that you can deploy to any cloud platform because it's PHP, and PHP is ubiquitous, and it's something that we thought about for scaling in terms of decades at this point.
Stuart Langridge: And this is exactly the sort of thing that Bitnami is good at.
We talked a bit about Zend Framework 3 and it coming along and what it's going
to bring. Do you anticipate running the
existing version and Zend 3 in parallel?
Are you expecting people to gradually migrate over to Zend Framework 3,
or do you think that 2 and 3 will run as parallel products for quite a while?
M. Weier O'Phinney: So, we're preparing Zend Framework 2.4 right
now, which we're going to mark as a long-term support release. We may or may not do a 2.5 after we separated
out the packages, but the one that we'll be supporting long-term is 2.4. What that means is for security fixes and
critical fixes is that we will continue doing that for, I think, two years or
three years.
Now, that said, like I said earlier, the base MVC layer is basically going to stay the same. There's going to be a few backwards compatibility changes with 3, but for the most part the architecture is the same. We're just going to have this additional aspect of Middleware sitting in front, or rather, to the side and running in parallel.
The nice part is that the Middleware also gives us a migration path because one of the aspects we're going to do is ship a modified version of the Zend Framework 2 skeleton that wraps it in Middleware. Meaning that you can say, "Hey, for all the paths that match, these particular paths, delegate to this particular Middleware (which runs on Framework 2)…and for this other stuff we'll start using this new Middleware, where it's Slim Middleware or whatever the case may be.”
Now, that said, like I said earlier, the base MVC layer is basically going to stay the same. There's going to be a few backwards compatibility changes with 3, but for the most part the architecture is the same. We're just going to have this additional aspect of Middleware sitting in front, or rather, to the side and running in parallel.
The nice part is that the Middleware also gives us a migration path because one of the aspects we're going to do is ship a modified version of the Zend Framework 2 skeleton that wraps it in Middleware. Meaning that you can say, "Hey, for all the paths that match, these particular paths, delegate to this particular Middleware (which runs on Framework 2)…and for this other stuff we'll start using this new Middleware, where it's Slim Middleware or whatever the case may be.”
So, we will have a migration path. I want to get a wrapper like this around Zend Framework 1 as well because that will give us a migration path between 1 and 2 and 3 essentially, and do it in a clean way that we weren't able to accomplish before.
Stuart Langridge: So, you're building an environment, which is sort of midway in
between the two. Say, you make a move. If
you're building on Zend Framework 2 at the moment or even 1, it brings you into
position where you're using a lot of Zend Framework 3 or a lot of generalized
Middleware component stuff, but you're still working with a Zend 2 core.
M. Weier O'Phinney: Exactly.
Stuart Langridge: What is your release strategy, release cadence and so on? Are you time-based releases or feature-based or
just when it's ready?
M. Weier O'Phinney: We used to be time-based. The problem is that
my team has been spread out between Zend Framework and Apigility for the past
year and a half, so it's been harder for us to adhere to a time-based one. It’s
been more of a ‘as the features are ready’ sort of thing.
At a certain point usually what happens is that we get to a point where we haven't had a release for a while and we really need to do one. That’s kind of what's happened recently. We’ve gotten to a point where we really need to have the 2.4 release so that we can move forward with 3.
We have a release plan going right now and in two weeks I'm going to be feature-freezing the development branch, and we're going to do our first beta. Usually our betas are pretty quick because people are always testing against our develop branch, so we catch backwards compatibility breaks, et cetera, pretty early. We can usually do our minor releases even within a two to three week timeline.
We're also doing an Apigility release and we want to pin that to the 2.4 release of Zend Framework, so we want to make sure it's stable and that before we add to it. The features for that are already going. We have said that late quarter three, early quarter four is what we're targeting for Zend Framework 3, so we do have a time-based release on this.
I'm going to be working on a detailed plan once we get 2.4 out of the way, so that we can figure out exactly what needs to happen. But, we already know the high-level details of what's going to happen. It's going to mainly be a matter of figuring out what the actual technical details of how to make it happen and figuring out how long it will take.
At a certain point usually what happens is that we get to a point where we haven't had a release for a while and we really need to do one. That’s kind of what's happened recently. We’ve gotten to a point where we really need to have the 2.4 release so that we can move forward with 3.
We have a release plan going right now and in two weeks I'm going to be feature-freezing the development branch, and we're going to do our first beta. Usually our betas are pretty quick because people are always testing against our develop branch, so we catch backwards compatibility breaks, et cetera, pretty early. We can usually do our minor releases even within a two to three week timeline.
We're also doing an Apigility release and we want to pin that to the 2.4 release of Zend Framework, so we want to make sure it's stable and that before we add to it. The features for that are already going. We have said that late quarter three, early quarter four is what we're targeting for Zend Framework 3, so we do have a time-based release on this.
I'm going to be working on a detailed plan once we get 2.4 out of the way, so that we can figure out exactly what needs to happen. But, we already know the high-level details of what's going to happen. It's going to mainly be a matter of figuring out what the actual technical details of how to make it happen and figuring out how long it will take.
Stuart Langridge: Let's talk a bit about the user and developer
communities. If I'm using Zend Framework
to build things, obviously, I'll participate in the community to get technical
support, ask questions and so on. But,
what benefits do I get from participating in the community in a more detailed fashion? What else is there that I can do, should do
that you'd like to see people doing?
M. Weier O'Phinney: We have a few semi-official channels that we
utilize. We have a mailing list, both
for users and those developing on the framework itself. FW General is the user's list where you ask
questions, Zend F Contributors is for people who are working on the development
on the framework itself.
We have mirror images of those in IRC, so on Free Node we have #ZendFTalk for the users and #ZendFTalk.dev for those that are contributing patches and bug-fixes. We can do a lot by asking in there, and one of the things I've seen is there's actually been a lot of comradery between people who are answering questions who've been there for a long period of time.
The part that I'm not seeing a whole lot of- I'm guilty of this as well- is, I haven't been seeing a whole lot of people blogging about Zend Framework 2 and what they're doing with it. The fact of the matter is I know a whole lot of people are using it because I see the download stats.
We have a lot of people using it, but they're not necessarily sharing what they're doing and the knowledge that they're getting from working with it. We have some excellent examples of people who are doing this. Rob Allen has been blogging about Zend Framework basically since its inception and has been part of our community review team for quite some time.
Matthew Setter, also based in England, has been doing a whole bunch of stuff on Zend Framework 2 specifically, which has been really cool to see, but there aren't a whole lot of names popping up in terms of people saying, "I'm doing Zend Framework." That’s the sort of thing where I can see a lot more participation in the community.
What are you doing? What are you building? And share that with people because people are often coming with the same questions over and over. If they can just share those details it helps everybody out.
Another thing that we're starting to see are Zend Framework specific user groups. I know Symfony and a few other frameworks have their own specific user groups, but we're starting to see those spring up. There's one in Paris now, one in the San Francisco Bay Area, and I think I saw another one in the Cologne area of Germany.
We are seeing those springing-up and we want to support them. For instance, I'm going to be at the one in San Francisco next week, and we had Zend present at the first one in Paris last fall. I want to see people participate in sharing their experience and help to figure out what the pros and cons of using Zend Framework are and how can it be made better?
And the only way we can get that information (as to how do we build it better) is from people that share their experiences so we can see what are the common problems that they're encountering.
We have mirror images of those in IRC, so on Free Node we have #ZendFTalk for the users and #ZendFTalk.dev for those that are contributing patches and bug-fixes. We can do a lot by asking in there, and one of the things I've seen is there's actually been a lot of comradery between people who are answering questions who've been there for a long period of time.
The part that I'm not seeing a whole lot of- I'm guilty of this as well- is, I haven't been seeing a whole lot of people blogging about Zend Framework 2 and what they're doing with it. The fact of the matter is I know a whole lot of people are using it because I see the download stats.
We have a lot of people using it, but they're not necessarily sharing what they're doing and the knowledge that they're getting from working with it. We have some excellent examples of people who are doing this. Rob Allen has been blogging about Zend Framework basically since its inception and has been part of our community review team for quite some time.
Matthew Setter, also based in England, has been doing a whole bunch of stuff on Zend Framework 2 specifically, which has been really cool to see, but there aren't a whole lot of names popping up in terms of people saying, "I'm doing Zend Framework." That’s the sort of thing where I can see a lot more participation in the community.
What are you doing? What are you building? And share that with people because people are often coming with the same questions over and over. If they can just share those details it helps everybody out.
Another thing that we're starting to see are Zend Framework specific user groups. I know Symfony and a few other frameworks have their own specific user groups, but we're starting to see those spring up. There's one in Paris now, one in the San Francisco Bay Area, and I think I saw another one in the Cologne area of Germany.
We are seeing those springing-up and we want to support them. For instance, I'm going to be at the one in San Francisco next week, and we had Zend present at the first one in Paris last fall. I want to see people participate in sharing their experience and help to figure out what the pros and cons of using Zend Framework are and how can it be made better?
And the only way we can get that information (as to how do we build it better) is from people that share their experiences so we can see what are the common problems that they're encountering.
Stuart Langridge: That's totally part of it.
It's incredibly useful for me or someone like me as a user or someone
building something with Zend
Framework to get an example of other people that have done something similar,
see how they did it, the challenges they run into.
But, it's also really useful for you to get a sense of what I'm doing with it in order to make sure that it meshes with what you think I'm doing with it. One of the things I'd love to see is people who are building projects (using something like Zend Framework) to contribute back their project and its test suite –
But, it's also really useful for you to get a sense of what I'm doing with it in order to make sure that it meshes with what you think I'm doing with it. One of the things I'd love to see is people who are building projects (using something like Zend Framework) to contribute back their project and its test suite –
M. Weier O'Phinney: Exactly.
Stuart Langridge: – back to you. I mean,
do you – I don't know how much there is in the way of people building open
source projects on top of Zend Framework, but there's potentially a big use of
pulling them in just so you can run their test suites and check their new
versions.
M. Weier O'Phinney: Exactly. And that's one of the pieces that we see a whole lot
more private applications being helped.
Not a whole lot of public ones.
That's one of the things that I've struggled with is how can we get
people building on top of it, and I'm really hoping with Zend Framework 3 that
making it easier, making it particularly easy to bring in whatever components
you want from anywhere. I think we're
going to see more of that and hopefully we'll get more people then, a bigger
user base who's more communicative about what they're doing and then we can
start testing our changes against what they're doing, which I think will
benefit everybody.
Stuart Langridge: So, if someone wants to find out more about Zend, about Zend
Framework, about Apigility where
should they go?
M. Weier O'Phinney: To find out more about Zend, www.zend.com. For Zend Framework it’s
framework.zend.com. Apigility is apigility.org.
Stuart Langridge: Excellent. So, thank
you very much for talking to us, Matthew Weier O'Phinney of Zend Technologies.
[Music plays]
[End of Audio]