ردیاب بودجه متن‌باز و خودمیزبان برای توسعه‌دهندگان: مالک واقعی داده‌های مالی خودتان باشید

اگر توسعه‌دهنده باشید، به احتمال زیاد داده‌های مالی‌تان روی سرور شخص دیگری قرار دارد. بیشتر برنامه‌های بودجه‌بندی و ثبت هزینه، از Mint و YNAB گرفته تا Copilot و Lunch Money، تراکنش‌ها، مانده‌حساب‌ها و الگوهای خرج‌کردن شما را در زیرساخت ابری خودشان نگه می‌دارند. در عمل باید به آن‌ها اعتماد کنید که هک نشوند، داده‌هایتان را نفروشند و یک روز هم ناگهان تعطیل نکنند.

اگر با Docker و Postgres راحت هستید، راه بهتری هم وجود دارد: یک ردیاب بودجهٔ متن‌باز را خودتان میزبانی کنید و همه‌چیز را روی زیرساختی نگه دارید که مالک آن هستید.

ردیاب هزینهٔ متن‌بازی که خودتان اجرا می‌کنید

Expense Budget Tracker یک سامانهٔ کاملاً متن‌باز برای پیگیری هزینه و بودجه است که بر پایهٔ Postgres ساخته شده. مخزن را کلون می‌کنید، make up را اجرا می‌کنید و یک برنامهٔ آماده روی localhost:3000 در اختیار دارید؛ همراه با یک پایگاه دادهٔ واقعی که کنترلش دست خودتان است.

نه به ساختن حساب کاربری نیاز دارید، نه داده‌ای از دستگاه شما خارج می‌شود، نه خبری از حق اشتراک است. این پروژه با مجوز MIT منتشر شده؛ می‌توانید از آن fork بگیرید، تغییرش دهید و هر طور می‌خواهید از آن استفاده کنید.

پشتهٔ فنی آن هم سرراست است: Next.js برای رابط وب، Postgres 18 برای ذخیره‌سازی، و یک فرایند پس‌زمینهٔ TypeScript برای دریافت روزانهٔ نرخ ارز. همه‌چیز از طریق یک docker-compose.yml واحد داخل کانتینرهای Docker اجرا می‌شود.

با Docker خودتان میزبانی کنید یا روی AWS مستقر کنید

این مخزن از همان ابتدا دو روش استقرار آماده دارد:

Docker Compose محلی: با چهار دستور کار راه می‌افتد:

git clone https://github.com/kirill-markin/expense-budget-tracker.git
cd expense-budget-tracker
open -a Docker   # start Docker if not running
make up          # Postgres + migrations + web + worker

http://localhost:3000 را باز کنید و اولین تراکنش را وارد کنید. داده‌های Postgres در فضای ذخیره‌سازی پایدار Docker ماندگار می‌شوند. کل راه‌اندازی همین‌قدر ساده است.

AWS CDK: یک استقرار کاملِ آمادهٔ تولید با یک اسکریپت:

bash scripts/bootstrap.sh --region eu-central-1

این اسکریپت ECS Fargate، RDS Postgres، یک ALB با HTTPS، سرویس Cognito برای احراز هویت، WAF، پایش CloudWatch، پشتیبان‌گیری خودکار و CI/CD از طریق GitHub Actions را بالا می‌آورد. هزینهٔ تقریبی آن حدود ۵۰ دلار در ماه است و در عوض زیرساختی در سطح سازمانی دارید که کاملاً در اختیار خودتان است. راهنمای استقرار هم همه‌چیز را قدم‌به‌قدم توضیح می‌دهد؛ از ساختن حساب AWS تا تنظیم DNS در Cloudflare.

از آنجا که هستهٔ کار فقط Postgres و Docker است، می‌توانید آن را تقریباً هر جای دیگری هم خودتان میزبانی کنید: DigitalOcean، Hetzner، یک Raspberry Pi در انباری خانه یا کلاستر Kubernetes شرکت‌تان. هر جا Docker و Postgres اجرا شود، این هم اجرا می‌شود.

درگاه SQL API برای دسترسی برنامه‌نویسی

بیشتر برنامه‌های بودجه‌بندی فقط یک رابط وب در اختیارتان می‌گذارند و تمام. این پروژه یک API برای اجرای پرس‌وجوهای SQL روی HTTP ارائه می‌کند: مسیر POST /v1/sql که دستورهای خام SQL را می‌گیرد و خروجی JSON برمی‌گرداند.

