Pivot 360 or what solutions we used. Part 1
Today, only the lazy does not do a project in the field of online travel. This is basically logical, because the market is growing rapidly, although there are few free niches, and the business is complex. Many have already been able to raise serious investments in hotel booking services or selling vouchers online.
Last December, we entered this market with the iknow.travel project, relying on combining the sale of airline tickets and a content resource, but after 3 months (in February) we decided to rewrite the project from scratch, and we didn’t even withdraw the ticket part from test at that time.
About why this was done in terms of the development strategy of the project, we will lay out a separate post in the near future. Now we want to describe what tasks we had to solve and what technologies were used on the way from the initial release of air tickets + content to the travel designer (the development of the new version took 3 months).
')
WHAT HAPPENED
WHAT BECAME
WHAT THEY WERE DOING
Initially, we set a goal: to leave the site completely open to search engines, while doing so in the style of a one-page application. One-page websites have difficulty with SEO. Google in such cases recommends the so-called Hash Fragments . The bottom line is this: all links begin with "#!", And the robot only replaces "#!" on "? _escaped_fragment =", makes a request and waits for static HTML in response. And it works. We preferred the good old method. Most of the site is available in HTML, which allows search engines to see the pages as on a regular static site (although it was not without compromises). True there are rumors that Googlebot already understands AJAX , but somehow we are not inclined to trust them. And with the usual browser we work on HTML5 PushState (which support is in all modern browsers except IE 9), with automatic switching to a hash URL if HTML5 PushState is not available. And how would you do?
We have decided to choose the language for the task. For server frontend, node.js became the optimal choice. This rather popular platform allowed us to separate the code and templates between the client and the server. JavaScript is a good functional language. But pure JS is exhausting lack of syntactic sugar and tedious with support, so we use CoffeeScript.
Our client is written on the basis of Backbone. Backbone is a JS framework for interactive applications. Everything is built on the basis of 4 concepts:
Their interpretation in Backbone differs from the generally accepted ones. First, the model is separated from the base. It comes bundled with a REST CRUD API, but there are adapters for HTML5 LocalStorage , WebSockets . Secondly, the View is usually not even a View at all, but a controller in the usual sense. I will make a reservation that the terminology is a purely subjective matter, and the authors of Backbone directly say: their preparations are open to any approaches . It is very important to choose and adhere to one approach. What do you think?
By the way, to start with Backbone, we recommend to look at this (we will be happy to translate for Habr - write, if necessary).
In parallel with the choice of the stack of technologies on which the client will be built, we faced the question of choosing a DBMS for storing data.
Since the subject area was new for us, it was obvious that we should not expect that once designed model would be good enough so that it would not have to be changed as the project developed and developed. In NoSQL, we expected to get faster query performance, more convenient and simple storage of complex data, flexibility. Understanding that we will change the base scheme more than once has completely nullified the chances of relational databases being in the technology stack of our project.
Following the analysis of several variants of the NoSQL DBMS, we opted for MongoDB, because of the good combination of its wide capabilities with high speed. In particular, we were attracted by the ability of MongoDB to index arrays, convenient sharding and replication, and good documentation. Also in favor of MongoDB, there is good support for this DBMS and its application in many successful projects (a complete list here , among them such giants as Disney, Craiglist, Foursquare).
Although we initially designed the data storage scheme taking into account the features of document-oriented DBMS, in order to reduce both the query execution time and the size of the database, we had to repeatedly change the database schema. For example, we were faced with the need to support large multidimensional indexes to provide fast filtering of posts, but our attempt to optimize the data storage scheme to ensure maximum query execution speed led to an exponential increase in the size of both the indices and the data itself, with the result that we realized that we did not We will be able to maintain such a database because of its memory requirements. As a result, we found a rather beautiful solution that provided a high speed of execution of all queries without an excessive increase in the size of the indices and data. However, despite the fact that at the moment, we have achieved acceptable indicators on the speed of work and resource consumption, we understand that as the project grows, we will have to modify the current solution more than once.
If it is interesting to see what happened in the end and how it works, then we put the updated project here for the test.
To access the air tickets (if anyone wants to climb there) on the old site use the code: i3n7wt0a8el
If you correctly post a post somewhere, then tell me where. Thank you in advance for feedback. In many ways we had to move quickly (in time for the holiday season) and intuitively, because a similar system was built for the first time. We are happy to answer your questions.
Last December, we entered this market with the iknow.travel project, relying on combining the sale of airline tickets and a content resource, but after 3 months (in February) we decided to rewrite the project from scratch, and we didn’t even withdraw the ticket part from test at that time.
About why this was done in terms of the development strategy of the project, we will lay out a separate post in the near future. Now we want to describe what tasks we had to solve and what technologies were used on the way from the initial release of air tickets + content to the travel designer (the development of the new version took 3 months).
')
WHAT HAPPENED
WHAT BECAME
WHAT THEY WERE DOING
Initially, we set a goal: to leave the site completely open to search engines, while doing so in the style of a one-page application. One-page websites have difficulty with SEO. Google in such cases recommends the so-called Hash Fragments . The bottom line is this: all links begin with "#!", And the robot only replaces "#!" on "? _escaped_fragment =", makes a request and waits for static HTML in response. And it works. We preferred the good old method. Most of the site is available in HTML, which allows search engines to see the pages as on a regular static site (although it was not without compromises). True there are rumors that Googlebot already understands AJAX , but somehow we are not inclined to trust them. And with the usual browser we work on HTML5 PushState (which support is in all modern browsers except IE 9), with automatic switching to a hash URL if HTML5 PushState is not available. And how would you do?
FURTHER, STACK SELECTION
We have decided to choose the language for the task. For server frontend, node.js became the optimal choice. This rather popular platform allowed us to separate the code and templates between the client and the server. JavaScript is a good functional language. But pure JS is exhausting lack of syntactic sugar and tedious with support, so we use CoffeeScript.
Backback
Our client is written on the basis of Backbone. Backbone is a JS framework for interactive applications. Everything is built on the basis of 4 concepts:
- Model
- View
- Collection
- Router
Their interpretation in Backbone differs from the generally accepted ones. First, the model is separated from the base. It comes bundled with a REST CRUD API, but there are adapters for HTML5 LocalStorage , WebSockets . Secondly, the View is usually not even a View at all, but a controller in the usual sense. I will make a reservation that the terminology is a purely subjective matter, and the authors of Backbone directly say: their preparations are open to any approaches . It is very important to choose and adhere to one approach. What do you think?
By the way, to start with Backbone, we recommend to look at this (we will be happy to translate for Habr - write, if necessary).
MongoDB
In parallel with the choice of the stack of technologies on which the client will be built, we faced the question of choosing a DBMS for storing data.
Since the subject area was new for us, it was obvious that we should not expect that once designed model would be good enough so that it would not have to be changed as the project developed and developed. In NoSQL, we expected to get faster query performance, more convenient and simple storage of complex data, flexibility. Understanding that we will change the base scheme more than once has completely nullified the chances of relational databases being in the technology stack of our project.
Following the analysis of several variants of the NoSQL DBMS, we opted for MongoDB, because of the good combination of its wide capabilities with high speed. In particular, we were attracted by the ability of MongoDB to index arrays, convenient sharding and replication, and good documentation. Also in favor of MongoDB, there is good support for this DBMS and its application in many successful projects (a complete list here , among them such giants as Disney, Craiglist, Foursquare).
Although we initially designed the data storage scheme taking into account the features of document-oriented DBMS, in order to reduce both the query execution time and the size of the database, we had to repeatedly change the database schema. For example, we were faced with the need to support large multidimensional indexes to provide fast filtering of posts, but our attempt to optimize the data storage scheme to ensure maximum query execution speed led to an exponential increase in the size of both the indices and the data itself, with the result that we realized that we did not We will be able to maintain such a database because of its memory requirements. As a result, we found a rather beautiful solution that provided a high speed of execution of all queries without an excessive increase in the size of the indices and data. However, despite the fact that at the moment, we have achieved acceptable indicators on the speed of work and resource consumption, we understand that as the project grows, we will have to modify the current solution more than once.
RESULT
If it is interesting to see what happened in the end and how it works, then we put the updated project here for the test.
To access the air tickets (if anyone wants to climb there) on the old site use the code: i3n7wt0a8el
If you correctly post a post somewhere, then tell me where. Thank you in advance for feedback. In many ways we had to move quickly (in time for the holiday season) and intuitively, because a similar system was built for the first time. We are happy to answer your questions.
Source: https://habr.com/ru/post/145811/
All Articles