Using symfony2 to create an e-commerce portal from scratch
It all started with the fact that we conceived a web portal for the sale of furniture. This is a web portal for selling furniture and interior items, and that I myself have a lot of ideas that we have to implement in the framework of the future portal. All these ideas were similar to an online store, but they did not quite fit into the framework of a regular store. For example, we should show the goods in the beautiful interiors of real apartments - this is interesting, and most importantly, convenient for the buyer. This means that our site should have separate cards and interiors and products that make up the structure. Here's another problem: the portal itself does not have its warehouse and logistics, but only aggregates information: it collects, analyzes, beautifully shows and generates sales from partners. So you need to enter different suppliers, show different delivery terms, etc. Therefore, we faced the question: what can we use to create a portal not from scratch, but at the same time have more flexibility in customizing the selected solutions. So, what we got.
LAMP selection
At first, we chose a common technology stack. It was simple: after all, the most common choice of technologies for web portals is LAMP (Linux, Apache, MySQL, PHP). We did not want to reinvent the wheel, write everything from scratch, as it is expensive and time consuming. We needed to quickly create a portal using any libraries / frameworks, perhaps CMS / E-commerce systems. If LAMP technologies are the most common, it means that we can find a large number of different open-source solutions, and from them we can choose something suitable for the “foundation” of our portal.
Ready E-commerce systems
As soon as we chose PHP and everything connected with it, we began to look at what is already ready on our subject. Of course, we immediately began to think about ready-made E-commerce systems, for example, the growing popularity of Magento. Found several partners Magento, who are engaged in customization and implementation of this system. They asked me to make an approximate estimate of how much it would cost us to “sharpen” Magento for all our requirements, including optimization of speed, with which Magento, as it turned out, has difficulties, especially the free version. Our calculations showed that at the cost of work and further support in the short term - it will be even more expensive than if we wrote everything from scratch in pure PHP. We looked at other E-commerce solutions: osCommerce, ZenCart, PrestoShop. Here the situation was about the same, and maybe even worse. So we returned to the starting point of the search.
')
Framers and libraries
Then we decided to look towards more common solutions: frameworks and libraries. We decided to focus on choosing the 3 most popular frameworks: Zend 1.11, Symfony 2 and Yii. Here we had a more technological approach to choosing: we wanted full support for PHP 5.3, and it is desirable that the framework code itself suggests the writing style of PHP 5.3, namely, as much OOP as possible, because we still need to support it later. From Zend refused immediately. It is very monstrous, and we need about 20 percent of its functionality. In addition, the expected 2.0 was then in the form of ideas on the sites of the main developers. Yii was still very fresh at that time (autumn 2011), and we know what these “hot cakes” are fraught with (as time has shown, the Yii 2.0 version with full PHP 5.3 support is being written so far). And we decided not to take risks and take the most ready and stable product - Symfony 2.
ORM solutions
So, we have chosen both the platform and the framework: LAMP + Symfony2. We also needed to solve the problem with the level of storage and presentation of data in our portal. It’s probably good to write something specific for yourself - it works faster and less code. However, our main problem was that we made our product, and we did not have a clear and constant specification. Improvements (read: frequent changes) in entities, their interconnections and business logic required some kind of flexible solution that we could quickly change and not be afraid to get a lot of regression bugs. In this case, we went a well-beaten road. Now a great popularity is gained by various ORM solutions. This is independent of the technology stack or application domain. Therefore, after a brief discussion, we chose ORM Doctrine 2. Moreover, it is included as a standard module in Symfony 2. Besides, we understood that with the growth of data volumes and interrelations between entities when working on the portal, we will proceed to the use of non-relational DBMS, for example, MongoDB, and with the selected ORM - Doctrine, this is also simply implemented.
Total we have an interesting set of technologies:
LAMP + Symfony 2 + Doctrine 2.
The implicit advantage of the combination of these technologies was that it was very easy for us to continue motivating our employees to work in our team, since the technologies we have chosen are very fresh and promising. Of course, with the exception of LAMP.
Symfony
Now a little more detail about the details of using symfony to create web portals. This topic is already well covered in the post: “Symfony 2: useful libraries and bundles” . By the way, when we saw this post, it turned out that we are already using almost everything in our work. It's nice that our choice is the same. Nevertheless, we would like to briefly list the bundles (plug-ins) that we used, as well as the reasons for this choice.
SonataMediaBundle - we use for work with pictures, video, swf objects - 360, panoramas. If you need to work with media content, I highly recommend it. Bundle is easily customizable and customizable. Now we store the content on the same server as the code. This bundle will allow us to easily upgrade to Amazon or other clouds. And it can be done in just a couple of hours. If you use only pictures, then you will need some kind of wrapper for standard PHP modules - gd, imagick. We used Imagine and AvalancheImagineBundle. You can of course, and something else, but how much do you know of good PHP libraries of this kind?
FOSUserBundle - initially we used it as a quick way to start working with users. Many will say that it is too big for tasks like simple authorization. I will say that it is just a bit more flexible than some need. We have this bundle used in conjunction with the Loginza service. A typical user more often logs in via vkontakte or facebook (I, for example, via twitter).
FOSRestBundle - we are just beginning to actively use it. I can say that the admin in the form that we need fits perfectly into REST. Here both standard operations, like “update”, “delete”, and output in different data formats.
KnpMenuBundle - easily replaced all our code for navigation - menu, bread crumbs. I think every PHP programmer wrote something similar for himself. Down with the bikes! Give us a simple menu!
TwigBundle - because I like templates, I don't like writing them in PHP and, of course, I really don't like Smarty. Yes, we know that there is Smarty 3, which also can do something. However, it’s not for nothing that they were thrown out with smarty.php.net.
SwiftMailer is too heavy a library for us. Our plans include the transition to something easier and simpler. Of the benefits of excellent integration into symfony2.
FOQElasticaBundle - do not like Sphinx. Joke. We do not have the volume of content in which it is difficult to search. Therefore, we decided that Elastica would be a better solution. Out of the box auto-update index on all CRUD operations. Fast and cheap.
Colleagues who were engaged in the creation and development of portals will understand me now - the work never ends. And now we have many tasks and plans for the technical development of the resource, not counting all the fantastic ideas of investors. The most important task for us now is to configure data search and caching, optimize performance, transfer storage of static content to the appropriate servers. About this, if there is enough time, I will write later separately.
I hope this article will be interesting for those who are thinking or are already creating a new successful and technically competent portal, good luck with this business!
LAMP selection
At first, we chose a common technology stack. It was simple: after all, the most common choice of technologies for web portals is LAMP (Linux, Apache, MySQL, PHP). We did not want to reinvent the wheel, write everything from scratch, as it is expensive and time consuming. We needed to quickly create a portal using any libraries / frameworks, perhaps CMS / E-commerce systems. If LAMP technologies are the most common, it means that we can find a large number of different open-source solutions, and from them we can choose something suitable for the “foundation” of our portal.
Ready E-commerce systems
As soon as we chose PHP and everything connected with it, we began to look at what is already ready on our subject. Of course, we immediately began to think about ready-made E-commerce systems, for example, the growing popularity of Magento. Found several partners Magento, who are engaged in customization and implementation of this system. They asked me to make an approximate estimate of how much it would cost us to “sharpen” Magento for all our requirements, including optimization of speed, with which Magento, as it turned out, has difficulties, especially the free version. Our calculations showed that at the cost of work and further support in the short term - it will be even more expensive than if we wrote everything from scratch in pure PHP. We looked at other E-commerce solutions: osCommerce, ZenCart, PrestoShop. Here the situation was about the same, and maybe even worse. So we returned to the starting point of the search.
')
Framers and libraries
Then we decided to look towards more common solutions: frameworks and libraries. We decided to focus on choosing the 3 most popular frameworks: Zend 1.11, Symfony 2 and Yii. Here we had a more technological approach to choosing: we wanted full support for PHP 5.3, and it is desirable that the framework code itself suggests the writing style of PHP 5.3, namely, as much OOP as possible, because we still need to support it later. From Zend refused immediately. It is very monstrous, and we need about 20 percent of its functionality. In addition, the expected 2.0 was then in the form of ideas on the sites of the main developers. Yii was still very fresh at that time (autumn 2011), and we know what these “hot cakes” are fraught with (as time has shown, the Yii 2.0 version with full PHP 5.3 support is being written so far). And we decided not to take risks and take the most ready and stable product - Symfony 2.
ORM solutions
So, we have chosen both the platform and the framework: LAMP + Symfony2. We also needed to solve the problem with the level of storage and presentation of data in our portal. It’s probably good to write something specific for yourself - it works faster and less code. However, our main problem was that we made our product, and we did not have a clear and constant specification. Improvements (read: frequent changes) in entities, their interconnections and business logic required some kind of flexible solution that we could quickly change and not be afraid to get a lot of regression bugs. In this case, we went a well-beaten road. Now a great popularity is gained by various ORM solutions. This is independent of the technology stack or application domain. Therefore, after a brief discussion, we chose ORM Doctrine 2. Moreover, it is included as a standard module in Symfony 2. Besides, we understood that with the growth of data volumes and interrelations between entities when working on the portal, we will proceed to the use of non-relational DBMS, for example, MongoDB, and with the selected ORM - Doctrine, this is also simply implemented.
Total we have an interesting set of technologies:
LAMP + Symfony 2 + Doctrine 2.
The implicit advantage of the combination of these technologies was that it was very easy for us to continue motivating our employees to work in our team, since the technologies we have chosen are very fresh and promising. Of course, with the exception of LAMP.
Symfony
Now a little more detail about the details of using symfony to create web portals. This topic is already well covered in the post: “Symfony 2: useful libraries and bundles” . By the way, when we saw this post, it turned out that we are already using almost everything in our work. It's nice that our choice is the same. Nevertheless, we would like to briefly list the bundles (plug-ins) that we used, as well as the reasons for this choice.
SonataMediaBundle - we use for work with pictures, video, swf objects - 360, panoramas. If you need to work with media content, I highly recommend it. Bundle is easily customizable and customizable. Now we store the content on the same server as the code. This bundle will allow us to easily upgrade to Amazon or other clouds. And it can be done in just a couple of hours. If you use only pictures, then you will need some kind of wrapper for standard PHP modules - gd, imagick. We used Imagine and AvalancheImagineBundle. You can of course, and something else, but how much do you know of good PHP libraries of this kind?
FOSUserBundle - initially we used it as a quick way to start working with users. Many will say that it is too big for tasks like simple authorization. I will say that it is just a bit more flexible than some need. We have this bundle used in conjunction with the Loginza service. A typical user more often logs in via vkontakte or facebook (I, for example, via twitter).
FOSRestBundle - we are just beginning to actively use it. I can say that the admin in the form that we need fits perfectly into REST. Here both standard operations, like “update”, “delete”, and output in different data formats.
KnpMenuBundle - easily replaced all our code for navigation - menu, bread crumbs. I think every PHP programmer wrote something similar for himself. Down with the bikes! Give us a simple menu!
TwigBundle - because I like templates, I don't like writing them in PHP and, of course, I really don't like Smarty. Yes, we know that there is Smarty 3, which also can do something. However, it’s not for nothing that they were thrown out with smarty.php.net.
SwiftMailer is too heavy a library for us. Our plans include the transition to something easier and simpler. Of the benefits of excellent integration into symfony2.
FOQElasticaBundle - do not like Sphinx. Joke. We do not have the volume of content in which it is difficult to search. Therefore, we decided that Elastica would be a better solution. Out of the box auto-update index on all CRUD operations. Fast and cheap.
Colleagues who were engaged in the creation and development of portals will understand me now - the work never ends. And now we have many tasks and plans for the technical development of the resource, not counting all the fantastic ideas of investors. The most important task for us now is to configure data search and caching, optimize performance, transfer storage of static content to the appropriate servers. About this, if there is enough time, I will write later separately.
I hope this article will be interesting for those who are thinking or are already creating a new successful and technically competent portal, good luck with this business!
Source: https://habr.com/ru/post/146112/
All Articles