Home >Web Front-end >JS Tutorial >NgSysV.A Serious Svelte InfoSys: A Rules-friendly version
This post series is indexed at NgateSystems.com. You'll find a super-useful keyword search facility there too.
Last reviewed: Nov '24
This series has previously described how you can use the Svelte framework in conjunction with Google's Firestore database Client API to develop useful information systems quickly and enjoyably. Sadly, however, Post 3.3 revealed how Firebase's otherwise excellent authentication system doesn't support Firestore activity in server-side load() and actions() functions where database rules reference the auth object.
Skipping your Firestore authorisation rules isn't an option - without these, your database is wide open to anyone who can hijack the firebaseConfig keys from your webapp. This post describes ways to re-work the Svelte server-side code so that it runs on the client side while Firestore rules remain firmly in place.
Not all load() functions will be affected by the presence of Firestore rules. Those that reference Firestore public collections will still run happily server-side. The Client API is still available in page.server.js files - it just won't work if it's asked to use collections protected by auth.
If your load() function addresses public files and you simply want to avoid server-side debugging, you might consider moving your load() function into a page.js file. This works exactly like a page.server.js file - Svelte will still run the function automatically at load time. But this happens client-side now where it can be debugged in the browser. See Svelte docs at Loading data for details
However, a 'compromised' load() function (typically where Firestore rules are used to ensure that users can only access their own data) must be relocated into client-side code. Typically, this would be reworked as a new, appropriately named, function in the