Rank 2: Process
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?