curl -X POST https://api.your-domain.com/v1/sql \
  -H "Authorization: ApiKey ebta_a7Bk9mNp..." \
  -H "X-Workspace-Id: workspace-id" \
  -H "Content-Type: application/json" \
  -d '{"sql": "SELECT category, SUM(amount) AS total FROM ledger_entries WHERE kind = '\''spend'\'' AND ts >= DATE_TRUNC('\''month'\'', CURRENT_DATE) GROUP BY category ORDER BY total"}'

در بخش تنظیمات یک کلید API می‌سازید، شناسهٔ فضای کاری هدف را انتخاب می‌کنید و بعد هر برنامه‌ای که بتواند درخواست HTTP بفرستد، می‌تواند داده‌های شما را پرس‌وجو کند. این فقط یک مسیر REST ساده است؛ نه GraphQL، نه لایه‌های انتزاعی ORM، نه SDK تازه‌ای که مجبور باشید یاد بگیرید. فقط SQL وارد می‌شود و JSON برمی‌گردد.

مدل امنیتی هم سخت‌گیرانه است: کلیدهای API به‌صورت چکیدهٔ SHA-256 ذخیره می‌شوند و نسخهٔ متن‌واضح آن‌ها اصلاً نگه‌داری نمی‌شود. پرس‌وجوها فقط به SELECT، INSERT، UPDATE و DELETE محدود هستند، برای هر دستور مهلت ۳۰ ثانیه‌ای در نظر گرفته شده، هر پاسخ حداکثر ۱۰۰ ردیف دارد و برای هر کلید محدودیت ۱۰ درخواست در ثانیه اعمال می‌شود. همهٔ پرس‌وجوها هم از Row Level Security در Postgres عبور می‌کنند؛ همان سازوکار جداسازی‌ای که رابط وب از آن استفاده می‌کند. در نتیجه هر کلید API فقط به داده‌های فضای کاری مالک خودش دسترسی دارد.

برای عامل‌های هوش مصنوعی و LLMها ساخته شده

همین SQL API است که استفادهٔ عملی از هوش مصنوعی در امور مالی شخصی را ممکن می‌کند، چون عامل شما برای خواندن و نوشتن داده‌های مالی به دسترسی مستقیم به پایگاه داده نیاز دارد.

به نحوهٔ استفاده‌تان از دستیارهای هوش مصنوعی امروز فکر کنید. یک تصویر از صورت‌حساب بانکی را داخل Claude یا ChatGPT می‌اندازید، از آن می‌خواهید هزینه‌ها را دسته‌بندی کند و یک خلاصهٔ تمیز تحویل می‌گیرید. بعد باید همان عددها را دستی وارد ابزار اصلی‌تان کنید. این گردش کار متعلق به ۲۰۲۳ است.

با SQL API، عامل هوش مصنوعی فقط داده را تحلیل نمی‌کند؛ بلکه مستقیماً در پایگاه دادهٔ شما می‌نویسد. روند کار به این شکل در می‌آید:

1. یک صورت‌حساب بانکی، فایل CSV، PDF یا تصویر را به عامل بدهید.
2. عامل هر تراکنش را می‌خواند، آن را با دسته‌بندی‌های موجود شما تطبیق می‌دهد و با INSERT در ledger_entries ثبت می‌کند.
3. عامل ماندهٔ حساب شما را با عدد اعلام‌شده از سمت بانک مقایسه می‌کند.
4. شما به‌جای یک ساعت ورود دستی اطلاعات، فقط چند دقیقه برای بازبینی وقت می‌گذارید.

طرح پایگاه داده هم دقیقاً برای همین سناریو طراحی شده است: هفت جدول تخت، بدون JSON تو‌در‌تو و بدون joinهای پیچیده برای کارهای روزمره. جدول ledger_entries عمداً ساده نگه داشته شده؛ برای هر جابه‌جایی پول یک ردیف و نام ستون‌هایی که روشن و قابل حدس هستند. به همین دلیل یک LLM معمولاً از همان بار اول می‌تواند دستورهای INSERT درست بنویسد.

Expense Budget Tracker یک چت داخلی هوش مصنوعی هم در رابط وب دارد. کلید API مربوط به OpenAI یا Anthropic را وصل می‌کنید و دستیار به ابزار query_database دسترسی پیدا می‌کند؛ یعنی می‌تواند مستقیماً روی Postgres شما SELECT، INSERT، UPDATE و DELETE اجرا کند. کافی است تصویری از برنامهٔ بانکی‌تان بارگذاری کنید تا هوش مصنوعی تراکنش‌ها را استخراج کند، از شما تأیید بگیرد و آن‌ها را ثبت کند. این فرایند هم پروتکل سخت‌گیرانه‌ای دارد: اول دسته‌بندی‌های موجود شما را پیدا می‌کند، دنبال موارد تکراری می‌گردد، مانده‌ها را می‌سنجد و فقط بعد از تأیید صریح شما چیزی می‌نویسد.

