Hi Paul, Yeah I am proposing one big component to house all services. The reason is that it makes no sense in separating them because they are tightly coupled and depend on each other heavily (because they share the full data model)
As I mentioned in my first email, we can perhaps create a new component and call it "service-library". Inside this component we follow a similar pattern to the datamodel component in organizing the files. To me the big win out of this move is that all the complexity we have right now in figuring out the dependencies between components almost completely goes away. Remember that big spaghetti diagram in the wiki for component dependencies? We get rid of that. Did I understand your question correctly and WDYT? On Mar 7, 2018 5:45 AM, "Paul Foxworthy" <[email protected]> wrote: Thanks Taher, I agree with your idea. I agree that most services can and should be decoupled from user interfaces. As you say if a service exists only to support a UI, it can stay with the UI component. Services that only make sense to support AJAX calls would be one example. If most services move somewhere else, should there be one monolithic component, or several? So where we now have accounting, content and so on, would we have accounting-ui, accounting, content-ui, content and so on? Possibly accounting-services, accounting-ui etc, but -services is long-winded and I think not very useful. Cheers Paul Foxworthy -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: [email protected]
