Hey folks. 👋
First and foremost, I really appreciate the effort Appwrite team as placed into making SSR options easier to integrate with the Appwrite ecosystem. I personally spent perhaps a bit too much time and experimenting with different "integration" styles until I found one that was working good enough for me.
If you are curious... It involved managing as much things as possible on the users' browser as possible. I only proxied the sign-in method in order to set a first party cookie on the server and was only using that information for initial server side rendering. I wa mostly doing mutations via the Client SDKs and using serverless functions to handle a few operations (which introduced some challenges) which required additional things that couldn't be done on the client; The issue here was that I had to spread my code across multiple repositories, synchronise a bunch of methods across environments and also had some challenges regarding sources of truth due to asynchronous nature of database changes (e.g.: should I push changes from Appwrite's User table to my own User table, or the other way around? This type of problems which I won't have using the server directly).
However, I do have a question regarding this new feature. I understand through the docs, that this approach expects all our data changes to go through our first party server? Both reads and writes? Ideally, I would like to keep on doing Reads through client SDKs, without making requests to my Nuxt server, and start doing mutations through my Nuxt server instead of serverless functions.
- This was possible before, but hard to implement, because when the user logged in on my nuxt server I would forward, the Appwrite original cookie AND a copy of it with my domain as first party. Would your new SSR options work with this model?
TL;DR
Developers are appreciating the effort the Appwrite team put into making SSR options easier to integrate. One developer shares their experience with integrating SSR and explains their process involving managing things on the user's browser, using the Client SDKs for mutations, and handling some operations with serverless functions. They are concerned about the new feature requiring all data changes to go through the first-party server, wondering if their previous model of forwarding cookies would work with this new SSR approach.
