Development help

This page is intended to be a high-level explanation of the crossposter to help people that want to help with a feature to get situated in the code.

The crossposter is divided in two entities:

• The rails application: The rails application is responsible for the frontend to connect accounts and set the configurations on how to crosspost.
• The sidekiq process: Process jobs, such as
  • check for users that haven't been checked for longer than the defined interval, and fires a job for them
  • checks twitter and mastodon for new posts and crossposts as necessary
  • fire the cleanup job to clean empty users, ids older than a year and stuff like that

When adding a new feature, you'll most likely need to touch both the rails application and the sidekiq-related classes. You'll usually touch the rails application to add new options that the users can configure, and the sidekiq-related classes to do changes that affect the crossposting.

Processing a user: When a user hasn't been processed for longer than the defined interval (which by default is 30s), a job will be created so that it is checked, a ProcessUserWorker. That will process both Mastodon and Twitter. If an error occurs while processing Twitter, Mastodon will be skipped. (The reason for that is that if Twitter check fails, it's most likely a Mastodon-related issue, such as timeout on the server or something similar, which means that Mastodon should be ignored anyway - ideally this will be changed so that checks are independent)

The two important classes to have in mind are TwitterUserProcessor - responsible for getting tweets and turning them into toots - and MastodonUserProcessor - which does the opposite path. For legacy reasons, they live in the lib/ directory, but should be refactored and moved into app/objects.

The Mastodon API lib is extended using lib/mastodon_ext.rb, to give us some facilities to access extra classes.