researchhub/researchhub-backend

1. This is a Django monolith organized into many domain apps under src/. The main application bootstrap lives in researchhub/ (settings, urls, wsgi, asgi, celery), while each feature area owns its own models, views, serializers, permissions, services, signals, tasks, and migrations.

2. The core architectural boundary is the Django API layer. Most request handling flows through app-specific DRF views and viewsets, with serializers shaping payloads and permission classes enforcing access. The repo is not a single-purpose app; it exposes a broad API for content, identity, search, funding, discussion, and AI-assisted workflows.

3. Content is centered around the paper/document stack. paper/, researchhub_document/, discussion/, review/, note/, hub/, topic/, tag/, and user/ collectively model scholarly content, authorship, versions, comments, topics, hubs, and moderation state. This content layer feeds most downstream features.

4. Ingestion is a major subsystem. paper/ingestion/ contains a pipeline, source clients, mappers, and enrichment services for external sources such as OpenAlex and preprint providers. The data flow is: external source APIs/XML feeds → parsers/mappers → paper domain models → enrichment and task execution. There are many management commands for backfills and repair jobs, which indicates the ingestion path is both online and batch-driven.

5. researchhub_document/ is the unifying abstraction used across the platform. It defines unified document records and document filters, and it connects papers, posts, grants, notes, and other entities into a common indexing/browse model. This layer is the bridge between content creation and the discovery surfaces.

6. Search is a dedicated subsystem backed by OpenSearch. search/ contains OpenSearch documents, query builders, serializers, view endpoints, and Celery tasks for indexing and cleanup. The search flow is: domain objects change → signals/tasks update OpenSearch documents → search and suggest endpoints query the index. The README confirms OpenSearch is required for browse/search, and there are commands for index rebuild and cleanup.

7. Feed generation is another major read-optimized layer. feed/ builds several feed variants: activity, funding, grant, journal, moderator, personalized, and ResearchHub feeds. It uses feed entries, hot-score logic, filtering, cache segmentation, and a large set of signals from content and transaction apps to invalidate or recompute feeds. This layer sits between the content/reputation events and the home/feed experiences.

8. User identity, author profiles, and moderation are handled in user/, oauth/, orcid/, invite/, organizations/, researchhub_access_group/, and related models. These apps cover signup/auth, ORCID linking, author claims, organizations, invite flows, permissions, risk scoring, and content moderation. External integrations here include OAuth/social login, ORCID, Persona verification, and organization-specific permissions.

9. Funding, transactions, and reputation form a separate financial subsystem. purchase/ handles grants, fundraises, balances, payment intents, and payment-provider integrations; reputation/ handles deposits, withdrawals, bounties, distributions, staking yield, and wallet logic. External payment/ledger integrations include Circle, Coinbase, Stripe, and Endaoment. This subsystem is heavily event-driven and tied to user balances and reward distribution.

10. Social interaction flows are modeled through discussion, comments, reactions, reviews, notes, notifications, and user interactions. discussion/, researchhub_comment/, review/, note/, notification/, and analytics/ each own pieces of the interaction graph. Many of these apps emit signals that feed feed updates, notifications, analytics events, and reputation changes.

11. AI-assisted features are isolated into research_ai/, ai_peer_review/, and some services in paper/, purchase/, and search/. These modules define prompts, LLM service wrappers, email generation, expert finding, proposal review, executive summaries, and RFP-related workflows. The AI boundary is clear: prompt templates and services encapsulate calls to external LLM providers such as Bedrock/OpenAI, then persist or render the generated output back into domain objects and emails.

12. Async and event processing is a cross-cutting backbone. Celery is used throughout for ingestion, indexing, email generation, reputation updates, risk-score backfills, and feed maintenance. Django signals are used heavily to react to model changes and enqueue downstream work. Redis is implied as the task/result/cache substrate from the devcontainer and Celery setup.

13. Analytics and behavioral syncing are handled separately from core product data. analytics/ ingests Amplitude webhooks and maps events into internal user_interactions records; personalize/ exports and syncs items/interactions to a recommendation backend. This creates a pipeline from user behavior → normalized events → recommendation and reporting services.

14. Infra and developer/runtime tooling matter to the architecture: the project runs on PostgreSQL, Redis, OpenSearch, Django ASGI/WSGI, and Celery workers/beat. There are devcontainer definitions, environment-specific config modules, many management commands for backfills and maintenance, and extensive test coverage per app, which supports a service-oriented monolith rather than a thin CRUD app.