docs: update README tech stack to reflect current implementation#16
Conversation
|
Warning Review limit reached
Next review available in: 7 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR refreshes the README to match the current project stack. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (1): Last reviewed commit: "docs: update README tech stack to reflec..." | Re-trigger Greptile |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the README.md to document several major architectural enhancements, including edge analytics with DuckDB-WASM, hybrid RAG using in-browser ONNX embeddings, LiteLLM fallback integration, tree-shaken Apache ECharts, and a migration to Tailwind CSS 4 native CSS Grid. The review feedback highlights a few documentation inconsistencies and redundancies, specifically suggesting the removal of vector databases from the vector embeddings list, removing the redundant backend listing of DuckDB-WASM, and unifying references to the ECharts tree-shaking library.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| - **Self-hosted LLMs**: vLLM, Hugging Face TGI | ||
| - **Vector Embeddings**: Chroma, Qdrant | ||
| - **Model Tracking**: MLflow, Weights & Biases | ||
| - **Vector Embeddings**: Chroma, Qdrant, sentence-transformers |
There was a problem hiding this comment.
Chroma and Qdrant are vector databases, not vector embeddings. Since they are already correctly listed under Backend & Data Processing as Vector Databases (line 38), they should be removed from this list to avoid confusion.
| - **Vector Embeddings**: Chroma, Qdrant, sentence-transformers | |
| - **Vector Embeddings**: sentence-transformers |
| - DuckDB (primary analytical engine — English-to-SQL, larger-than-memory analytics, PostgreSQL direct-attach) | ||
| - DuckDB-WASM (edge analytics in browser web worker for local filter/sort/aggregation) | ||
| - Apache Arrow + PyArrow (zero-copy interchange and IPC streaming from DuckDB to the UI/LLM) |
There was a problem hiding this comment.
DuckDB-WASM is a client-side technology running entirely in the browser's WebAssembly environment. Since it is already listed under Frontend & UI (line 26), listing it under Backend & Data Processing is redundant and may confuse readers about where the processing actually occurs.
| - DuckDB (primary analytical engine — English-to-SQL, larger-than-memory analytics, PostgreSQL direct-attach) | |
| - DuckDB-WASM (edge analytics in browser web worker for local filter/sort/aggregation) | |
| - Apache Arrow + PyArrow (zero-copy interchange and IPC streaming from DuckDB to the UI/LLM) | |
| - DuckDB (primary analytical engine — English-to-SQL, larger-than-memory analytics, PostgreSQL direct-attach) | |
| - Apache Arrow + PyArrow (zero-copy interchange and IPC streaming from DuckDB to the UI/LLM) |
| * **Zustand Store:** `src/store/dashboardStore.ts` is the single source of truth for widgets, ordering, telemetry, summaries, and status. | ||
| * **Code-Splitting:** Apache ECharts (~1MB) and the React Flow (D3) pipeline are loaded on demand via `React.lazy` (`src/components/charts/LazyCharts.tsx`), keeping the baseline bundle lean. | ||
| * **Native CSS Grid:** Dashboard canvas migrated to a native CSS Grid (`gridify-canvas` / `gridify-col-N`) driven by Tailwind 4 `@theme` tokens. Widget spans come from each widget's column count; reflow is handled by the browser grid engine. | ||
| * **Code-Splitting:** Apache ECharts (~1 MB monolithic) is now tree-shaken via `echarts-for-react/lib/core` importing only Line/Bar/Scatter/Heatmap/Treemap charts plus Grid/Tooltip/VisualMap and Canvas renderer, cutting the chunk to ~594 KB (gzip 199 KB). React Flow (D3) pipeline is also loaded on demand via `React.lazy` (`src/components/charts/LazyCharts.tsx`). |
There was a problem hiding this comment.
There is an inconsistency in how the ECharts tree-shaking is described. Here on line 274, it mentions echarts-for-react/lib/core, but on line 21, it mentions echarts/core. It would be better to unify these references to avoid confusion.
1 participant
No description provided.