Five things to consider when thinking about the architecture of an online store
It is no secret that customers do not always know in advance about everything that they need from the software being developed. Many of them also cannot distinguish such innovations that can be easily added to a ready-made system from those that must either be foreseen from the very beginning, or be immediately prepared for significant revisions of the existing code, complex data migrations, and, accordingly, significant time costs.
However, the situation can often be significantly improved if you try to guess the client’s possible desires before developing and immediately explain to him that the decision needs to be made before starting the work, because otherwise (if he later changes his mind), you will have to redo a lot, and it will take a lot of time.
Let's look at what you should immediately consider when discussing an online store project.
Suppose that the online store you are going to write in Python / Django.
')
Many online stores sell products that are significantly different from each other. For example, one set of parameters is given for electric kettles, the second for dildos, and the third for henna for mehndi . Moreover, all these products can be sold on the same site. Or, even more likely, on different sites that use the same database with goods (the client probably wants to be able to manage all the goods of all their stores from the general administrative interface).
Thus, it is usually assumed that the goods must be able to specify a dynamic set of parameters.
You can use MongoDB (or another non-relational DBMS, to choose from). There are many options (this is often discussed, for example, here is one of the topics on softwaremaniacs) - some of them involve the use of the Mongo query language, some leave the opportunity to use ORM (however, there is an opinion that this is a dubious decision). Of course, some dances with a tambourine are needed here in order to add management of this data to the admin panel. In general, the task is not very difficult, but it can be quite a lot of nuances, therefore, the deadline in advance is quite difficult to predict.
But if such a goal is not set, that is, the mechanism for adding and editing goods is your own, and the presence in the standard admin panel (which would require an interface if possible) does not pretend, then this option should be the most convenient and best in terms of capabilities scaling (that is, if you need to store information about more goods, while improving resistance to stress, then you will need to make fewer changes).
Another option - on the contrary, to use everything as standard as possible for Django. In particular, there is django ‑ eav . This is just a solution that allows you to add a dynamic set of fields for objects in the model (of course, the data is not stored in one table - the database remains relational).
In this case, there is a ready-made integration with the admin panel.
But not everything is so smooth: firstly, this option is not very good in terms of performance (that is, we immediately complicate the scaling of the system - so it is more suitable when high loads are not expected), and secondly, it can be additional difficulties in the implementation of multilingualism.
In general, Ivan Sagalaev writes the following about EAV:
Was there any talk about using Django with MongoDB for this purpose? In general, yes . Alix Axel's response is that there are some good links (for example, to this presentation), which reveal how MongoDB is used for e-commerce. However, specific solutions for Django are not given there.
Here's a little more about using EAV, as well as hstore (this is the option of storing a dynamic set of values for PostgreSQL):
- Grigory Fateyev about hstore, from here .
On the Internet you can find a lot of information about the various ways of implementing dynamic fields. For example, here is another discussion on Stackoverflow.
There are various solutions for the implementation of multilingual content - in this case, the speech, in particular, the translation into different languages of the parameters that are set for the goods. However, depending on which approach for data storage you intend to use, these applications may not be suitable (although you can try to adapt any of them).
In many cases, the revision history for each product can be very useful for the customer (for example, to restore something, if not edited so).
With a relational database, this is done using one of the ready-made applications .
For example, django ‑ reversion can display diff using django ‑ reversion-compare (scroll down to see screenshots).
There is also django ‑ history - the work of the Ufim ildus developer . And here is a review of django ‑ reversion, django ‑ revisions and django ‑ simple ‑ history.
If you use a non-relational database, then there is, of course, a little more complicated. Although generally a dynamic set of fields + a dynamic set of translations are very strong arguments in favor of using Mongo, it seems to me. In the end, because it exists to store such “embedded” data in it (plus there is an opportunity to conveniently group values!). The only counter-argument here, probably, is the possible complexity of integration with existing e-commerce solutions. On the other hand, with this, the difficulties in any case will be in the development of any relatively complex project, so far they have not been completely circumvented.
In most cases, tree categories are required for products: that is, each category can have not only products, but also several levels of nesting (for example, Audio → Headphones → Open).
By the way, here is a good discussion of the implementation of such a hierarchy of objects in Django (besides the mention of django-mptt there are some good tips).
Do not forget to take into account plans for expansion: perhaps the client will need a mobile application in the future, or, for example, he is going to agree on the sale of some goods through the website of his partners. Anyway, do not forget to ask him if he is going to do something, which may require developing your own API.
Let's see what can be used to save time.
Comparisons and Reviews:
There is also a blog on this topic.
More on Habré there is an article about Oscar .
In general, Satchless and LFS are the least abused, which means we can assume that they are the most decent. However, the most decent ≠ decent ones, in principle, unfortunately: in practice, in fact, and in another case, you are very likely to end up with your own fork, and the merge update from the official repository will not be easy (and maybe not necessary at all - but then you need to monitor if there are any security fixes in their commits that may also affect your branch).
And it also turns out that the authors of Satchless are not at all enthusiastic about the idea of dynamic fields for goods .
Apparently, the tree structure of categories in Satchless is fine. But it is quite expected for any such decision, as it is very much in demand.
As for LFS (Lightning Fast Shop), there are also tree categories out of the box , and a kind of EAV (but not multilingual). However, it is implemented in such a way that I would be careful to use this on a large project.
By the way, the creators of Satchless do not like LFS, because they consider it not too modular.
In practice, perhaps the fastest solution that leads to the smallest number of hacks is generally writing your store based on individual ready-made components (for example, take a ready-made payment system for which there are already several backends and the ability to write new ones fairly easily). In the end, if these components are not in the form of separate applications, then you can see how closely they are integrated with Satchless or LFS, and if you can see that it is not very strong, then you can try to pull them out.
I think that it is obvious to the reader: if you write your own solution, in which all the problems described above are solved at once, and then put it on the Internet, then it will most likely quickly become widespread.
However, the situation can often be significantly improved if you try to guess the client’s possible desires before developing and immediately explain to him that the decision needs to be made before starting the work, because otherwise (if he later changes his mind), you will have to redo a lot, and it will take a lot of time.
Let's look at what you should immediately consider when discussing an online store project.
Suppose that the online store you are going to write in Python / Django.
')
א. Storage of product data
Many online stores sell products that are significantly different from each other. For example, one set of parameters is given for electric kettles, the second for dildos, and the third for henna for mehndi . Moreover, all these products can be sold on the same site. Or, even more likely, on different sites that use the same database with goods (the client probably wants to be able to manage all the goods of all their stores from the general administrative interface).
Thus, it is usually assumed that the goods must be able to specify a dynamic set of parameters.
You can use MongoDB (or another non-relational DBMS, to choose from). There are many options (this is often discussed, for example, here is one of the topics on softwaremaniacs) - some of them involve the use of the Mongo query language, some leave the opportunity to use ORM (however, there is an opinion that this is a dubious decision). Of course, some dances with a tambourine are needed here in order to add management of this data to the admin panel. In general, the task is not very difficult, but it can be quite a lot of nuances, therefore, the deadline in advance is quite difficult to predict.
But if such a goal is not set, that is, the mechanism for adding and editing goods is your own, and the presence in the standard admin panel (which would require an interface if possible) does not pretend, then this option should be the most convenient and best in terms of capabilities scaling (that is, if you need to store information about more goods, while improving resistance to stress, then you will need to make fewer changes).
Another option - on the contrary, to use everything as standard as possible for Django. In particular, there is django ‑ eav . This is just a solution that allows you to add a dynamic set of fields for objects in the model (of course, the data is not stored in one table - the database remains relational).
In this case, there is a ready-made integration with the admin panel.
But not everything is so smooth: firstly, this option is not very good in terms of performance (that is, we immediately complicate the scaling of the system - so it is more suitable when high loads are not expected), and secondly, it can be additional difficulties in the implementation of multilingualism.
In general, Ivan Sagalaev writes the following about EAV:
EAV is when the attribute set is not fixed or just very large. Having several thousand tables in the database, each of which will have one column and several thousand records, one or two of which are filled, is not very cool.
Therefore, if you need EAV, then no inheritance will help. On the other hand, using such a system is not very convenient. It is not supported by the ORM in an explicit form, and yes even purely by construction it is more difficult to build queries for such tables and they work more slowly. And so, I have long believed that if your system requires such an approach, then this essentially means that it is inconvenient for it to use the relational storage. And it would be better to look in the direction of document-oriented databases (CouchDB as the most vivid example). Although it requires a lot of effort to change the consciousness and the abandonment of relational practices.
Was there any talk about using Django with MongoDB for this purpose? In general, yes . Alix Axel's response is that there are some good links (for example, to this presentation), which reveal how MongoDB is used for e-commerce. However, specific solutions for Django are not given there.
Here's a little more about using EAV, as well as hstore (this is the option of storing a dynamic set of values for PostgreSQL):
There is a search and a direct connection with the objects. Naturally, the sample will not be too fast, but for small shops this should not be a problem.
- Grigory Fateyev about hstore, from here .
On the Internet you can find a lot of information about the various ways of implementing dynamic fields. For example, here is another discussion on Stackoverflow.
ב. Multilingualism
There are various solutions for the implementation of multilingual content - in this case, the speech, in particular, the translation into different languages of the parameters that are set for the goods. However, depending on which approach for data storage you intend to use, these applications may not be suitable (although you can try to adapt any of them).
ג. Edit history
In many cases, the revision history for each product can be very useful for the customer (for example, to restore something, if not edited so).
With a relational database, this is done using one of the ready-made applications .
For example, django ‑ reversion can display diff using django ‑ reversion-compare (scroll down to see screenshots).
There is also django ‑ history - the work of the Ufim ildus developer . And here is a review of django ‑ reversion, django ‑ revisions and django ‑ simple ‑ history.
If you use a non-relational database, then there is, of course, a little more complicated. Although generally a dynamic set of fields + a dynamic set of translations are very strong arguments in favor of using Mongo, it seems to me. In the end, because it exists to store such “embedded” data in it (plus there is an opportunity to conveniently group values!). The only counter-argument here, probably, is the possible complexity of integration with existing e-commerce solutions. On the other hand, with this, the difficulties in any case will be in the development of any relatively complex project, so far they have not been completely circumvented.
ד. Product Categories
In most cases, tree categories are required for products: that is, each category can have not only products, but also several levels of nesting (for example, Audio → Headphones → Open).
By the way, here is a good discussion of the implementation of such a hierarchy of objects in Django (besides the mention of django-mptt there are some good tips).
ה. API
Do not forget to take into account plans for expansion: perhaps the client will need a mobile application in the future, or, for example, he is going to agree on the sale of some goods through the website of his partners. Anyway, do not forget to ask him if he is going to do something, which may require developing your own API.
Community groundwork
Let's see what can be used to save time.
Comparisons and Reviews:
- www.readncode.com/blog/the-state-of-ecommerce-in-django (April 2011)
- valentinewebsystems.com/en/blog/ecommerce-comparison (July 2010, solutions in general in Python are not only Django, there is a translation from komtet )
- www.djangopackages.com/grids/g/ecommerce (periodically updated / edited)
There is also a blog on this topic.
More on Habré there is an article about Oscar .
In general, Satchless and LFS are the least abused, which means we can assume that they are the most decent. However, the most decent ≠ decent ones, in principle, unfortunately: in practice, in fact, and in another case, you are very likely to end up with your own fork, and the merge update from the official repository will not be easy (and maybe not necessary at all - but then you need to monitor if there are any security fixes in their commits that may also affect your branch).
And it also turns out that the authors of Satchless are not at all enthusiastic about the idea of dynamic fields for goods .
Apparently, the tree structure of categories in Satchless is fine. But it is quite expected for any such decision, as it is very much in demand.
As for LFS (Lightning Fast Shop), there are also tree categories out of the box , and a kind of EAV (but not multilingual). However, it is implemented in such a way that I would be careful to use this on a large project.
By the way, the creators of Satchless do not like LFS, because they consider it not too modular.
In practice, perhaps the fastest solution that leads to the smallest number of hacks is generally writing your store based on individual ready-made components (for example, take a ready-made payment system for which there are already several backends and the ability to write new ones fairly easily). In the end, if these components are not in the form of separate applications, then you can see how closely they are integrated with Satchless or LFS, and if you can see that it is not very strong, then you can try to pull them out.
I think that it is obvious to the reader: if you write your own solution, in which all the problems described above are solved at once, and then put it on the Internet, then it will most likely quickly become widespread.
Source: https://habr.com/ru/post/216689/
All Articles