Feat/docs and branding - #37
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe PR removes monolithic API_USAGE and DEVLOG docs, adds a modular docs/ set (introduction, getting-started, authentication, database, storage, api-reference, security), updates README/SUMMARY and landing page branding/colors, replaces icon+text logos with a single Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant StorageCtrl as StorageController
participant ProjectModel as Project Model (MongoDB)
participant StorageProv as Storage Provider
Client->>StorageCtrl: POST /api/storage/upload (multipart, x-api-key)
StorageCtrl->>ProjectModel: Project.updateOne($inc used to adjust usage)
ProjectModel-->>StorageCtrl: update result
StorageCtrl->>StorageProv: upload file stream
StorageProv-->>StorageCtrl: upload success + file URL/size
StorageCtrl->>ProjectModel: Project.updateOne($set provider/status fields if needed)
ProjectModel-->>StorageCtrl: update result
StorageCtrl-->>Client: 201 Created + {url, path, size}
sequenceDiagram
participant Client as Client
participant ProjectCtrl as ProjectController
participant ProjectModel as Project Model (MongoDB)
participant Validator as Schema Validator
Client->>ProjectCtrl: POST /api/project/:id/toggleAuth (enable)
ProjectCtrl->>ProjectModel: find project, check for existing 'users' collection
alt users collection exists
ProjectCtrl->>Validator: validateUsersSchema(existingModel)
Validator-->>ProjectCtrl: valid / invalid
alt valid
ProjectCtrl->>ProjectModel: update isAuthEnabled = true
ProjectCtrl-->>Client: 200 OK
else invalid
ProjectCtrl-->>Client: 422 Unprocessable Entity
end
else users collection missing
ProjectCtrl-->>Client: 422 Unprocessable Entity (no auto-creation)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~35 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the user experience by introducing a comprehensive and well-structured documentation system, making it easier for developers to understand and utilize the urBackend API. Concurrently, it refreshes the project's visual identity and core messaging across the frontend, aligning the brand with its updated value proposition of flexibility and speed. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![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 significantly refactors the project's documentation and updates frontend branding. The previous API_USAGE.md has been replaced with a new, structured docs directory, including detailed guides on authentication, database operations, cloud storage, security, and an API quick reference, along with an introduction and getting started guide. Concurrently, the frontend has been updated to reflect new branding, changing the primary color scheme, updating hero section taglines, and replacing old logo assets with a new official logo across various components like the footer, main layout, sidebar, and landing page navigation. Review comments highlight several areas for improvement in the new documentation, including defining an undefined variable in a code example, adding a missing heading in the 'Getting Started' section, correcting a duplicated heading and a grammatical error in the 'Introduction', and suggesting a more web-friendly filename for the new logo asset. Additionally, a general suggestion was made to move inline styles to CSS files for better maintainability in the LandingPage component.
| <Database size={24} color="var(--color-primary)" /> | ||
| <span style={{ fontSize: '1.2rem', fontWeight: 700, color: '#fff' }}>urBackend</span> | ||
| <div style={{ display: 'flex', alignItems: 'center', marginBottom: '1rem' }}> | ||
| <img src="/urBACKEND_NAV_LOGO (2).png" alt="urBackend Logo" style={{ height: '80px', width: 'auto' }} /> |
There was a problem hiding this comment.
The filename urBACKEND_NAV_LOGO (2).png contains spaces and parentheses, which can cause issues with some tools and are not ideal for web assets. It's best practice to use web-friendly names (e.g., kebab-case, no special characters). Consider renaming the file to something like urbackend-nav-logo.png and updating all references to it.
| <img src="/urBACKEND_NAV_LOGO (2).png" alt="urBackend Logo" style={{ height: '80px', width: 'auto' }} /> | |
| <img src="/urbackend-nav-logo.png" alt="urBackend Logo" style={{ height: '80px', width: 'auto' }} /> |
| @@ -284,7 +283,7 @@ function LandingPage() { | |||
| </div> | |||
|
|
|||
| <div id="features" style={{ padding: '8rem 0', background: '#030303', borderTop: '1px solid rgba(255, 255, 255, 0.05)', position: 'relative', overflow: 'hidden' }}> | |||
There was a problem hiding this comment.
This component uses a lot of inline styles. While it works, it makes the code harder to maintain and read. For better separation of concerns and reusability, consider moving these styles to the corresponding style.css file and using CSS classes.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (1)
docs/api-reference.md (1)
8-12: Use one placeholder name for the data routes across the docs.This file uses
:col, whiledocs/database.mduses:collectionNamefor the same endpoints. Keeping one name avoids needless confusion.Proposed doc fix
-| **Data** | `GET` | `/api/data/:col` | Get all documents in collection | -| **Data** | `GET` | `/api/data/:col/:id` | Get document by ID | -| **Data** | `POST` | `/api/data/:col` | Insert new document | -| **Data** | `PUT` | `/api/data/:col/:id` | Update document by ID | -| **Data** | `DELETE` | `/api/data/:col/:id` | Delete document by ID | +| **Data** | `GET` | `/api/data/:collectionName` | Get all documents in collection | +| **Data** | `GET` | `/api/data/:collectionName/:id` | Get document by ID | +| **Data** | `POST` | `/api/data/:collectionName` | Insert new document | +| **Data** | `PUT` | `/api/data/:collectionName/:id` | Update document by ID | +| **Data** | `DELETE` | `/api/data/:collectionName/:id` | Delete document by ID |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/api-reference.md` around lines 8 - 12, The docs use two different route placeholder names (":col" in the API table and ":collectionName" elsewhere); standardize to one placeholder (use ":collectionName") by replacing all occurrences of "/api/data/:col" and "/api/data/:col/:id" in the API table with "/api/data/:collectionName" and "/api/data/:collectionName/:id" so the route examples match the rest of the docs (look for the table entries and route patterns in the docs to update).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/authentication.md`:
- Around line 19-21: The docs claim a 7-day signup JWT but the signup token
created in backend/controllers/userAuth.controller.js is signed without an
expiresIn; update the jwt.sign call that generates the signup token (the one in
the signup/create user handler) to include an expiresIn: '7d' option so the
created token actually expires in seven days, and ensure any related helper or
constant (if used) is updated consistently.
In `@docs/getting-started.md`:
- Around line 9-10: The docs currently state "Publishable Key (`pk_live_...`)"
is read-only but the example at the POST demo uses it for a write operation;
clarify the exact permission model and update examples: explicitly state that
Publishable keys (pk_...) are read-only and must not be used for
POST/PUT/DELETE, change the POST example that currently uses the publishable key
to instead reference the Secret Key (`sk_live_...`) as a backend-only operation
(or change the demo to a read-only GET that is safe for pk_...), and add a
prominent warning note before the example explaining that secret keys must
remain on trusted servers only and that publishable keys are safe for
client-side read-only use (or, if your system allows limited client-side writes,
document the security model including rate limits and allowed operations).
Ensure references to "Publishable Key (`pk_live_...`)" and "Secret Key
(`sk_live_...`)" and the POST example are updated accordingly.
- Line 12: The document jumps to "## 2. Your First Request" without a preceding
section 1; either insert a new heading "## 1. Get Your API Keys" before the
existing "## 2. Your First Request" heading or rename "## 2. Your First Request"
to "## 1. Your First Request" and renumber all subsequent top-level headings
accordingly; update the heading text "## 2. Your First Request" wherever it
appears to ensure sequential numbering.
In `@docs/introduction.md`:
- Around line 20-24: Remove the duplicated section heading "## Why urBackend?"
(the one at the later occurrence) and correct the sentence in that paragraph to
read "urBackend provides a **Unified REST API** that abstracts all that
complexity away." Locate the duplicate heading and the paragraph containing
"urBackend provides a **Unified REST API** that abstract all that complexity
away" and delete the extra heading and change "abstract" to "abstracts" so the
sentence is grammatical.
In `@docs/security.md`:
- Around line 24-27: The doc incorrectly describes the auth limiter as
monitoring failed login attempts while the actual middleware
(backend/middleware/auth_limiter.js, the exported limiter middleware with max:
10) is a simple request-count limiter; update docs/security.md to state the auth
endpoints are protected by a request-based rate limiter (e.g., max 10 requests
per window per IP) rather than a failure-based lockout, or alternatively modify
backend/middleware/auth_limiter.js to implement failure-based tracking if you
intend to rate-limit only failed logins; reference the limiter middleware
(auth_limiter.js) when making the change so the doc and implementation match.
- Around line 21-23: The docs overstate the NoSQL sanitization: update the
"NoSQL Injection Prevention" section to say that the current sanitizer in
backend/utils/input.validation.js only strips `$`-prefixed keys at the top level
(the top-level stripping logic / sanitize function) and does not recurse into
nested objects like {"data":{"$gt":""}}; either document this limitation
explicitly and recommend using a recursive sanitizer or a vetted library, or
change the implementation to perform a deep recursive removal of `$`-prefixed
keys in that same module.
In `@frontend/src/components/Layout/MainLayout.jsx`:
- Around line 6-7: The logo path is hard-coded in the const logoImage
declaration; replace it with a BASE_URL-aware path using
import.meta.env.BASE_URL so the app works when served from a non-root base;
update the const logoImage in MainLayout.jsx and make the same change for the
equivalent logo path/constant in Footer.jsx and LandingPage/index.jsx (or
extract a shared constant like siteLogoUrl) so all references concatenate
import.meta.env.BASE_URL with "urBACKEND_NAV_LOGO (2).png" instead of using a
root-relative string.
---
Nitpick comments:
In `@docs/api-reference.md`:
- Around line 8-12: The docs use two different route placeholder names (":col"
in the API table and ":collectionName" elsewhere); standardize to one
placeholder (use ":collectionName") by replacing all occurrences of
"/api/data/:col" and "/api/data/:col/:id" in the API table with
"/api/data/:collectionName" and "/api/data/:collectionName/:id" so the route
examples match the rest of the docs (look for the table entries and route
patterns in the docs to update).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 643249d4-8ffd-4098-892e-2deb096c3317
⛔ Files ignored due to path filters (2)
banner.pngis excluded by!**/*.pngfrontend/public/urBACKEND_NAV_LOGO (2).pngis excluded by!**/*.png
📒 Files selected for processing (15)
API_USAGE.mdREADME.mddocs/SUMMARY.mddocs/api-reference.mddocs/authentication.mddocs/database.mddocs/getting-started.mddocs/introduction.mddocs/security.mddocs/storage.mdfrontend/src/components/Layout/Footer.jsxfrontend/src/components/Layout/MainLayout.jsxfrontend/src/components/Layout/Sidebar.jsxfrontend/src/pages/LandingPage/index.jsxfrontend/src/pages/LandingPage/style.css
💤 Files with no reviewable changes (1)
- API_USAGE.md
|
Note Docstrings generation - SUCCESS |
Docstrings generation was requested by @yash-pouranik. * #37 (comment) The following files were modified: * `frontend/src/components/Layout/Footer.jsx` * `frontend/src/components/Layout/MainLayout.jsx` * `frontend/src/components/Layout/Sidebar.jsx` * `frontend/src/pages/LandingPage/index.jsx`
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/database.md (2)
29-35: Document query parameters for filtering, sorting, and pagination.The "Fetch All" endpoint (line 32) documentation doesn't mention how to filter, sort, limit, or paginate results when fetching all documents. For collections with many documents, developers will need guidance on:
- Filtering by field values (e.g.,
?status=published)- Sorting results (e.g.,
?sort=-createdAt)- Pagination (e.g.,
?limit=10&skip=20)If the API supports these features, documenting them would significantly improve usability. If not supported yet, consider noting that all documents are returned (which could be a performance concern for large collections).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/database.md` around lines 29 - 35, The "Fetch All" endpoint GET /api/data/:collectionName lacks documentation for query parameters; update the docs to list supported query params for filtering (e.g., field=value, multiple fields), sorting (e.g., sort=field or sort=-field for desc), pagination/limits (e.g., limit and skip or page and perPage), and provide example query strings like ?status=published&sort=-createdAt&limit=10&skip=20; if the API does not support these features yet, explicitly state that the endpoint returns all documents and note the potential performance implications and recommend adding pagination/filtering in the future.
29-35: Consider adding code examples for GET requests.Unlike the Create and Update sections, the Read section lacks code examples. Adding fetch examples for both endpoints would improve consistency and help developers understand:
- How to include the
x-api-keyheader in GET requests- What the response structure looks like
- How to handle returned data (single document vs. array of documents)
📝 Example to consider adding
// Fetch all documents const response = await fetch('https://api.urbackend.bitbros.in/api/data/posts', { method: 'GET', headers: { 'x-api-key': 'YOUR_KEY' } }); const posts = await response.json(); // Fetch single document const postId = "YOUR_DOCUMENT_ID"; const singleResponse = await fetch(`https://api.urbackend.bitbros.in/api/data/posts/${postId}`, { method: 'GET', headers: { 'x-api-key': 'YOUR_KEY' } }); const post = await singleResponse.json();🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/database.md` around lines 29 - 35, Add JavaScript fetch examples to the "Fetch All" and "Fetch Single Document" sections in docs/database.md showing how to call the GET /api/data/:collectionName and GET /api/data/:collectionName/:id endpoints with the x-api-key header, parse the JSON response, and demonstrate the expected response shapes (an array for the collection fetch and an object for the single document fetch); place concise snippets under the respective headings and label them "Fetch all documents" and "Fetch single document" so readers can copy/paste usage for those endpoints.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/database.md`:
- Around line 16-27: The example uses an API key directly in a client-side fetch
call (the fetch() example setting header 'x-api-key'), which risks leaking
secrets; add a concise security note after the code block stating that API keys
must never be embedded in frontend/browser code, that the shown pattern is for
server-side/Node.js or trusted environments only, and recommend using a backend
proxy or user-authentication (e.g., JWTs with proper expiry) instead of exposing
'x-api-key' to clients.
---
Nitpick comments:
In `@docs/database.md`:
- Around line 29-35: The "Fetch All" endpoint GET /api/data/:collectionName
lacks documentation for query parameters; update the docs to list supported
query params for filtering (e.g., field=value, multiple fields), sorting (e.g.,
sort=field or sort=-field for desc), pagination/limits (e.g., limit and skip or
page and perPage), and provide example query strings like
?status=published&sort=-createdAt&limit=10&skip=20; if the API does not support
these features yet, explicitly state that the endpoint returns all documents and
note the potential performance implications and recommend adding
pagination/filtering in the future.
- Around line 29-35: Add JavaScript fetch examples to the "Fetch All" and "Fetch
Single Document" sections in docs/database.md showing how to call the GET
/api/data/:collectionName and GET /api/data/:collectionName/:id endpoints with
the x-api-key header, parse the JSON response, and demonstrate the expected
response shapes (an array for the collection fetch and an object for the single
document fetch); place concise snippets under the respective headings and label
them "Fetch all documents" and "Fetch single document" so readers can copy/paste
usage for those endpoints.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…anik/urBackend into feat/docs-and-branding
…mited only for brute force Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…anik/urBackend into feat/docs-and-branding
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
SUMMARY.md (1)
3-3: Use h2 (##) for top-level section headings instead of h3.The document jumps from h1 (
# Summary) directly to h3 (### Documentation). For proper heading hierarchy, section headings should use h2 (##).📝 Proposed fix
-### Documentation 📚 +## Documentation 📚-### Project & Community 🤝 +## Project & Community 🤝Also applies to: 14-14
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@SUMMARY.md` at line 3, Change top-level section headings from h3 to h2: replace "### Documentation 📚" with "## Documentation 📚" and likewise update any other occurrences of h3 used as top-level sections (the other instance mentioned) so all main sections under "# Summary" use "##" for proper hierarchy; locate the headings by their text ("Documentation") and amend the leading hashes accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/getting-started.md`:
- Line 16: The docs incorrectly state that collections are created on the fly;
update the text to reflect that insertData checks project.collections for an
existing collection (see collectionConfig and the insertData controller) and
returns 404 if not found. Change the sentence to say collections must be
pre-configured before POSTing, and add a short note/instruction explaining how
to create or register a collection (or link to the collection setup docs) so
users won't hit the 404 from the insertData controller's collection lookup.
---
Nitpick comments:
In `@SUMMARY.md`:
- Line 3: Change top-level section headings from h3 to h2: replace "###
Documentation 📚" with "## Documentation 📚" and likewise update any other
occurrences of h3 used as top-level sections (the other instance mentioned) so
all main sections under "# Summary" use "##" for proper hierarchy; locate the
headings by their text ("Documentation") and amend the leading hashes
accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 429c63c6-080b-4d09-bc74-abfbe2236202
⛔ Files ignored due to path filters (2)
frontend/public/logo.pngis excluded by!**/*.pngfrontend/public/logo_u.pngis excluded by!**/*.png
📒 Files selected for processing (10)
DEVLOG.mdREADME.mdSUMMARY.mddocs/api-reference.mddocs/getting-started.mddocs/introduction.mddocs/security.mdfrontend/src/components/Layout/Footer.jsxfrontend/src/components/Layout/MainLayout.jsxfrontend/src/pages/LandingPage/index.jsx
💤 Files with no reviewable changes (1)
- DEVLOG.md
🚧 Files skipped from review as they are similar to previous changes (5)
- frontend/src/components/Layout/MainLayout.jsx
- docs/introduction.md
- docs/api-reference.md
- frontend/src/components/Layout/Footer.jsx
- frontend/src/pages/LandingPage/index.jsx
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/getting-started.md`:
- Around line 20-22: The markdown contains two adjacent blockquotes ("**💡 Pro
Tip**: You can define..." and "**⚠️ Note**: Write operations...") separated by a
blank line which triggers MD028; remove the empty line between these two
blockquote paragraphs so they are consecutive blockquotes (i.e., ensure the line
after the Pro Tip blockquote begins with '>' immediately before the Note
blockquote) to satisfy the linter.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 73bcf66c-d600-46a0-98d6-e5dce82b2fda
📒 Files selected for processing (1)
docs/getting-started.md
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
backend/controllers/storage.controller.js (1)
31-57:⚠️ Potential issue | 🟠 MajorMake the storage-limit check and reservation atomic.
Line 32 reads
project.storageUsedfrom the request object, but Line 54 increments the persisted counter later, after the file is already uploaded. Two concurrent uploads can both pass the check and push internal storage paststorageLimit, and a DB failure after a successful upload leaves an untracked file behind. Please reserve quota with a conditional DB update before the upload, then roll it back if the upload fails.💡 Proposed fix
- if (!external) { - if (project.storageUsed + file.size > project.storageLimit) { - return res - .status(403) - .json({ error: "Internal storage limit exceeded." }); - } - } + if (!external) { + const reservation = await Project.updateOne( + { + _id: project._id, + storageUsed: { $lte: project.storageLimit - file.size } + }, + { $inc: { storageUsed: file.size } } + ); + + if (reservation.modifiedCount !== 1) { + return res + .status(403) + .json({ error: "Internal storage limit exceeded." }); + } + } @@ - if (uploadError) throw uploadError; - - if (!external) { - await Project.updateOne( - { _id: project._id }, - { $inc: { storageUsed: file.size } } - ); - } + if (uploadError) { + if (!external) { + await Project.updateOne( + { _id: project._id }, + { $inc: { storageUsed: -file.size } } + ); + } + throw uploadError; + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/controllers/storage.controller.js` around lines 31 - 57, The current flow reads project.storageUsed then uploads and only afterward increments storageUsed, allowing race conditions and orphaned uploads; change to atomically reserve quota before upload by performing a conditional DB update (e.g., use Project.findOneAndUpdate or updateOne with a filter that ensures storageUsed + file.size <= storageLimit and $inc: { storageUsed: file.size }) and fail with 403 if the update did not match (no quota); proceed to call supabase.storage.from(bucket).upload(filePath, ...) only after the successful reservation; if the upload fails (uploadError or thrown), roll back the reservation by decrementing storageUsed by file.size (use a safe update like Project.updateOne({ _id: project._id }, { $inc: { storageUsed: -file.size } })) and surface the upload error to the caller. Ensure the code references project._id, file.size, Project.updateOne/findOneAndUpdate, filePath and the supabase upload call so you modify the right places.
🧹 Nitpick comments (1)
backend/controllers/storage.controller.js (1)
10-11: Consider extractingisExternalto a shared helper.This logic now duplicates
backend/controllers/project.controller.js:29-33. Keeping the storage classification rule in one place will prevent the controllers from drifting if theProjectshape changes again.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/controllers/storage.controller.js` around lines 10 - 11, The isExternal check in storage.controller.js (const isExternal = (project) => !!project.resources?.storage?.isExternal) is duplicated in project.controller.js; extract this logic into a shared helper (e.g., export a function isProjectStorageExternal in a new/shared module) and replace both local definitions with imports from that helper, updating storage.controller.js and project.controller.js to call the shared isProjectStorageExternal function so the storage classification rule is maintained in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@backend/controllers/project.controller.js`:
- Around line 903-909: The current enable-auth check only validates an existing
'users' collection schema but allows enabling auth when the 'users' collection
is missing; update the logic around usersCol and validateUsersSchema (the
project.collections.find(c => c.name === 'users') result) to explicitly block
enabling auth when usersCol is falsy by returning a 422 JSON response explaining
that the 'users' collection must exist (and include required 'email' and
'password' fields) before toggling isAuthEnabled, so Auth cannot be marked
enabled while signup/login remain nonfunctional.
In `@SUMMARY.md`:
- Line 13: The "Project & Community" heading jumps from h1 ("Summary") to h3;
change the "### Project & Community 🤝" heading to h2 ("## Project & Community
🤝") to restore proper incremental heading levels, and scan nearby headings
(e.g., any following "###" sections) to ensure heading levels only increase or
decrease by one step relative to their predecessors.
---
Outside diff comments:
In `@backend/controllers/storage.controller.js`:
- Around line 31-57: The current flow reads project.storageUsed then uploads and
only afterward increments storageUsed, allowing race conditions and orphaned
uploads; change to atomically reserve quota before upload by performing a
conditional DB update (e.g., use Project.findOneAndUpdate or updateOne with a
filter that ensures storageUsed + file.size <= storageLimit and $inc: {
storageUsed: file.size }) and fail with 403 if the update did not match (no
quota); proceed to call supabase.storage.from(bucket).upload(filePath, ...) only
after the successful reservation; if the upload fails (uploadError or thrown),
roll back the reservation by decrementing storageUsed by file.size (use a safe
update like Project.updateOne({ _id: project._id }, { $inc: { storageUsed:
-file.size } })) and surface the upload error to the caller. Ensure the code
references project._id, file.size, Project.updateOne/findOneAndUpdate, filePath
and the supabase upload call so you modify the right places.
---
Nitpick comments:
In `@backend/controllers/storage.controller.js`:
- Around line 10-11: The isExternal check in storage.controller.js (const
isExternal = (project) => !!project.resources?.storage?.isExternal) is
duplicated in project.controller.js; extract this logic into a shared helper
(e.g., export a function isProjectStorageExternal in a new/shared module) and
replace both local definitions with imports from that helper, updating
storage.controller.js and project.controller.js to call the shared
isProjectStorageExternal function so the storage classification rule is
maintained in one place.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f84e3bee-f7ea-45f7-b4ac-0bf0f5039dbc
📒 Files selected for processing (4)
README.mdSUMMARY.mdbackend/controllers/project.controller.jsbackend/controllers/storage.controller.js
Render
Destroyed
1 participant
🚀 Documentation Restructure & Brand Refresh
This PR introduces a professional documentation hierarchy and aligns the entire frontend with the official urBackend branding and visual identity.
📦 Changes
📚 Documentation Restructure (GitBook Ready)
API_USAGE.mdwith a structureddocs/directory.🎨 Brand Identity & Landing Page
urBACKEND_NAV_LOGOacross the Navbar, Sidebar, and Footer.#00f5d4) and Yellow accent theme from the brand banner.🛠️ DX & Frontend Upgrades
Authpage now supports editingObject,Array, andRef(IDs) fields via JSON-aware textareas.🧪 Verification
Built with ❤️ for urBackend.
Summary by CodeRabbit