Hi folks,
I'm trying to conceptualize how I want to structure an app I'm building. I'm not asking where to put classes/models as I can read the docs for that. I just want to validate my sites structure as a whole based on my understanding of Fuel's features. What do you think?
Modules
* Home or Welcome module mapping to site.com/controller
* site.com/app module, possibly mapped to app.site.com used for static app template, asset loader, thick js client
* site.com/api/ module for API
controller inheritance
An auth controller extends controller (<-- can I still use the basic controller regardless of module? Do I just use Fuel\ namespace?)
template & rest controllers extends auth controller
app module controllers extend template controller
api controller extends rest controller
Why I think this is a good option.
* You get a site, app, and api all under the same roof with app and api sharing the same authorization
* As is the trend, the API becomes the real player. It's the super model, serving both front end clients and my "app" module. I can choose to render client side with JS or I can use HMVC to grab data from the API and serve it from the "app" module's controllers.
* I like that I would have the ability to check in the "API" module's controller whether or not the request is an HMVC request or from an outside client then I can RETURN data rather than output json.
OK, tell me what you think. The biggest argument I could see with this is it's over architecting. Perhaps just thicker models shared in the app and api modules is a better idea?
-Stephen @srhyne
Oh, and I'm thinking that unit testing would be easier this way. I can just create a test module, then test my API controllers pretty easily because the api RETURNS data to the test rather than just exiting to json.
Hi,
All I can say to this is I wouldn't do modules like you're suggesting. I'd group related logic in a module. I'd include your api throughout your modules (as your API is only really a controller that interacts with your models). Take for example this setup, you would have all of your logic in those modules and have RESTful controllers or XML RPC controllers that get input, but they'd be within those modules. They'd be grouped with the models they're using and that way your app will be more organised...
That's my two cents
Ben,
Thank you for the great answer. Wow, I never thought about doing it that way. I hold a module in too high a regard. I'm used to breaking up an application by action instead of the module. But I guess the grouping by related logic or high level feature is a better way of doing it vs grouping by "presentation". Plus authorizing users and user session behavior is probably easier to maintain when broken up like this.
So basically instead of /api/action/method it's module/api (as the action)/method or I could even use routes just point to the api contoller if the .format has changed?
Yep, that's how I would do it. In my example with those modules in that screenshot, I have http://www.example.com/music/artists_api/list.json but I could use the routes to re-route the controllers, it might seem nicer to do so. But for what it's worth, I think the best approach is to group logic.
Take for example Magento or Pyro CMS, they do the same sort of thing with grouping logic
Hope I've made myself useful lol
Donate
