CODEWITHSUNDEEP
symfony
Snoop9
Snoop9

Reputation: 23

Symfony2 : implement multiple projects sharing same logics

I've read a lot on this topic, but cannot find out a clear answer on how to structure a complex project around symfony2...

My new project will be structured with : 1) one back office website hosted on a subdomain of our partner's website 2) one partner's website 3) one (or more) customer's website

Of course, each of these websites will share logics from "core" bundles (i.e : core entities, core user logic, etc...), but they also need to have custom routing, custom templates, and so on...

I think that I have 2 options :

1) define 1 bundle per website and define routing based on the hostname, but it seems that it is not recommended

2) implement one SF2 instance by website, and copy/deploy core bundles into each instances

What is the best solution ? And is there another solution on how to implement some kind of complex project?

Upvotes: 1

Views: 287

Answers (1)

ChrisC
ChrisC

Reputation: 2469

It's difficult to say which is best for your particular situation: I've used both approaches for projects. I actually have one project which uses both approaches simultaneously, consisting of two Symfony applications: One generating the main website, the other generating a separate application containing some other functionality, with separate bundles for the "user" functionality and the "admin" functionality. We used Varnish to dispatch requests to the correct application, based on the URL path.

In my experience I've found that having multiple applications adds a degree of complexity to the overall solution. This makes it more complicated to work with and to hold the "big picture" of the whole system in your head. There's also potentially a cost implication, if you want to run your applications on separate servers. You also need to consider that there's overhead on getting the whole solution set up for local development, which is definitely a concern if you're in a team of more than one.

The flip-side of this is that working on one part of the whole solution (i.e. one app) is often more straightforward: Configuration values/dependencies for the other applications won't need to be set up, you only need to get working the bare minimum for that one standalone app. This approach also affords you a lot of flexibility and the ability to concentrate changes on one particular area of the solution. For example: If you wanted to make some changes to the partner's website, if that was generated by a completely separate application, it becomes straightforward to do this. You know that there won't be knock-on effects to your other applications. This goes for shared code too, providing you version it correctly: With composer, your separate applications can depend on different versions of your shared bundles/libraries if necessary. Another benefit of having separate applications is the ability to scale them independently of each other. If your customer website gets much more traffic than your partner's site, you can set it up on better hardware/virtualised instances, giving you finer grained control over performance/costs.

Sharing code is relatively straightforward with Composer and is not one of the main concerns here, in my opinion: Think carefully about the above factors when making your decision.

Upvotes: 1

Related Questions