An Ideal eComm webapp architecture
In between a few weeks home in Ireland for family reasons, I've spent alot of the past 4 working weeks grappling with colleagues regarding eComm website architecture questions.
A number of eComm vendors offer a "website in a box" which a customer then customizes for their site needs. Examples include Demandwares SiteGenesis, Hybris recently released their Accelerator product (see my blog post here for more) and so on.
For some customers these can indeed be a good choice but in other cases its not a good fit for the customer and only guarantees vendor lock in for years to come ultimately leading to an expensive complete rip'n'replace when the whole cycle is often restarted again.
An ideal eComm architecture (and not just eComm) is a service oriented architecture where an app is composed of web services with clearly defined interfaces. Such an architecture is loosely coupled and a given service can be replaced as needed with another service. EComm services could include: Payment Gateway, Mail subscription, CMS, Account/Cart/Checkout, Reviews, Store Locator etc.
Here's a strawman UML diagram of such a site Architecture. Note the WebApp can be a server side app (php/node etc) marking up pages or a complete single page javascript app (browser only) exchanging json as needed. In both cases the WebApp is a consumer of services from a number of service providers.
CMS content can be returned as HTML fragments or json wrapped fragments.
A Search engine such as Solr or equivalent is a great solution for supporting product searches and filtering.
Some server side proxy/facade code may be needed to communicate with more complicated services.
I should note that Demandware does now provide a set of APIs for interacting with their functionality so +1 for Demandware. I have heard a whisper Hybris will offer apis in the future but nothings confirmed.
I will also note one of the challenges with this approach is that as that apis will change as services release new functionality.
A number of eComm vendors offer a "website in a box" which a customer then customizes for their site needs. Examples include Demandwares SiteGenesis, Hybris recently released their Accelerator product (see my blog post here for more) and so on.
For some customers these can indeed be a good choice but in other cases its not a good fit for the customer and only guarantees vendor lock in for years to come ultimately leading to an expensive complete rip'n'replace when the whole cycle is often restarted again.
An ideal eComm architecture (and not just eComm) is a service oriented architecture where an app is composed of web services with clearly defined interfaces. Such an architecture is loosely coupled and a given service can be replaced as needed with another service. EComm services could include: Payment Gateway, Mail subscription, CMS, Account/Cart/Checkout, Reviews, Store Locator etc.
Here's a strawman UML diagram of such a site Architecture. Note the WebApp can be a server side app (php/node etc) marking up pages or a complete single page javascript app (browser only) exchanging json as needed. In both cases the WebApp is a consumer of services from a number of service providers.
CMS content can be returned as HTML fragments or json wrapped fragments.
A Search engine such as Solr or equivalent is a great solution for supporting product searches and filtering.
Some server side proxy/facade code may be needed to communicate with more complicated services.
I should note that Demandware does now provide a set of APIs for interacting with their functionality so +1 for Demandware. I have heard a whisper Hybris will offer apis in the future but nothings confirmed.
I will also note one of the challenges with this approach is that as that apis will change as services release new functionality.
Comments
Post a Comment