Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/meldiron/appwrite-ssr-remix
Appwrite Loves Remix! Demo application with authorized server-side and client-side rendering.
https://github.com/meldiron/appwrite-ssr-remix
appwrite remix
Last synced: about 1 month ago
JSON representation
Appwrite Loves Remix! Demo application with authorized server-side and client-side rendering.
- Host: GitHub
- URL: https://github.com/meldiron/appwrite-ssr-remix
- Owner: Meldiron
- License: mit
- Created: 2023-04-30T07:51:50.000Z (almost 2 years ago)
- Default Branch: main
- Last Pushed: 2023-05-11T11:48:44.000Z (over 1 year ago)
- Last Synced: 2024-12-24T19:51:46.340Z (about 1 month ago)
- Topics: appwrite, remix
- Language: TypeScript
- Homepage: https://remix.ssr.almostapps.eu/
- Size: 1.83 MB
- Stars: 6
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Almost SSR - Remix
> Demo application with authorized server-side and client-side rendering.
## 👀 Looking for Different Framework?
* [🔦 Svelte Kit](https://github.com/Meldiron/appwrite-ssr-svelte-kit) | [svelte-kit.ssr.almostapps.eu](https://svelte-kit.ssr.almostapps.eu/)
* [🔦 Next.js](https://github.com/Meldiron/appwrite-ssr-next-js) | [next-js.ssr.almostapps.eu](https://next-js.ssr.almostapps.eu/)
* [🔦 Nuxt](https://github.com/Meldiron/appwrite-ssr-nuxt) | [nuxt.ssr.almostapps.eu](https://nuxt.ssr.almostapps.eu/)
* [🔦 Astro](https://github.com/Meldiron/appwrite-ssr-astro) | [astro.ssr.almostapps.eu](https://astro.ssr.almostapps.eu/)
* [🔦 Qwik](https://github.com/Meldiron/appwrite-ssr-qwik) | [qwik.ssr.almostapps.eu](https://qwik.ssr.almostapps.eu/)
## 💭 So How Does It Work?
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.
## 🧰 Tech Stack
- [Appwrite](https://appwrite.io/)
- [Remix](https://remix.run/)
- [Pink Design](https://pink.appwrite.io/)
- [TypeScript](https://www.typescriptlang.org/)
## 🛠️ Setup Server
1. Setup Appwrite server
2. Create project `almostSsr`
## 👀 Setup Client
1. Install libarries `npm install`
2. Update `AppwriteEndpoint` in `src/lib/AppwriteService.ts`
3. Start server `npm run dev`
## 🚀 Deployment
1. Deploy the frontend on your production domain. For example, `myapp.com`.
2. Add the frontend domain as a trusted platform in your Appwrite project.
3. Add a custom domain to your Appwrite project, which is a subdomain of your frontend. For example, `appwrite.myapp.com`.
4. Update `SsrHostname` and `AppwriteHostname` in `src/lib/AppwriteService.ts` with proper domains.
## 🤝 Contributing
To contribute to frontend, make sure to use the [Pink Design](https://pink.appwrite.io/) 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.
## 🖼️ Screenshots
## 🤖 Auto-generated documentation
## Welcome to Remix!
- [Remix Docs](https://remix.run/docs)
## Deployment
After having run the `create-remix` command and selected "Vercel" as a deployment target, you only need to [import your Git repository](https://vercel.com/new) into Vercel, and it will be deployed.
If you'd like to avoid using a Git repository, you can also deploy the directory by running [Vercel CLI](https://vercel.com/cli):
```sh
npm i -g vercel
vercel
```
It is generally recommended to use a Git repository, because future commits will then automatically be deployed by Vercel, through its [Git Integration](https://vercel.com/docs/concepts/git).
## Development
To run your Remix app locally, make sure your project's local dependencies are installed:
```sh
npm install
```
Afterwards, start the Remix development server like so:
```sh
npm run dev
```
Open up [http://localhost:3000](http://localhost:3000) and you should be ready to go!
If you're used to using the `vercel dev` command provided by [Vercel CLI](https://vercel.com/cli) instead, you can also use that, but it's not needed.