Meople.Net. How it works?

As you already understood from previous posts, Meople.Net is an aggregator of your personal (and not only) news from social networks, implemented for WEB and Windows 8 . Many of you may legitimately say that the service is far from revolutionary. But in this article I would like to dwell on what makes it unique from a technical (functional) point of view, and not from a user one.

So, how to work with social networks: most social networks provide REST API functionality for third-party developers who want to build their applications on social network platforms / data. That is, if you want to use Facebook or VKontakte data in your application, then this is what you need.
I will omit the general steps that any developer must take:
● registration of the application on the site social. network and obtaining secret keys of the application;
● implementation (in most cases) of OAuth 2.0 authorization ( http://tools.ietf.org/html/rfc6749 );
● actually sending a signed request to the social. network to get the data you need.

Authorization

Authorization is divided into client and server. 99% of applications that are built on a social network platform, make server authorization, which gives them the opportunity to proxy all requests and save your authorization data on their servers. They actually do this. Otherwise, you would have to constantly enter the password for your account in the social. network (or constantly confirm permission to use your account for a third-party application). Your authorization data in this case is stored on third-party servers that do not belong to the social. network. There, anything can happen to them - they can even be taken advantage of without your knowledge: for example, like a page, sign you for some news, send a message to your friends that you have started using some message for advertising purposes. application and so on.
Our service uses client authentication where possible. As a result, your authorization data is in your browser (cookies, data storage) or device and is not stored on our servers. Subscription requests sent to the network, also occurs on the client. That is, when you do not use our service, we don’t even have a theoretical opportunity to use your data.
')

Sending requests for data

When server authorization to obtain actual data, the request is signed on a third-party server, this means that to get some data, a request from your browser goes to a third-party server, from there to the data center of the social network, from the social network back to the third-party server and returns to you. It would seem that everything is fine, but imagine that you are in Russia (and if you read this post, then you are most likely there), and the server of a third-party application in most cases (and we also have it) in the US . This means that your request will figuratively travel like this: Russia -> US third-party server -> US social network (VKontakte is not sure if there is a server there) -> US third-party server -> Russia.
As a result, we see a bunch of requests and there are numerous delays on each of them. Especially in the case of requests Russia-USA. As a result, application performance drops. This is partially solved by caching data on third-party servers for some time (this is one more thing that you always want to avoid) - but you lose the opportunity to get actual data for a given second, and receive data with a delay.

In our case, the work is different. The signed request for receiving data is sent directly from your browser to the nearest data center of the social network, that is, the journey is something like this: Russia -> Russia social network -> Russia. Thus, there are no intermediate third-party servers, which allows you to receive data as quickly as possible and be confident in the security of the request. As you can see, our service uses social infrastructure. networks around the world for performance.



Also, sending requests from the client allows you to solve another big problem. Many networks monitor the number of requests from one IP address and block the application in case of exceeding the limits. In our case, all users have different addresses, which allows to avoid this problem.

- Do you have all the application running on the client?

In 99% that way. We have a JavaScript application running on the client / browser that does all the logic. It was interesting to us to do just that - as we see, it turned out.
As a result, our servers serve only 3 files: HTML, JS, CSS.



All these files are cached on the client and theoretically, even if our server crashes, you can still use the service. If any critical bugs appear, a fix is ​​made, the file version rises, and you get a new version of the application.

- I do not believe that there is not a single request to your server in the process!

And rightly so. Analytical requests, requests containing detected errors or crashes, statistics about new users and visits go to your client (which allows us to understand where and by whom the application is used and improve it). Also, as an example, in order to upload a photo to most social networks, you need to make a submit form, which itself happens after some kind of onclick action and so on. If we upload photos to several networks, instead of calling 5 different form submit, the photo is sent to our server and from there it is added to all selected social networks.

- Why do not you collect data, the same can be used for advertising, etc.?

We do not need your data and what you do in the social. networks. The Meople.Net application was made to be as anonymous as possible. We do not insert advertising and do not intend to do this - since we ourselves use our own application.

Thanks for attention! Leave your questions in the comments. And in subsequent articles, if there is interest, we will tell about JavaScript architecture in more detail.