Last week I wrote an article about my experience with Magento and why I think it’s not good as a choice for an ecommerce platform.
Some people asked me what should be the right platform to choose. I could write a comparison between the most popular ecommerce platforms available, but you can easily find that just googling.
I’m going to tell you instead how would I build an ecommerce if I had to.
A wrong concept
Back in the early 90's, every webpage was served as a single document.
Each user action ended up with a complete page refresh. That was a very inefficient process: to update a single part of a page, the whole page was dumped and a new complete page was served.
Then, in the 2000s, AJAX arrived. The browser could now fetch and update content asynchronously. The user experience improved a lot. Rich applications like Gmail were born.
In this new concept of web, an initial webpage is received from the server, and some parts are then asynchronously fetched and updated. This is the kind of architecture that all of the most popular ecommerce platform embrace, like Magento, Prestashop, Wordpress+WooCommerce, etc.
Now, more than 10 years after that, browsers are growing more and more powerful. They even have local storage and offline applications. Other than that, internet is not just about browsers but there are also smartphone apps, watches apps and a lot more clients are going to be added to the equation.
On a side note, it’s now common to see single page applications that reside entirely in the browser and fetch data from a remote service, making a the user experience rich and fluid.
The right architecture
An ecommerce has to solve a lot of different problems, including:
- Sell producs (yay)
- Have a good user experience
- Manage catalog and inventory
Using a one-size-fits-all product that tries to solves all these problems is not the right way to go.
Separation of conerns is a well-estabilished design principle in computer programs. We build our software separated in different pieces, so that every single piece does only a simple thing, so it’s easily re-usable and testable.
With the new web technologies (like modern frontend frameworks) we can easily bring separation of concerns in our web application architecture by reducing our core ecommerce in one simple service accessible via an API with all the essentials logic, and then build other services on top of it.
This architecture is called SOA (Service Oriented Architecture).
How would I build it
I’m not reinventing the wheel here, a lot of web application are made this way nowadays, but I think that ecommerce solutions are somewhat behind other cutting-edge industries (e.i. startups).
Sylius is a new promising ecommerce platform based on Symfony.
It is a full stack solution but you can cherry-pick the parts that you need, if you prefer.
It has a modern, clean and easy to test codebase, and it comes with an API that it’s perfect for this concept.
Using the Sylius API you can isolate the core ecommerce functionality in a service, and then you can build anything else you need on top of it.
You are not tied to a single product or technology, but anything can communicate and interact with your store.
You could easily build anything on top of it, like a new dashboard for the executives, a python script to import bulk products, a software for a physical store or even connect your store to other APIs. All of this without touching your core service and using your favourite technologies and languages.
You can easily plug third-party software for CRM, Management, Accounting, etc.
I personally believe that the Service Oriented Architecture is the future of the web, and now with Sylius almost mature and modern frontend frameworks like AngularJS it is possible to build a next generation ecommerce solution.
Actually I think that I will build a proof of concept this summer. Do you have an idea for an ecommerce? Maybe we could be partners! Drop me a line.
Did you like this post? Do you agree or disagree?
Commenting is encouraged.
Follow me on twitter at @salvozappa
Thank you for reading this far.