|
2 | 2 | Infrastructure for E-democracy |
3 | 3 |    |
4 | 4 |
|
5 | | -Polis is a real-time system for gathering, analyzing and understanding |
6 | | -what large groups of people think in their own words, |
7 | | -enabled by advanced statistics and machine learning. |
| 5 | +## Overview |
8 | 6 |
|
9 | | -LitePolis is a Python-based, developer-friendly iteration of [Polis](https://github.com/compdemocracy/polis), |
10 | | -designed to provide a scalable and flexible platform for data scientists and developers. |
11 | | -Our goal is to make it easy to build and deploy data-driven applications giving more flexibility to the community. |
| 7 | +LitePolis is an advanced, Python-based infrastructure designed for building **customizable opinion collection systems**, extending beyond the capabilities of the original [Polis](https://github.com/compdemocracy/polis). It offers a **developer-friendly** environment focused on flexibility and power. |
12 | 8 |
|
13 | | -## TL;DR |
14 | | -* [Build Your First LitePolis API Router in 5 Minutes! 🚀](https://github.com/NewJerseyStyle/LitePolis/wiki/Tutorial:-Creating-New-LitePolis-Packages-with-litepolis%E2%80%90cli) |
15 | | -* [Example of database package](https://github.com/NewJerseyStyle/LitePolis-database-example) |
16 | | -* [Example of router package](https://github.com/NewJerseyStyle/LitePolis-router-example) |
| 9 | +Built with a modular, microservice-like architecture, LitePolis is **distributed by default**, leveraging the [Ray framework](https://www.ray.io/) for inherent **auto-scaling** capabilities right out of the box. This ensures your applications can handle large groups and high traffic volumes efficiently. |
17 | 10 |
|
18 | | -> ⚠️ The LitePolis is a complex system with this package manager to enable serve in cluster. Current stage is beta testing with developer while building more documents and testing middleware integration. |
| 11 | +The core of LitePolis is a central package manager that discovers and orchestrates various components – API Routers, Middleware, and UI Packages. This modularity allows developers and data scientists to easily build, deploy, and iterate on sophisticated data-driven e-democracy tools and other opinion-gathering applications. |
19 | 12 |
|
20 | | -## Overview |
| 13 | +## Getting Started: Develop to Deploy LitePolis App in 7 Steps\! |
| 14 | + |
| 15 | +This tutorial guides you through building and deploying a minimal LitePolis application, consisting of a simple API backend (a Router package). |
| 16 | + |
| 17 | +**Prerequisites:** |
| 18 | + |
| 19 | + * Python (3.8+ recommended) and pip installed. |
| 20 | + * Git installed. |
| 21 | + * Access to a running Ray Cluster. For local development, you can start one easily: |
| 22 | + ```bash |
| 23 | + pip install ray[serve] # Install Ray with the Serve component |
| 24 | + ray start --head --dashboard-host 0.0.0.0 # Start a local single-node cluster |
| 25 | + # Access the Ray Dashboard at http://127.0.0.1:8265 |
| 26 | + ``` |
| 27 | + *(Refer to [Ray Cluster Setup Docs](https://docs.ray.io/en/latest/cluster/getting-started.html) for more advanced setups like multi-node or Kubernetes)* |
| 28 | + |
| 29 | +### 1. Install the LitePolis CLI |
21 | 30 |
|
22 | | -LitePolis is a modular Python-based system, refactored from [Polis](https://github.com/compdemocracy/polis), designed for scalability and performance. It uses a microservice-like architecture for flexibility and integration. This repository acts as the central package manager, orchestrating the integration of various components for deployment. The package manager automatically discovers and manages routers (APIs), middleware, and UI packages, including dependency resolution. Database interactions are handled as a router (API). Future development will include Docker SDK support for managing dependencies like database servers. |
23 | | - |
24 | | -Routers and middleware can be developed independently in separate repositories and integrated during deployment based on the dependencies declared by UI packages. This allows for a highly modular and extensible system. |
25 | | - |
26 | | -```mermaid |
27 | | -graph TD |
28 | | - subgraph "Local Development Environment" |
29 | | - CLI[LitePolis CLI] |
30 | | - PM[Package Manager] |
31 | | - CF[Static Config File] |
32 | | - end |
33 | | -
|
34 | | - subgraph "Package Sources" |
35 | | - PYPI[PyPI Repository] |
36 | | - GH[GitHub Templates] |
37 | | - end |
38 | | -
|
39 | | - subgraph "Ray Cluster Deployment" |
40 | | - RAY[Ray Cluster] |
41 | | - SERVE[Ray Serve] |
42 | | - MON[Ray Dashboard/Monitoring] |
43 | | - |
44 | | - subgraph "Application Components" |
45 | | - API[FastAPI Application] |
46 | | - R[Router Services] |
47 | | - M[Middleware Services] |
48 | | - UI[UI Static Files] |
49 | | - end |
50 | | - end |
51 | | -
|
52 | | - subgraph "Database Layer" |
53 | | - SR[(StarRocks Data Lakehouse)] |
54 | | - end |
55 | | -
|
56 | | - CLI -->|User Commands| PM |
57 | | - PM -->|Read/Write| CF |
58 | | - PM -->|Install Dependencies| PYPI |
59 | | - |
60 | | - PM -->|Deploy Application| SERVE |
61 | | - SERVE -->|Run| API |
62 | | - API -->|Include| R |
63 | | - API -->|Apply| M |
64 | | - API -->|Serve| UI |
65 | | - |
66 | | - R <-->|Query/Store Data| SR |
67 | | - |
68 | | - RAY -->|Monitor| MON |
69 | | - SERVE -.->|Part of| RAY |
| 31 | +The `litepolis-cli` is your main tool for creating, managing, and deploying LitePolis packages. |
| 32 | + |
| 33 | +```bash |
| 34 | +pip install litepolis |
| 35 | +# Verify installation |
| 36 | +litepolis --version |
70 | 37 | ``` |
71 | 38 |
|
72 | | -**Routers, UI Packages, and Middlewares** |
73 | | - |
74 | | -In LitePolis, these components play distinct roles, though their relationship to traditional MVC might not be a direct mapping due to the distributed nature of the system: |
75 | | - |
76 | | -* **Routers (APIs):** These are analogous to *Controllers* in a traditional MVC framework. They define the endpoints and logic for handling incoming requests and returning responses. They act as the entry point for all interactions with the system. A database interaction is handled *through* a router, meaning a dedicated router is responsible for communicating with the database. The database itself, along with the data processing logic, represents the *Model* in this context. |
77 | | - |
78 | | -* **UI Packages:** These are closer to the *View* component of MVC. They consume the APIs exposed by the routers to present data and interact with the user. While they might contain some control logic, their primary function is to render the user interface and handle user interactions. They then communicate these interactions back to the routers. |
79 | | - |
80 | | -* **Middlewares:** These components sit between the routers and the UI, acting as intermediaries. They handle cross-cutting concerns like authentication, authorization, logging, and rate limiting. They are not directly tied to the MVC paradigm but are essential for managing access control, security, and other system-wide functionalities. Thinking of them as handling access control is a reasonable simplification. |
81 | | - |
82 | | -```mermaid |
83 | | -graph TD |
84 | | - subgraph "LitePolis Core" |
85 | | - PM[Package Manager] --> DP[Dependency Resolution] |
86 | | - PM --> CP[Component Discovery] |
87 | | - PM --> ORC[Orchestration] |
88 | | - end |
89 | | -
|
90 | | - subgraph "Component Types" |
91 | | - R[Routers/APIs] --> RA[API Endpoints] |
92 | | - R --> RC[Request Handling] |
93 | | - R --> RDB[Database Access Router] |
94 | | - |
95 | | - M[Middlewares] --> MA[Authentication] |
96 | | - M --> MB[Authorization] |
97 | | - M --> MC[Logging] |
98 | | - M --> MD[Rate Limiting] |
99 | | - |
100 | | - UI[UI Packages] --> UIA[Static Files] |
101 | | - UI --> UIB[User Interface] |
102 | | - end |
103 | | -
|
104 | | - PM --> R |
105 | | - PM --> M |
106 | | - PM --> UI |
107 | | - |
108 | | - R --> RDB |
109 | | - RDB -.-> DK[Docker Containers] |
110 | | - |
111 | | - UI --> DPC[Dependencies Declaration] |
112 | | - DPC --> PM |
| 39 | +### 2. Create Your First API Router Package |
| 40 | + |
| 41 | +API Routers handle backend logic and data requests. Let's create a simple "hello world" router. |
| 42 | +
|
| 43 | +```bash |
| 44 | +# Use the CLI to bootstrap a new router package |
| 45 | +litepolis create router litepolis-router-simple-api |
| 46 | +
|
| 47 | +# Navigate into the new directory |
| 48 | +cd litepolis-router-simple-api |
113 | 49 | ``` |
114 | 50 |
|
115 | | -**Scalability and Infrastructure** |
| 51 | +This command creates a standard Python package structure. Look inside `litepolis_router_simple_api/main.py` (or similar). It will contain boilerplate code using FastAPI. Let's make sure it has a basic endpoint: |
116 | 52 |
|
117 | | -LitePolis is designed for scalability and can handle high-volume usage through horizontal scaling: |
| 53 | +```python |
| 54 | +# litepolis_router_simple_api/main.py (ensure/modify it looks like this) |
| 55 | +from fastapi import APIRouter |
118 | 56 |
|
119 | | -* **Routers/APIs (Controllers):** Multiple instances of the API servers can be deployed and managed by a load balancer to distribute traffic and ensure high availability. LitePolis support autoscaling on cloud platforms like Google Cloud out-of-box. |
120 | | -* **UI Packages (Views):** Static files for the UI can be served from a content delivery network (CDN) to minimize latency and improve performance. The UI itself can be designed to be stateless, allowing for easy horizontal scaling of the application servers. |
121 | | -* **Model (Database and Data Processing):** LitePolis leverages distributed databases and data processing systems (like [StarRocks on Kubernetes](https://github.com/StarRocks/starrocks-kubernetes-operator/tree/main/examples/starrocks)) that can scale horizontally to handle increasing data volumes and query loads. |
| 57 | +router = APIRouter() |
122 | 58 |
|
123 | | -This distributed architecture, combined with cloud infrastructure and autoscaling, allows LitePolis to adapt to varying levels of demand and maintain performance even under heavy load, enabling nation-wide high-volume usage. |
| 59 | +@router.get("/hello") |
| 60 | +async def read_root(): |
| 61 | + return {"message": "Hello from my-simple-api!"} |
124 | 62 |
|
125 | | -```mermaid |
126 | | -graph TD |
127 | | - subgraph "Scalability" |
128 | | - SCALE[Scalable Architecture] --> LB[Load Balancing] |
129 | | - SCALE --> CDN[Content Delivery Network] |
130 | | - SCALE --> DB[Distributed Database] |
131 | | - SCALE --> AS[Auto Scaling] |
132 | | - end |
| 63 | +# LitePolis package manager will discover this 'router' object |
133 | 64 | ``` |
134 | 65 |
|
135 | | -## Conclusion |
136 | | - |
137 | | -This flexible architecture, coupled with a central package manager, simplifies the development process. Developers can focus on building their applications (routers, middleware, UI) while LitePolis handles the underlying infrastructure for scalability and performance. This separation of concerns allows for rapid development and deployment of new features and functionalities. |
138 | | - |
139 | | - |
140 | | - |
141 | | - |
142 | | -# TODOs |
143 | | -## Features |
144 | | - |
145 | | -* [ ] **Real-time Sentiment Gathering:** Polis gathers and analyzes opinions from large groups of people in real-time. |
146 | | -* [ ] **Open-Ended Feedback:** Participants can express their views in their own words, going beyond simple surveys or polls. |
147 | | -* [ ] **Anonymous Participation:** Participants can contribute anonymously, fostering open and honest dialogue. |
148 | | -* [ ] **Voting Mechanism:** Participants can vote on statements submitted by others, indicating agreement, disagreement, or neutrality. |
149 | | -* [ ] **Advanced Statistical Analysis:** Polis uses machine learning algorithms to identify consensus statements, divisive statements, and patterns in opinions. |
150 | | -* [ ] **Data Visualization and Reporting:** The platform provides real-time data visualization and reporting tools to understand the results of the conversation. |
151 | | -* [ ] **Moderation Tools:** Moderators can manage the conversation, address spam, and ensure a productive environment. |
152 | | -* [ ] **Scalability:** The platform can handle large-scale conversations with many participants. |
153 | | - |
154 | | -**Core Functionality:** |
155 | | - |
156 | | -* **User Interface:** |
157 | | - * [ ] User registration and authentication. |
158 | | - * [ ] Interface for creating and joining conversations. |
159 | | - * [ ] Interface for submitting statements and voting on them. |
160 | | - * [ ] Interface for viewing conversation data and reports. |
161 | | - * [ ] User-friendly and intuitive design. |
162 | | -* **Backend System:** |
163 | | - * [ ] Database to store user data, conversation data, and voting data. |
164 | | - * [x] API for interacting with the frontend and other services. |
165 | | - * [ ] Secure and reliable infrastructure. |
166 | | - * [x] Scalable architecture to handle large volumes of data and users. |
167 | | -* **Machine Learning Algorithms:** |
168 | | - * [ ] Algorithms to analyze sentiment and identify consensus and divisive statements. |
169 | | - * [ ] Algorithms to personalize the user experience based on their voting history and interests. |
170 | | - * [ ] Algorithms to detect spam and inappropriate content. |
171 | | -* **Data Visualization and Reporting:** |
172 | | - * [ ] Real-time visualizations of conversation data, including sentiment trends, agreement maps, and key statements. |
173 | | - * [ ] Customizable reports and dashboards for analyzing data. |
174 | | - * [ ] Ability to export data in various formats. |
175 | | -* **Moderation Tools:** |
176 | | - * [ ] Tools for managing user accounts and roles. |
177 | | - * [ ] Tools for flagging and removing inappropriate content. |
178 | | - * [ ] Tools for moderating discussions and resolving conflicts. |
179 | | -* **Integration with Third-Party Services:** |
180 | | - * [ ] Integration with translation services for multilingual conversations. |
181 | | - * [ ] Integration with spam filtering services to prevent abuse. |
182 | | - * [ ] Integration with other platforms and tools for data analysis and visualization. |
183 | | -* **Security:** |
184 | | - * [ ] Compliance with relevant privacy regulations (e.g., GDPR). |
185 | | -* **Scalability:** |
186 | | - * [x] Ability to handle large numbers of users and conversations. |
187 | | - * [x] Scalable infrastructure to accommodate increasing demand. |
188 | | - * [ ] Performance optimization for efficient data processing. |
189 | | -* **Accessibility:** |
190 | | - * [ ] Accessible design for users with disabilities. |
191 | | - * [ ] Support for multiple languages and cultural contexts. |
192 | | -* **Documentation:** |
193 | | - * [ ] Comprehensive documentation for developers and users. |
194 | | - * [ ] Tutorials and guides to help users understand the platform. |
195 | | -* **Testing:** |
196 | | - * [ ] Thorough testing of all features and functionality. |
197 | | - * [x] Automated testing to ensure code quality and stability. |
198 | | - |
199 | | -## Getting started |
200 | | -Under development... |
201 | | -<!-- something about deployment and configuration --> |
202 | | -### Tryout |
203 | | -use all in one dockerfile |
204 | | -## Advanced usage |
205 | | -### Separate storage |
206 | | -https://www.starrocks.io/blog/four-simple-ways-to-deploy-starrocks |
207 | | -### Separate front end |
208 | | -disable `streamlit` |
209 | | -develop your own front end web/mobile/desktop application with RESTful API docs |
210 | | -### Product deployment |
211 | | -- MVC architecture |
212 | | -- Data lakehouse |
213 | | - - https://www.starrocks.io/blog/four-simple-ways-to-deploy-starrocks |
214 | | -- scaling |
215 | | - - scaling of UI |
216 | | - - scaling of API server |
217 | | - - scaling of database |
218 | | - |
219 | | -## Developer manual |
220 | | -### Tech stack |
221 | | -Relationship of containers |
222 | | -```mermaid |
223 | | - graph TD; |
224 | | - Streamlit-->|View|FastAPI; |
225 | | - FastAPI-->|Control|StarRocks; |
226 | | - StarRocks-->*storage; |
| 66 | + * **(Optional) Explore:** Check out the [Example Router Package](https://github.com/NewJerseyStyle/LitePolis-router-example) for more complex examples, including database interactions ([Example DB Package](https://github.com/NewJerseyStyle/LitePolis-database-example)). |
| 67 | + |
| 68 | +### 3. Prepare Your Packages for Deployment |
| 69 | + |
| 70 | +For the LitePolis CLI to find your local packages during deployment, you often need to install them in "editable" mode. |
| 71 | + |
| 72 | +```bash |
| 73 | +# In the litepolis-router-simple-api directory: |
| 74 | +pip install -e . |
227 | 75 | ``` |
228 | 76 |
|
229 | | -Data flows from UI to API and store in database |
230 | | -then been accessed by other UI widget through other API endpoints |
231 | | -```mermaid |
232 | | - graph TD; |
233 | | - Streamlit-input-->|input|FastAPI-C_UD; |
234 | | - FastAPI-C_UD-->|write-in|StarRocks; |
235 | | - StarRocks-->*storage; |
236 | | - *storage-->StarRocks; |
237 | | - StarRocks-->|read-out|FastAPI-_R__; |
238 | | - FastAPI-_R__-->|output|Streamlit-display; |
| 77 | +This makes your local package code importable by the LitePolis deployment process. |
| 78 | + |
| 79 | +### 4. Deploy to Ray\! |
| 80 | + |
| 81 | +Make sure your local Ray cluster is running (see Prerequisites). Now, use the LitePolis CLI to deploy your application based on the configuration file. |
| 82 | + |
| 83 | +```bash |
| 84 | +litepolis-cli deploy add-deps litepolis-router-simple-api |
| 85 | +litepolis-cli deploy serve |
239 | 86 | ``` |
240 | | -*storage: Such as Amazon S3, Google Cloud Storage, Azure Blob Storage, and other S3-compatible storage |
| 87 | + |
| 88 | +## Next Steps: |
| 89 | + |
| 90 | + * Explore the [Example UI](https://github.com/NewJerseyStyle/LitePolis-ui-example) and [Example Router](https://github.com/NewJerseyStyle/LitePolis-router-example) repositories in more detail. |
| 91 | + * Try adding a **Middleware** package (`litepolis create middleware ...`) for things like logging or authentication. |
| 92 | + * Learn more about configuring **auto-scaling**, replicas, and other deployment options in your `deploy.yaml` or via CLI arguments (refer to LitePolis documentation). |
| 93 | + * Integrate a database using a dedicated router package (see the [Database Example](https://github.com/NewJerseyStyle/LitePolis-database-example)). |
| 94 | + |
| 95 | +## Deployment & Maintenance Strengths |
| 96 | + |
| 97 | +While the tutorial covers the *how*, remember the key *why*s for using LitePolis, especially for administrators: |
| 98 | + |
| 99 | + * **Default Auto-Scaling:** Ray Serve automatically scales API replicas based on traffic. |
| 100 | + * **Modular Feature Addition:** Add functionality by adding package dependencies and redeploying. |
| 101 | + * **Simplified Orchestration:** The `litepolis` tool manages component discovery and dependency resolution. |
| 102 | + * **Resilience:** Ray provides fault tolerance for running components. |
| 103 | + * **Cloud Native:** Runs effectively on Kubernetes and cloud platforms. |
0 commit comments