https://pockethost.io/_app/immutable/chunks/vlF36rEb2.js

1import{B as e,R as t,St as n,kt as r}from"./CzsObDY8.js";import"./xihTtKlq.js";import"./C5qy-xbg.js";var i=r({default:()=>l,metadata:()=>a}),a={title:`Server-Side PocketBase is an Anti-Pattern`,description:`Using PocketBase from SvelteKit or Next.js server files is generally an antipattern.`},{title:o,description:s}=a,c=e(`<h1>Server-Side PocketBase is an Anti-Pattern</h1> <p>When building applications with PocketBase, it’s tempting to access it from server-side code in frameworks like SvelteKit or Next.js. However, this approach often indicates architectural issues and should generally be avoided. Here’s why:</p> <h2>The Problem with Server-Side Access</h2> <h3>Double Network Hops</h3> <p>When you access PocketBase from your server-side code, requests make two network hops:</p> <ol><li>Client -> Your Server</li> <li>Your Server -> PocketBase</li></ol> <p>This adds unnecessary latency compared to direct client-to-PocketBase communication.</p> <h3>JWT State Management Complexity</h3> <p>Managing authentication state becomes more complex when you need to transfer JWT tokens between client and server. This often leads to security vulnerabilities when not handled properly.</p> <h3>Rate Limiting Issues</h3> <p>Accessing PocketBase from a single backend IP address can trigger rate limits more easily than distributed client access. This is intentionally designed to encourage direct client communication. If you must proxy, see <a href="/docs/trusted-ips">Trusted IPs</a>.</p> <h2>Better Approaches</h2> <h3>Use Direct Client Access</h3> <p>PocketBase is designed to be accessed directly from client applications. Its built-in security rules provide fine-grained access control without needing a middleware server.</p> <h3>Leverage JS Hooks for Privileged Operations</h3> <p>If you need server-side logic or privileged operations, use PocketBase’s JS hooks feature instead of wrapping PocketBase calls in a separate backend:</p> <ul><li>Create custom API endpoints using JS hooks</li> <li>Handle privileged operations directly in PocketBase</li> <li>Implement business logic where it belongs</li></ul> <h3>Consider Static Site Generation</h3> <p>If you’re using server-side rendering primarily to protect PocketBase access, consider:</p> <ul><li>Moving to static site generation (SSG)</li> <li>Using PocketBase’s security rules for protection</li> <li>Implementing sensitive operations via JS hooks</li></ul> <h2>When Server-Side Access Makes Sense</h2> <p>While generally an anti-pattern, there are valid cases for server-side PocketBase access:</p> <ul><li>Complex data aggregation requiring server resources</li> <li>Integration with external services that can’t be exposed to clients</li> <li>Specific security requirements that can’t be met with API rules</li></ul> <p>However, even in these cases, consider whether the functionality could be implemented using PocketBase’s native features first.</p> <h2>Further Reading</h2> <p>Gani also posted about this on the PocketBase site: <a href="https://github.com/pocketbase/pocketbase/discussions/5313" rel="nofollow">JS SSR - issues and recommendations when interacting with PocketBase</a></p> <h2>Conclusion</h2> <p>PocketBase is designed to be a complete backend solution with built-in security and extensibility. Adding an additional server layer often complicates the architecture unnecessarily. Before implementing server-side PocketBase access, consider whether you can:</p> <ol><li>Use client-side access with security rules</li> <li>Implement the functionality via JS hooks</li> <li>Restructure your application to leverage PocketBase’s native capabilities</li></ol> <p>This will lead to simpler, more maintainable, and more performant applications.</p>`,1);function l(e){var r=c();n(58),t(e,r)}export{l as n,i as t};