Tracks Flow from the inside
What is nested MVC? How do three Node, php-fpm and IIS back-end servers get along in one project? Can I run the music service on my laptop? And how does tracksflow.com work from the inside?
At the start of the project tracksflow.com was the task of making a music service that:
')
At the time of the start of development we had:
Since we have several clients planned and the site will be implemented as a web application, we will strictly separate the database (model) from the views.
We will separate the model from the presentation using the API in the REST format — a platform-independent technology that is easy to implement on all clients.
The data transfer format is JSON. There were heated debates with the iOS team, but through brute force they were forced to work with JSON - this is more convenient for the majority.
It was clear that working with several third-party services would introduce an element of randomness into the work of the site and iOS apps - you can never be sure that something will come back to you and, if so, when. We also wanted to have a uniform data transfer format for all third-party services. At that moment, the idea was born of using Node.js as a lightweight MVC controller, which will interact asynchronously with the API of third-party services, simultaneously bringing the results into the desired form.
Thus, we have developed the concept of MVC at the level of system components. Web and mobile applications acted as presentations. Node.js - the controller. .Net and third-party services - model.
The only thing is that vk.com had to be tied directly to the clients since their API imposes restrictions on the number of requests from a single IP address, binds sessions to IPs and generally promotes the implementation of methods for working with the vk.com API on the client in general.
In turn, MVC was used as an internal pattern in all client applications and in .NET. So much for the nested doll from MVC :)
Then it turned out that using Node.js for proxying requests to our own backend on .Net is not very convenient - the node was clearly an extra link and we saved it from this work by sending requests from clients to the .Net backend “directly” through nginx.
Yes, all requests through the helmet nginks. This saves us problems with cross-domain queries, closes backend servers from direct access. Also nginx allows in case of something unforeseen to redirect requests to another assembly / server.
To store avatars we used a time-tested system in php, which provided storage of 120 TB of data in fidel.ru. Place under it, of course, reduced.
The backend is written in ASP.NET MVC 3. In working on previous projects, the horosho bundle with .NET MVC 3 showed itself from the good side - the REST API is easy and beautiful. Entity Framework 4.2 beta is used to access the database.
Mobile (iOS) application is written by newonder by native means. The application has implemented many interesting elements: a navigation menu that opens by swiping; brushing table cells; data model migration system. The application is already in the AppStore .
The client part of the site is implemented by vmkcom using MVC using the backbone.js + underscore.js bundle. Routing is based on pushState and uses the history API in those browsers where it is supported, in the rest - hashtags.
The good old jQuery is responsible for working with the DOM.
Of the interesting features:
Now the tracksflow.com service is working in the DataLine cloud of three virtual machines:
linux system with nginx + php-fpm + node.js. Features 2 GB of memory, 32Gb hdd, 1 CPU Xeon 2.67GHz core.
Windows Server 2003 IIS 6 with .NET MVC backend. Features 2 GB of memory, 60Gb hdd, 1 CPU Xeon 2.67GHz core.
Windows Server 2003 SQL Server 2008. Features 4 GB of memory, 250Gb hdd, 2 CPU core Xeon 2.67GHz.
Total for the whole service 4 cores, 340 GB Hdd, 8 GB of memory: tracksflow.com can be safely launched on a laptop :)
We do not claim a high-load project. There was a load of 50 requests per second during the publication of the blog post before last - we stood at the limit. The narrow place was a pair of join-s, performed by the Entity Framework on the web server side. Now we have optimized the bottlenecks, we have tested - about 500 requests per second came out.
In the near future, several more detailed articles about different service systems are planned. Write in the comments, what is worth telling in the first place.
And, by the way, we are looking for super people in our excellent office on Red October.
At the start of the project tracksflow.com was the task of making a music service that:
- will take content and metadata to it from open sources,
- will have its own user base with playlists / likes attached to them and other things,
- will contain social tools
- will have multiple inputs - web / mobile applications,
- the site will be executed as a web application (no page reloads, implementation of a part of logic on the client).
')
At the time of the start of development we had:
- 5 licenses of Windows server 2003,
- 2 MS SQL Server 2008 licenses (per processor license),
- php file storage system with C # client library,
- three JS programmers, one .NET programmer, two Objective-C programmers.
The decisions that we made at the very start
Since we have several clients planned and the site will be implemented as a web application, we will strictly separate the database (model) from the views.
We will separate the model from the presentation using the API in the REST format — a platform-independent technology that is easy to implement on all clients.
The data transfer format is JSON. There were heated debates with the iOS team, but through brute force they were forced to work with JSON - this is more convenient for the majority.
It was clear that working with several third-party services would introduce an element of randomness into the work of the site and iOS apps - you can never be sure that something will come back to you and, if so, when. We also wanted to have a uniform data transfer format for all third-party services. At that moment, the idea was born of using Node.js as a lightweight MVC controller, which will interact asynchronously with the API of third-party services, simultaneously bringing the results into the desired form.
Thus, we have developed the concept of MVC at the level of system components. Web and mobile applications acted as presentations. Node.js - the controller. .Net and third-party services - model.
The only thing is that vk.com had to be tied directly to the clients since their API imposes restrictions on the number of requests from a single IP address, binds sessions to IPs and generally promotes the implementation of methods for working with the vk.com API on the client in general.
In turn, MVC was used as an internal pattern in all client applications and in .NET. So much for the nested doll from MVC :)
Then it turned out that using Node.js for proxying requests to our own backend on .Net is not very convenient - the node was clearly an extra link and we saved it from this work by sending requests from clients to the .Net backend “directly” through nginx.
Yes, all requests through the helmet nginks. This saves us problems with cross-domain queries, closes backend servers from direct access. Also nginx allows in case of something unforeseen to redirect requests to another assembly / server.
What is it written on?
To store avatars we used a time-tested system in php, which provided storage of 120 TB of data in fidel.ru. Place under it, of course, reduced.
The backend is written in ASP.NET MVC 3. In working on previous projects, the horosho bundle with .NET MVC 3 showed itself from the good side - the REST API is easy and beautiful. Entity Framework 4.2 beta is used to access the database.
Mobile (iOS) application is written by newonder by native means. The application has implemented many interesting elements: a navigation menu that opens by swiping; brushing table cells; data model migration system. The application is already in the AppStore .
The client part of the site is implemented by vmkcom using MVC using the backbone.js + underscore.js bundle. Routing is based on pushState and uses the history API in those browsers where it is supported, in the rest - hashtags.
The good old jQuery is responsible for working with the DOM.
Of the interesting features:
- we use HTML5 / Flash / SilverLight player mediaelement.js, which automatically detects support for a particular codec in the browser and launches the necessary plugin for playback,
- A socket.io bundle with Node.js is used to send push notifications about new events.
Iron
Now the tracksflow.com service is working in the DataLine cloud of three virtual machines:
linux system with nginx + php-fpm + node.js. Features 2 GB of memory, 32Gb hdd, 1 CPU Xeon 2.67GHz core.
Windows Server 2003 IIS 6 with .NET MVC backend. Features 2 GB of memory, 60Gb hdd, 1 CPU Xeon 2.67GHz core.
Windows Server 2003 SQL Server 2008. Features 4 GB of memory, 250Gb hdd, 2 CPU core Xeon 2.67GHz.
Total for the whole service 4 cores, 340 GB Hdd, 8 GB of memory: tracksflow.com can be safely launched on a laptop :)
Loads
We do not claim a high-load project. There was a load of 50 requests per second during the publication of the blog post before last - we stood at the limit. The narrow place was a pair of join-s, performed by the Entity Framework on the web server side. Now we have optimized the bottlenecks, we have tested - about 500 requests per second came out.
In the near future, several more detailed articles about different service systems are planned. Write in the comments, what is worth telling in the first place.
And, by the way, we are looking for super people in our excellent office on Red October.
Source: https://habr.com/ru/post/147137/
All Articles