Architecture overview: Difference between revisions
m (Resque has been replaced by Sidekiq) |
|||
(One intermediate revision by one other user not shown) | |||
Line 6: | Line 6: | ||
For D*. background processing of jobs is important, because we do a lot of network communication with other servers, and we can't have the UI block while that is taking place. | For D*. background processing of jobs is important, because we do a lot of network communication with other servers, and we can't have the UI block while that is taking place. | ||
This is taken care of by | This is taken care of by Sidekiq (another Gem, https://github.com/mperham/sidekiq) and Redis (a key-value store). | ||
So, when you write a post, your server saves it to the database and hands processing (e.g. sending your post to users on different servers) over to | So, when you write a post, your server saves it to the database and hands processing (e.g. sending your post to users on different servers) over to Sidekiq, which then takes place in the background as a separate process. | ||
== Application Structure == | == Application Structure == | ||
Line 39: | Line 39: | ||
=== Automated Testing === | === Automated Testing === | ||
Also, there are many automated Tests written for Rspec (another Gem, automated Testing framework for Ruby), Jasmine (JavaScript testing Framework) and Cucumber (Integration Tests using a remote-controlled Browser session, that acutally interacts with the site like a user would). See also: http://wiki.diaspora-project.org/wiki/Testing_Workflow | Also, there are many automated Tests written for Rspec (another Gem, automated Testing framework for Ruby), Jasmine (JavaScript testing Framework) and Cucumber (Integration Tests using a remote-controlled Browser session, that acutally interacts with the site like a user would). See also: http://wiki.diaspora-project.org/wiki/Testing_Workflow | ||
[[Category:Technical]] | |||
[[Category:Developers]] |
Latest revision as of 16:58, 6 June 2017
Overview of the Diaspora* Network
Overview of used technologies
For D*. background processing of jobs is important, because we do a lot of network communication with other servers, and we can't have the UI block while that is taking place. This is taken care of by Sidekiq (another Gem, https://github.com/mperham/sidekiq) and Redis (a key-value store). So, when you write a post, your server saves it to the database and hands processing (e.g. sending your post to users on different servers) over to Sidekiq, which then takes place in the background as a separate process.
Application Structure
Every request goes throug the Rails routing mechanism (http://guides.rubyonrails.org/routing.html) - every URL is mapped to an action inside a controller.
e.g. When a user requests the stream page with the Browser:
GET yourpod.net/stream -> StreamsController#multi
When a user writes a new post from the Browser:
POST yourpod.net/status_messages -> StatusMessagesController#create
The Diaspora* protocol uses HTTPS as transfer mechanism, so receiving messages from other Server also get routed via Rails to a controller action:
e.g. When a user receives a message from another Server:
POST yourpod.net/receive/public -> PublicsController#receive
Rails enforces a Model-View-Controller based approach for application design (http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture) and encourages the developers to stick to REST-ful routes as much as possible (http://guides.rubyonrails.org/getting_started.html#rest).
Controllers
Controllers can be divided into two basic use-cases: Web UI handling and protocol handling. Web UI contains the normal HTML responses, AJAX responses and some special cases like ATOM feeds or Webfinger for user discovery. The protocol handlers are the entry points for the Diaspora* server-to-server protocol, where messages from other servers are received.
Automated Testing
Also, there are many automated Tests written for Rspec (another Gem, automated Testing framework for Ruby), Jasmine (JavaScript testing Framework) and Cucumber (Integration Tests using a remote-controlled Browser session, that acutally interacts with the site like a user would). See also: http://wiki.diaspora-project.org/wiki/Testing_Workflow