این چت از مدل‌های Claude و GPT پشتیبانی می‌کند. هر دو از همان ابزار پایگاه داده و همان قواعد امنیتی استفاده می‌کنند: فهرست سفید واژه‌های مجاز، مهلت زمانی برای دستورها و اجرای اجباری RLS. از طرف دیگر می‌توانید همین SQL API را به هر عامل بیرونی هم وصل کنید: Claude Code، OpenAI Codex، اسکریپت‌های سفارشی یا وب‌هوک‌های Zapier. کافی است کلید API با پیشوند ebt_ را به عامل بدهید و آدرس درگاه را مشخص کنید؛ از همان لحظه به خواندن و نوشتن داده‌ها در محدودهٔ فضای کاری خودش دسترسی دارد.

قابلیت‌های ردیاب بودجه

این پروژه فقط یک دفتر کل ساده برای ثبت هزینه‌ها نیست. بیشتر قابلیت‌هایی که از یک محصول تجاری انتظار دارید، همین‌جا وجود دارند:

• جدول بودجه: ردیف‌ها دسته‌بندی‌ها هستند و ستون‌ها ماه‌ها. ماه‌های گذشته ارقام واقعی را نشان می‌دهند و ماه‌های آینده پیش‌بینی شما را. می‌توانید ۱۲ ماه جلوتر برنامه‌ریزی کنید و مانده‌های پیش‌بینی‌شده را یک‌جا ببینید.
• پشتیبانی چندارزی: هر تراکنش با ارز اصلی خودش ذخیره می‌شود. نرخ‌های روزانه از ECB، CBR و NBS به‌صورت خودکار دریافت می‌شوند. تبدیل به ارز گزارش‌گیری در زمان پرس‌وجو و با joinهای SQL انجام می‌شود؛ نه با ستون‌های از پیش محاسبه‌شده و نه با افت دقت.
• مانده‌حساب‌ها: حساب جاری، پس‌انداز، کارت اعتباری، وجه نقد و سرمایه‌گذاری را دنبال می‌کنید. ماندهٔ هر حساب از روی دفتر کل محاسبه می‌شود.
• انتقال بین حساب‌ها: می‌توانید پول را بین حساب‌های خودتان، حتی بین ارزهای مختلف، جابه‌جا کنید. این انتقال با دو سطر در دفتر کل و یک event_id مشترک ثبت می‌شود؛ یکی منفی و یکی مثبت.
• دسته‌بندی تراکنش‌ها: دسته‌بندی‌ها را خودتان تعریف می‌کنید و مجبور به پیروی از یک طبقه‌بندی از پیش تعیین‌شده نیستید. هوش مصنوعی هم دسته‌بندی‌های شما را از روی داده‌های قبلی یاد می‌گیرد.
• رابط چندزبانه: انگلیسی، اسپانیایی، چینی، عربی، عبری، فارسی، اوکراینی و روسی را پشتیبانی می‌کند و از RTL هم به‌طور کامل پشتیبانی می‌شود.
• جداسازی فضای کاری: Row Level Security در Postgres دادهٔ هر کاربر را کاملاً جدا نگه می‌دارد. حتی اگر همه روی یک پایگاه داده باشند، هیچ‌کس دادهٔ دیگری را نمی‌بیند.
• حالت نمایشی: با یک دکمه در رابط می‌توانید به دادهٔ نمونهٔ درون‌حافظه‌ای جابه‌جا شوید و بدون پایگاه داده هم رابط را امتحان کنید.

طرح Postgres که برای توسعه‌دهنده‌ها ساخته شده

کل طرح پایگاه داده در ذهن جا می‌گیرد:

• ledger_entries: یک سطر برای هر جابه‌جایی پول
• budget_lines: برنامهٔ بودجه با ثبت صرفاً افزایشی
• budget_comments: یادداشت‌های سلول‌های بودجه
• exchange_rates: نرخ‌های روزانهٔ ارز
• workspace_settings: ارز گزارش‌گیری هر فضای کاری
• account_metadata: طبقه‌بندی نقدشوندگی
• accounts: یک VIEW مشتق‌شده از ledger_entries

