Scaling Wix to 100 million users. Start
Hello! Today we are starting a series of posts from our engineers about scaling Wix. Our audience grew dynamically: Wix website builder was created in 2006, in 2009 our service audience reached 1 million users, and today this figure has already reached 80 million. In our series of posts, our chief architect of Wix software Yoav Abrahami will tell about our architecture at each development stage.
When we launched Wix in 2006, there was no clear understanding of what kind of implementation of the Flash site designer would be working, and what the WYSIWYG site designer actually means. We were engaged in the development of two Flash applications: one for editing sites (it created the site representation as an XML document) and another for displaying sites (based on an XML document). Most of the development was done in Flash. In addition, we also needed a server to store and process XML files based on the URL template or site domain. Our first backend engineer built this server on Tomcat, Hibernate, Ehcache and MySQL. In addition, our server was based on its own framework, which generated Java entity files from Hibernate HBM files, which made it possible to add new code by inheriting from the generated classes.
On the first day of my work at Wix in 2006, I was asked to comment on this structure:
I said: "For a start, this is a great option, but within 2-3 years it will need to be replaced."
In the early stages of a startup, when we still do not know what will work and what changes are expected of the product, the logic is that it is important first of all to ensure rapid development and not focus on pure engineering, scalable architecture, or development through testing (TDD ). If at that time we practiced TDD or ordered a design, then perhaps we would not have been able to create Wix at all.
')
In 2008, one of the founders told me: “You said that by that time it would be time for us to change the server part. The only thing you forgot to mention is how difficult it will be. ” During these two years, the Wix server has become an artifact that supports all sorts of services, from storing XML files and processing them to downloading media files and managing the comment module.
As a vivid example of how this server works, you can use the method of saving documents (for example, websites). This method was built on a CRUD design pattern that Hibernate promotes. He supported the creation of new documents, and editing existing ones. At some point, we decided that we would not delete documents, but instead simply mark them as deleted. From this point on, the save method also provided deletion.
Later we added bonus tariff plans for websites and we wanted the relevant documents to contain a note about their premium status. Therefore, we added a field for the premium flag to the document and included logic in the save method for working with it (for example, you cannot delete a premium document and you cannot set a premium flag for a deleted document). As the product develops, we cram more and more functionality into the same preservation method. We then joked that the preservation method can do anything, even make coffee!
In 2008, we gradually began to replace this server. It was finally stopped in 2012. Migration from the source server to our current architecture took 4 years, because we continued to develop our product and convert it from Flash website builder to HTML5 website builder.
The full history of this transition is beyond the scope of this article, but I will return to it later. Now the question is: did we do it right when we decided to build a system based on a server that was not well thought out from an architectural point of view? Was it worth moving quickly forward at the cost of accumulating a huge technical debt?
The first lesson we learned at the beginning of work on Wix is ​​that when we start a project or a startup and we don’t know which version of the product will work (and most startups don’t know), we need to move quickly. It is necessary to adapt, to use any tools familiar to us, regardless of the scale and correct methodologies (such as TDD). And yes, coding debt will pile up.
The second lesson (which we failed) is that, of course, it is necessary to build a system quickly, but at the same time build it in the calculation for subsequent gradual processing. From the very first stage, we must prepare to change parts of the system when it is required. Moreover, so that the alteration requires minimal effort. If we did, we would replace our source server in a year or two and not spend four years on this work. However, we built a classic spaghetti server and paid for it.
In the early stages, develop quickly, with an eye toward gradual processing.
Chief Software Architect for Wix site creation ,
Yoav Abrahami
Original article: Wix engineers blog
When we launched Wix in 2006, there was no clear understanding of what kind of implementation of the Flash site designer would be working, and what the WYSIWYG site designer actually means. We were engaged in the development of two Flash applications: one for editing sites (it created the site representation as an XML document) and another for displaying sites (based on an XML document). Most of the development was done in Flash. In addition, we also needed a server to store and process XML files based on the URL template or site domain. Our first backend engineer built this server on Tomcat, Hibernate, Ehcache and MySQL. In addition, our server was based on its own framework, which generated Java entity files from Hibernate HBM files, which made it possible to add new code by inheriting from the generated classes.
Source architecture
On the first day of my work at Wix in 2006, I was asked to comment on this structure:
I said: "For a start, this is a great option, but within 2-3 years it will need to be replaced."
In the early stages of a startup, when we still do not know what will work and what changes are expected of the product, the logic is that it is important first of all to ensure rapid development and not focus on pure engineering, scalable architecture, or development through testing (TDD ). If at that time we practiced TDD or ordered a design, then perhaps we would not have been able to create Wix at all.
')
In 2008, one of the founders told me: “You said that by that time it would be time for us to change the server part. The only thing you forgot to mention is how difficult it will be. ” During these two years, the Wix server has become an artifact that supports all sorts of services, from storing XML files and processing them to downloading media files and managing the comment module.
The preservation method can do everything ... even make coffee!
As a vivid example of how this server works, you can use the method of saving documents (for example, websites). This method was built on a CRUD design pattern that Hibernate promotes. He supported the creation of new documents, and editing existing ones. At some point, we decided that we would not delete documents, but instead simply mark them as deleted. From this point on, the save method also provided deletion.
Later we added bonus tariff plans for websites and we wanted the relevant documents to contain a note about their premium status. Therefore, we added a field for the premium flag to the document and included logic in the save method for working with it (for example, you cannot delete a premium document and you cannot set a premium flag for a deleted document). As the product develops, we cram more and more functionality into the same preservation method. We then joked that the preservation method can do anything, even make coffee!
In 2008, we gradually began to replace this server. It was finally stopped in 2012. Migration from the source server to our current architecture took 4 years, because we continued to develop our product and convert it from Flash website builder to HTML5 website builder.
The full history of this transition is beyond the scope of this article, but I will return to it later. Now the question is: did we do it right when we decided to build a system based on a server that was not well thought out from an architectural point of view? Was it worth moving quickly forward at the cost of accumulating a huge technical debt?
The lessons we have learned
The first lesson we learned at the beginning of work on Wix is ​​that when we start a project or a startup and we don’t know which version of the product will work (and most startups don’t know), we need to move quickly. It is necessary to adapt, to use any tools familiar to us, regardless of the scale and correct methodologies (such as TDD). And yes, coding debt will pile up.
The second lesson (which we failed) is that, of course, it is necessary to build a system quickly, but at the same time build it in the calculation for subsequent gradual processing. From the very first stage, we must prepare to change parts of the system when it is required. Moreover, so that the alteration requires minimal effort. If we did, we would replace our source server in a year or two and not spend four years on this work. However, we built a classic spaghetti server and paid for it.
Summarizing
In the early stages, develop quickly, with an eye toward gradual processing.
Chief Software Architect for Wix site creation ,
Yoav Abrahami
Original article: Wix engineers blog
Source: https://habr.com/ru/post/279903/
All Articles