CARULY / TECHNICAL REPORT
Caruly — Technology Choices
Why the current stack was chosen and when it should change.
1. Node Http Server
Back to contents ↑The application uses built-in Node HTTP, filesystem and crypto APIs. package.json currently allows Node >=22.18.0 for built-in SQLite support. The server has no external runtime package dependencies. This keeps installation small, but routing, errors, limits and security headers are maintained manually. Pin and test a production runtime version as operations mature.
2. Plain Html, Css And Javascript
Back to contents ↑The current interface is one large index.html with hash-based navigation. This enabled rapid iteration without a build pipeline. Its growing size and shared mutable state increase maintenance risk. Splitting pages, reusable components and state logic into modules is a likely next step. There is no React application in this repository.
3. Sqlite
Back to contents ↑SQLite was selected for a single-instance, low-cost prototype. It stores structured draft data while photos remain ordinary files. WAL mode and parameterized queries are used. This is suitable for the current deployment shape; independent replicas cannot safely share this setup as if it were a managed network database. Consider managed PostgreSQL as concurrent workloads and multi-instance needs grow.
4. Render Persistent Disk
Back to contents ↑A 5 GB mounted disk keeps SQLite and photo files across deploys. The ordinary ephemeral application filesystem must not hold production uploads. The disk cost recorded when provisioned was $1.25/month in addition to the existing $7 service; this is a historical configuration note, not a current pricing guarantee. Confirm billing in Render before changing resources.
5. File Storage
Back to contents ↑User image uploads accept JPG/JPEG, PNG and WebP up to 10 MiB. Photo capacity is capped at 4 GiB with a free-space reserve. A future object-storage service can provide independent capacity, lifecycle rules and better multi-instance support; the database should continue to hold metadata and ownership.
6. Document Library
Back to contents ↑Repository files plus a manifest were chosen for curated technical documentation. They are versioned with the app, require no new database tables, and can be downloaded on another computer once published. Text is portable; PDFs/images use browser previews; HTML runs in a restricted frame. Browser support determines which image and PDF formats render; unsupported formats retain a download option.
7. Demo Vs Production
Back to contents ↑The estimate, auction date and phone code are sample behavior. SMS provider choice was postponed. No paid provider, login identity platform, queue, email delivery service or pricing engine has been integrated. These choices remain open and must not be inferred from the UI alone.
8. Alternatives And Tradeoffs
Back to contents ↑Node with TypeScript: can improve compile-time checks and data contracts while retaining the current runtime and browser language. It adds build/configuration work; type annotations alone do not secure authentication.
React or Vue: may help reusable form components and navigation as the UI grows. They can use the existing Node APIs; a frontend framework does not require changing the database.
Python/Flask or Django: reasonable for a team with that expertise, but Caruly is not currently implemented in Python. A migration needs evidence of value and parity tests.
Java/Spring or C#/ASP.NET: possible organizational choices, with rewrite and deployment costs. Java and JavaScript are different languages; a Java backend still needs browser behavior. JSP is a server-side view technology, not a substitute for browser JavaScript.
PostgreSQL and object storage: address shared persistence and scaling separately from frontend or backend language choice. No equivalent implementation benchmark was run.
9. When To Reconsider
Back to contents ↑Measure concurrent listings, image volume, slow requests, memory, disk I/O and maintenance costs. Refactor a bottleneck before assuming a complete rewrite is necessary. The current recommendation is incremental structure and identity/storage improvements, based on this project's code and stage, not a universal ranking or an invented original design decision.
10. Sources And Maintenance
Back to contents ↑Prepared from the Caruly source tree and recorded development work on September 13, 2026. Reference report structure supplied by the owner. Update this snapshot when routes, schema, security, or deployment behavior changes. Do not copy unrelated project findings into this report.