نه ORM، نه چارچوب پیچیدهٔ مهاجرت. فقط فایل‌های SQL شماره‌دار در db/migrations/ که با یک اسکریپت شل اعمال می‌شوند. می‌توانید تک‌تک مهاجرت‌ها را بخوانید، جدول‌ها را بفهمید و مستقیم روی همان طرح، پرس‌وجوی دلخواه‌تان را بنویسید.

تغییرات ساختار پایگاه داده از مسیر مهاجرت‌ها انجام می‌شوند. نقش app که رابط وب از آن استفاده می‌کند دسترسی محدودی دارد و نمی‌تواند جدول تازه بسازد یا ساختار را تغییر دهد. نقش tracker هم که فقط برای اجرای اسکریپت مهاجرت به کار می‌رود، مسئول DDL است. این همان تفکیک مسئولیتی است که از یک سامانهٔ آمادهٔ تولید انتظار دارید.

چرا توسعه‌دهنده‌ها داده‌های مالی‌شان را خودشان میزبانی می‌کنند

شما از قبل مهارت اجرای چنین پشته‌ای را دارید. Docker، Postgres و AWS را می‌شناسید، یا هر زیرساخت ابری دیگری را که ترجیح بدهید. پرسش اصلی فقط این است که آیا این مزایا ارزش زحمتش را دارند یا نه.

مالکیت کامل داده: داده‌های مالی شخصی شما هیچ‌وقت از زیرساخت خودتان خارج نمی‌شوند. رخنه‌های امنیتی شرکت‌های ثالث مستقیماً روی شما اثر نمی‌گذارند. لازم نیست سیاست‌های حریم خصوصی طولانی را بخوانید. کسی هم الگوهای خرج‌کردن شما را برای تبلیغات نمی‌فروشد.

سفارشی‌سازی: می‌توانید به طرح پایگاه داده ستون اضافه کنید، با SQL خام گزارش‌های اختصاصی بسازید و آن را به ابزارهای فعلی‌تان وصل کنید. ربات تلگرام برای گزارش هزینهٔ روزانه می‌خواهید؟ یک اسکریپت بنویسید که SQL API را صدا بزند. می‌خواهید داده‌ها را در Grafana ببینید؟ مستقیم آن را به Postgres وصل کنید. کد کاملاً در اختیار شماست.

بدون وابستگی به فروشنده: اگر دیگر از رابط وب استفاده نکنید، داده‌های شما همچنان در یک پایگاه دادهٔ استاندارد Postgres باقی می‌مانند. می‌توانید با pg_dump از آن خروجی بگیرید، با هر ابزار SQL به آن پرس‌وجو بزنید یا کلاً به سامانهٔ دیگری مهاجرت کنید.

یادگیری: این کدبنیاد یک نمونهٔ واقعی از ترکیب Next.js، Postgres، Docker، AWS CDK، Row Level Security، احراز هویت با کلید API و یکپارچه‌سازی ابزارهای هوش مصنوعی است. اگر در حال ساخت یک محصول SaaS باشید، الگوهای زیادی برای استفاده در کار خودتان پیدا می‌کنید.

شروع کار با ردیاب بودجهٔ متن‌باز

git clone https://github.com/kirill-markin/expense-budget-tracker.git
cd expense-budget-tracker
make up

http://localhost:3000 را باز کنید. اولین تراکنش را وارد کنید. برای ماه جاری بودجه بنویسید. اگر می‌خواهید بدون پایگاه داده رابط را امتحان کنید، روی دکمهٔ Demo در سربرگ بزنید تا دادهٔ نمونهٔ درون‌حافظه‌ای فعال شود.

وقتی برای محیط تولید آماده شدید، راهنمای استقرار AWS را دنبال کنید یا تنظیمات Docker Compose را با زیرساخت خودتان سازگار کنید.

مخزن پروژه اینجاست: github.com/kirill-markin/expense-budget-tracker. اگر خوشتان آمد، می‌توانید آن را در GitHub به فهرست مخزن‌های ستاره‌دار خود اضافه کنید، از آن fork بگیرید یا فقط کد را بخوانید. پروژه با مجوز MIT منتشر شده و هر طور بخواهید می‌توانید از آن استفاده کنید.

اگر همین حالا هم برای کارتان سرور و پایگاه داده مدیریت می‌کنید، اجرای همین پشته برای امور مالی شخصی فقط یک قدم اضافه است؛ در عوض کنترل کامل داده‌ها دست خودتان می‌ماند.