RFC: Flow Framework - Foundation for complex applications?

Hi all,

I wanted to address that earlier, but I did not yet have the time to do so…

When I bought the last t3n I stumbled about a short article considering the “roadmap” of Neos and Flow.
In this article called “Neustart für Neos” @christianm states that Flow was primarily developed for the purpose of beeing the foundation for Neos, and explicitly not as an independent Framework for developing PHP-Applications.

This is really bothering me since then I have to admit. Me and my partner @saR are currently in the progress of developing a trimmed open-source alternative for tools like mailchimp and campaign monitor. And since Flow always has been advertised as an extremely flexible, secure and easy-to-use Framework for developing scalable enterprise-grade applications, that article really made us think, if we chose the “wrong” tool for what we have in mind.

Of Course, going with (the) flow seemed pretty reasonable, because a lot of paradigms we read about where default features of the Flow Framework and no one can take away the knowledge we gained about DDD, MVC and AOP.

Nevertheless, what I really want to know is:

Should we stick with flow or switch to something like Yii or Laravel?
Since we do have an MVC-based Application here, it wouldn’t be a big problem to switch the framework, since we can move the Domain-Model, Controller, Services and Views in a pretty “straight-forward” way.

If we stick with Flow, should we consider another Framework for our next Projects?
As I learned yesterday it really is a blast working with Flow and Neos Backend-Modules, but I’m pretty sure in a lot of scenarios we might not combine our Flow applications with a Neos site.
And if this tight integration is what the future for Flow brings, we really would like to know that for sure!

Best Regards and lots of love,

@chri____ and @saR

1 Like

Thank you for sharing your concerns, Christian!

It’s right, Flow was primarily developed as foundation for Neos and this is still our main focus.

But that doesn’t make it a bad choice for non-CMS solutions, quite the contrary:

Neos is one of the large applications Flow is built and kept up-to-date with. Neos gives us a lot of guidance as to what are important features for a (web) application. And as long as Neos is developed, Flow will too. At least.
Also, you never know whether your application might need some CMS functionality at some point - Flow allows you to use (parts of) Neos side-by-side, i.e. there are Flow apps using the TYPO3CR to store structured data (though that’s not the most stable of our packages, frankly).

Having said that Neos is the main focus, some of us (including me) mostly work on Flow projects and are keen on improving it further and further.

Just one general hint: When following simple examples don’t expect them to scale - in any framework. If a domain is complex per definition it needs special handling (e.g. Bounded Context, Job Queue, …) or you will most probably run into maintainability/performance issues.
That’s certainly nothing specific to Flow but with its magic it’s easy to end up with a big ball of mud :wink: