Synchronous requests to edge functions, roles for UI, #58
Synchronous requests to edge functions, roles for UI, #58Spotchi wants to merge 6 commits intoCommonsHub:mainfrom
Conversation
✅ Deploy Preview for chb-booking-system-blue-ocean-happy ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Can you elaborate how this will work with nostr in the future? I see the benefits, however, the server based approach moves us further away from the event based approach of nostr. Centralized logic on one server means less openness and less opportunities to build on top of it. |
|
This was mostly because it is less code. I think either approach doesn't work with NOSTR in any case. To move this to a NOSTR-backend and do it properly, we should either:
|
|
To create an open system, I see the current supabase DB as a placeholder for the nostr network, where users store their reuqests and comments. Then we have edge functions that can work with this data. I think users should not interact with the backend directly to keep the system open. |
|
I agree with the principle, but don't see how much more open a Database trigger than an API call. If this is deemed unnecessary we can can this PR, as it doesn't move towards more openness, only developer-friendliness |
|
Api calls depends on a single implementation, nostr storage only on the nostr node. To can or not to can? How would the migration to nostr work? How does the backend/edge functions would need to change? |
|
No more supabase db trigger or edge function. |
2 participants
This pull request introduces a major architectural change by migrating all booking and request operations from database triggers to direct edge function calls from the frontend. This centralizes business logic, improves security, and simplifies error handling. Effectively, this means the https://github.com/CommonsHub/bookingsystem-dbtrigger repo is no longer useful. The frontend hooks for creating and approving bookings and requests have been refactored to use the new edge function approach, and user role management has been enhanced to support role-based access control (RBAC). Several UI and localization improvements are also included.
Edge Function Migration and Centralization:
I have performed this refactor as there are less failure points (1 edge function instead of a DB trigger + an edge function with ad hoc authentication) and it is much easier to debug.
EDGE_FUNCTION_MIGRATION.mdto document the migration from database triggers to edge function calls, outlining the new architecture, benefits, migration steps, and troubleshooting.useCreateBooking,useCreateRequest,useApprovalOperations) to send data directly to the edge function for all create and approve operations, removing reliance on direct Supabase table writes and triggers. [1] [2] [3] [4] [5] [6] [7]Role-Based Access Control (RBAC):
AuthProviderto fetch user roles from theuser_rolestable and include them in the user context, enabling RBAC throughout the app. [1] [2]RequestProviderto use a new RBAC utility (isAdmin) instead of email domain heuristics. [1] [2]UI and Localization Improvements:
Headerto only show the "ICS Preview" button to users who have booking approval permissions, using a new helper (canUserApproveBookings). [1] [2]Other Changes:
packageManagerfield topackage.jsonfor reproducible builds.These changes modernize the system by centralizing logic, improving security and maintainability, and laying the groundwork for future enhancements.