You’re offline. This is a read only version of the page.
I am attempting to do a series of forum posts that speaks to the architecture, capabilities and limitations of Dynamics 365 e-commerce rendering so the community can make the best decisions while implementing solutions on top of the platform.
I feel the best place to kick start this conversation is to start with high-level architecture of Dynamics 365 e-commerce. Our online document is a great resource to check out. In this post, I will cover the different components of the rendering engine, their roles and responsibilities.
When it comes to e-commerce rendering engine, there are two services behind the scenes – Commerce Online Platform and Node services.
Commerce Online Platform (or just Rendering platform) is an ASP.Net & C# based service that is responsible for doing the initial processing of the user requests. When a user makes a request on the browser, the request will get routed to the Commerce Online Platform service via CDN & Traffic manager.
Commerce online platform is responsible for several things in processing the requests
It then posts this Page object to the Node service and gets back the HTML that is in turn returned to the caller.
Commerce Online Platform does not support any customizations. This service is fully built and managed by Microsoft. This service gets deployed every week. It can take 2-3 weeks for a change that is checked in to make its way to our Production environment. All the environments will get those changes automatically. We leverage our internal flighting services heavily in this layer, that gives us ability to turn on some flows in select environments or roll out changes incrementally on customer environments.
Node service layer is often referred to as Nodejs layer, Partner app or Node container. As the name indicates, this service runs on Node.js and renders the React.js modules server side to build the HTML response. It uses online SDK as the runtime and is pretty much the same service that developers run in their local environments to build and test customizations. The Node.js service is responsible for converting the page object provided by Commerce Online Platform into HTML that is finally sent back to the browser.
The request flow in Node service does the following
Note: Since we support rendering modules both server side and client side, we need to make sure the data used for rendering the module server side is available on the client side as well. So this gets sent down the wire as ___initialData___ and React will hydrate the HTML back to react components client side using this ___initialData___, this in turn lets React execute the lifecycle hooks client side. It’s important to note that, if the data contracts on server side are not optimized, it can bloat the ___initialData___ object . This will affect your site performance and LCP, I will cover this topic in detail in a future post.
This layer hosts all customer customizations and is isolated from the rest of the services that need to be inside a trust boundary. These customizations include
Partner app development starts from our github repository. Developers can execute “yarn msdyn365 pack” command to create a package that can then be deployed to their environment via LCS. More information can be found here.
Please feel free to ask your questions here and i will try and answer them. I intend to cover more topics in coming weeks and if anyone have a topic you prefer to discuss here, please do let me know.
Share
Report
All responses (
Answers (
865
