pratikpandey994-dotcom/fx-terminal

1. Overall shape

This repo is a multi-runtime intelligence platform, not a single web app. The architecture is split across a Next.js 14 frontend/API layer, a Node.js worker for ingestion and computation, and a Python FastAPI pattern service for technical analog matching. Persistent state lives in PostgreSQL with pgvector and Redis.

2. User-facing application

The app/ and components/ trees implement the terminal-style UI and dashboard surfaces. The main experience is the research terminal under app/(dashboard)/terminal, with supporting dashboard panels and reusable terminal widgets in components/terminal and components/dashboard. This layer is primarily presentation, orchestration, and live data fetching.

3. API boundary

The app/api/ tree is the primary HTTP contract. It groups endpoints by domain: market, intelligence, bias, pattern, feed, knowledge, public, v1, plus health/ready and terminal bootstrap. These routes act as the boundary between the UI and the backend engines, normalizing responses and shielding the frontend from direct provider complexity.

4. Fundamental intelligence engine

The Node worker is the core computation plane for the “Engine 1” side of the product. Its jobs ingest and synthesize news, macro releases, central-bank communications, COT, positioning, sentiment, event risk, and narrative structure. The worker’s engine modules cover things like market structure, regime detection, funding stress, intermarket chains, positioning, risk sentiment, daily brief generation, and forecast/recommendation combining.

5. Technical pattern engine

“Engine 2” is isolated in services/pattern/, a separate Python service built around candle encoding, motif discovery, similarity search, and probability estimation. It stores and queries historical analogs using pgvector-backed similarity. The worker also contains pattern-related jobs for encoding, resolving, and backfilling candle episodes, which suggests a pipeline from raw price history to analog-based predictions.

6. Data ingestion layer

The worker is responsible for pulling from many external sources via provider adapters and scrapers: Alpha Vantage, BLS, CFTC, EIA, FRED, Finnhub, OANDA, Twelve Data, World Bank, ForexFactory, GDELT, SEC, RSS, Google News proxy, and others. There are dedicated jobs for macro, news, earnings, politician trades, source discovery, staleness checks, and feed promotion. This is the main ingress path into the platform.

7. Persistence and indexing

prisma/schema.prisma and the large migration history show that PostgreSQL is the system of record for users, layouts, market snapshots, intelligence artifacts, knowledge documents, alerts, and pattern data. pgvector is used for semantic or analog retrieval. Redis is used as a shared cache/tiered-speed layer for worker and API paths, with additional edge/cache helpers in the app code.

8. Knowledge and retrieval subsystem

The platform has a separate knowledge-corpus pipeline: embeddings, chunking, hybrid retrieval, taxonomy classification, entity linking, and search. The services/search/ microservice handles discovery and retrieval across sources using DuckDuckGo/SearxNG-style engines plus LLM-assisted ranking. This subsystem feeds the intelligence layer rather than serving as a user-facing search product.

9. Alerts and external delivery

The system is not a trading bot, but it does produce outbound intelligence via Telegram and automation hooks. lib/telegram and worker/src/telegram-notify.ts indicate alert generation, while services/telegram/ and app/api/n8n/ingest connect to external ingestion/automation flows. A Google Drive cold-storage path is also part of the operational data lifecycle.

10. AI and model integration

Both app and worker have AI client wrappers for Gemini and Groq. These are used for enrichment, summarization, narrative synthesis, and likely retrieval-augmented reasoning. The AI layer sits above raw data ingestion and below the UI, and is used to turn market facts into explainable intelligence outputs.

11. Operational architecture

Deployment is centered on Railway for the app and worker, with a separate Oracle Cloud n8n automation environment. Dockerfiles, GitHub Actions, Sentry configs, health/ready routes, and docker-compose.yml show that the repo is designed for containerized deployment with explicit observability and environment separation. There is also a strong runbook/docs culture around operations.

12. Primary data flow

The typical flow is: external providers and scrapers → worker jobs → Postgres/Redis → API routes → terminal/dashboard UI. For pattern analysis, the flow is: historical candles → Python pattern service and/or worker encoding jobs → vector similarity/probability outputs → API/UI panels. The platform’s architecture is therefore a two-engine intelligence pipeline with shared storage and a thin presentation layer on top.