Which is the good frontend and backend separation structures?

Contributors
,
1

Frontend and backend separation structures for zend-mvc and expressive.

Which structure do you recommend?

Solution A:

frontend
  +--- src  (CMD JS)
  +--- test
  +--- ...
  +--- webpack.config.js
  \--- package.json

api   (expressive | zend-mvc skeleton, no `public` dir)
  +--- config
  +--- data
  +--- src | modules
  +--- test 
  \--- composer.json

public
  +--- statics (frontend build target)
  +--- index.php
  \--- .htaccess

Solution B:

assets (Frontend codes and the dir name from sf4 skeleton. CMD JS)
  +--- foo.js
  \--- foo.spec.js
config
data
src | modules   (expressive | zend-mvc)
test 
composer.json
package.json
webpack.config.js
public
  +--- statics (frontend build target)
  +--- index.php
  \--- .htaccess

Solution C:

The idea from zend-mvc and apigility.

config
data
src | modules
  \--- FooUiModule  (Frontend codes)
    +--- assets   (CMD JS codes)
    +--- src
      \--- Module.php 
    +--- test
    +--- package.json
    \--- webpack.config.js
test 
composer.json
package.json
webpack.config.js
public
  +--- statics (frontend build target)
  +--- index.php
  \--- .htaccess

Or more recommend solutions?

Vote

  • Solution A
  • Solution B
  • Solution C
  • Other solutions

0 voters

2

I think that webpack pretty much removed the need for separate directory trees (Solution A) by allowing to have multiple entry-point scripts that automatically assemble whatever is relevant to them.

Solution C still seems to couple JS, PHP and frontend code: unless the PHP dev and the JS dev roles strictly overlap, this is most likely no longer relevant. I used to think it was (at the time, I was helping RWOverdijk with AssetManager), but it really does not matter that much. The idea was also to reuse as much module code as possible, but that rarely applies to private projects, and is only relevant to open source modules (which rarely ship assets anyway).

Solution B completely splits out everything JS, leaving the JS devs freedom as to where to put assets, sources, etc, and I think it is the most fitting one too. Effectively, the JS/design part of a website is kind-of a separate project per-se, so this leaves the people most involved in it being free to pick their own poison.

3 Likes
3

We use something close to solution B where server code and client code are kept relatively separated in their respective directory server and client.

bin/
client/
htdocs/
server/
angular.json
composer.json
composer.lock
package.json
yarn.lock

We also try to avoid the terms “backend” and “frontend” as they are sometime used to refer to admin/visitor pages (typically in TYPO3 ecosystem). Whereas “server” and “client” should be unambiguous in pretty much all contexts.

You can see an example of a real-life project on https://github.com/Ecodev/dilps. There are things that could be improved, but mostly it’s solution B.