Demo application with authorized server-side and client-side rendering.
- 🔦 Svelte Kit | svelte-kit.ssr.almostapps.eu
- 🔦 Next.js | next-js.ssr.almostapps.eu
- 🔦 Nuxt | nuxt.ssr.almostapps.eu
- 🔦 Qwik | qwik.ssr.almostapps.eu
- 🔦 Remix | remix.ssr.almostapps.eu
Appwrite uses 1st party secure cookies for authorization. For legacy reasons, there are two such cookies. They are both very similar, but one's name ends with _legacy and is configured a tiny bit differently. It's also possible to use a fallback cookie, but that is not secure for production, and we will not be using that.
To ensure server-side rendering works, we need to set those cookies on our SSR server hostname instead of the Appwrite hostname. Let's say our Appwrite instance is on cloud.appwrite.io, and our app is on myapp.com. SSR server on domain myapp.com won't receive appwrite.io cookies. This is expected behavior, as browsers keep 1st party cookies securely scoped to specific domains.
To set those cookies on the SSR server, we need a special API endpoint in our SSR server. This endpoint will send a request to create a session, proxying email/password or other credentials. This endpoint next parses the response set-cookie header, replaces domain configuration on the cookies, and set's it's own set-cookie on the response to the client.
When a client calls this endpoint, the cookie will now be set on the SSR server hostname instead of the Appwrite hostname.
This makes server-side rendering work, but now client-side rendering is broken. Since set-cookie coming to the browser only includes a cookie for the SSR server, talking to the Appwrite server directly won't have a proper cookie - there is no auth cookie on the Appwrite hostname. To overcome this problem, we ensure the Appwrite hostname is a subdomain of the SSR hostname. For example, if our SSR server runs on myapp.com, Appwrite needs a custom domain configured on appwrite.myapp.com. With this setup, all requests to the Appwrite server will include auth cookies, and the user will be properly authorized. This is possible thanks to Appwrite prefixing the cookie domain with ., meaning all subdomains can also access the cookie.
- Setup Appwrite server
- Create project
almostSsr
- Install libarries
npm install - Update
AppwriteEndpointinsrc/pages/AppwriteService.js - Start server
npm run dev
- Deploy the frontend on your production domain. For example,
myapp.com. - Add the frontend domain as a trusted platform in your Appwrite project.
- Add a custom domain to your Appwrite project, which is a subdomain of your frontend. For example,
appwrite.myapp.com. - Update
SsrHostnameandAppwriteHostnameinsrc/pages/AppwriteService.jswith proper domains.
To contribute to frontend, make sure to use the Pink Design design system. Ensure both dark and light theme work properly, as well as responsivity on mobile, tablet and desktop.
When contributing with static files, ensure all images are in WEBP or SVG format.
npm create astro@latest -- --template minimal
🧑🚀 Seasoned astronaut? Delete this file. Have fun!
Inside of your Astro project, you'll see the following folders and files:
/
├── public/
├── src/
│ └── pages/
│ └── index.astro
└── package.json
Astro looks for .astro or .md files in the src/pages/ directory. Each page is exposed as a route based on its file name.
There's nothing special about src/components/, but that's where we like to put any Astro/React/Vue/Svelte/Preact components.
Any static assets, like images, can be placed in the public/ directory.
All commands are run from the root of the project, from a terminal:
| Command | Action |
|---|---|
npm install |
Installs dependencies |
npm run dev |
Starts local dev server at localhost:3000 |
npm run build |
Build your production site to ./dist/ |
npm run preview |
Preview your build locally, before deploying |
npm run astro ... |
Run CLI commands like astro add, astro check |
npm run astro --help |
Get help using the Astro CLI |
Feel free to check our documentation or jump into our Discord server.