Support for appwrite 15.1 and latest version of sveltekit?

[YugoCode]

Thank you very much for updating sdk-for-svelte!

Does your fork support the latest version of sveltekit and appwrite 15.1?

Thank you! :)

[koodeau]

@YugoCode it's currently working with sdk 0.8.1 and server version 0.14. I'll be updated soon but might take more time because of many breaking changes

[YugoCode]

Thank you very much koodeau! Looking forward to it ❤️

[pspierce]

Any further thoughts on this one? I worked on it some myself, but I haven't gotten too deep into it yet.

[greendesertsnow]

Does it break with the latest SK and AW?

[justin-prather]

bump

[ohbob]

hey guys how is the work going on this one? Found out about the library, looks sweet but needs update to the latest version!

[koodeau]

This library needs a huge refactoring guys. I think I might get back to refactoring this one but it will be client side only and may be good for building static SPA and MPA. Later I think it would be worth adding SSR support but that needs to be figured out

[digitaldrreamer]

This library needs a huge refactoring guys. I think I might get back to refactoring this one but it will be client side only and may be good for building static SPA and MPA. Later I think it would be worth adding SSR support but that needs to be figured out

@koodeau I hear you. More like a complete rewrite though. Needs to be built to support SSR too.
I'll have a go at it soon, when I have less on my hands.

[koodeau]

This library needs a huge refactoring guys. I think I might get back to refactoring this one but it will be client side only and may be good for building static SPA and MPA. Later I think it would be worth adding SSR support but that needs to be figured out

@koodeau I hear you. More like a complete rewrite though. Needs to be built to support SSR too.
I'll have a go at it soon, when I have less on my hands.

Not entirely a complete rewrite, components are mostly fine for the client side but their sdk integration is the most important part. Also for SSR support I’m thinking of doing something else than components, for SvelteKit that might make more sense to partially abstract things and provide better typescript support to kind of make SSR side of this look and feel as simple to use like Houdini but in the .server.whatever js or ts load function. Ideally tho make it just work without users having to that much on their own using my sdk class instead of Appwrite sdk, however backward compatibility with Appwrite sdk would be nice, one thing that is not clear enough yet for me of whether same sdk and same config is going to be used for both. Appwrite has support for configuring a server app like you’d expect to have in Express or others but keep it all clean natively in SvelteKit. Or maybe splitting the thing into a multiple packages and move further into a monorepo. There’s a lot to think about for planning a complete production ready solution for SSR support in SvelteKit, also documentation is key to better understanding of what you can do and how, I’ve been manually rewriting it after updates but if there’s still a thing to properly generate a correct useful stuff to have a documentation would be awesome. Things are different these days

[digitaldrreamer]

This library needs a huge refactoring guys. I think I might get back to refactoring this one but it will be client side only and may be good for building static SPA and MPA. Later I think it would be worth adding SSR support but that needs to be figured out

@koodeau I hear you. More like a complete rewrite though. Needs to be built to support SSR too.
I'll have a go at it soon, when I have less on my hands.

Not entirely a complete rewrite, components are mostly fine for the client side but their sdk integration is the most important part. Also for SSR support I’m thinking of doing something else than components, for SvelteKit that might make more sense to partially abstract things and provide better typescript support to kind of make SSR side of this look and feel as simple to use like Houdini but in the .server.whatever js or ts load function. Ideally tho make it just work without users having to that much on their own using my sdk class instead of Appwrite sdk, however backward compatibility with Appwrite sdk would be nice, one thing that is not clear enough yet for me of whether same sdk and same config is going to be used for both. Appwrite has support for configuring a server app like you’d expect to have in Express or others but keep it all clean natively in SvelteKit. Or maybe splitting the thing into a multiple packages and move further into a monorepo. There’s a lot to think about for planning a complete production ready solution for SSR support in SvelteKit, also documentation is key to better understanding of what you can do and how, I’ve been manually rewriting it after updates but if there’s still a thing to properly generate a correct useful stuff to have a documentation would be awesome. Things are different these days

@koodeau I understand. A new approach to things would make sense. I think it would be viable to create separate classes for SSR and CSR.
Just as you said, there's a lot to think about. I just think we should keep in mind that making the library SSR ready, we might need to compromise backwards compatibility.
Happy hacking🤟

[koodeau]

@Codes-wizard I agree. Making a second SDK class for the server only is something that many users would find incredibly valuable for their SSR logic. This new server-side SDK class could offer some advanced SvelteKit integration, simplifying tasks like authentication, handling protected routes, and possibly incorporating more "under the hood" magic for pre-rendering and build-time optimizations. This would make it SvelteKit-specific and user-friendly. Another option is to explore using Bun instead of Node for certain APIs to facilitate a seamless transition to a bun-based SSR setup. For other cases, the existing node-appwrite SDK might still be the way to go.

I see the SSR integration as a phase that could come later. What I'm inclined to focus on initially is providing APIs that can expose parts of the client library. This would enable users to leverage these components in scenarios where they're using SvelteKit SSR. It could help reduce the number of requests made from the browser, enable effective caching via workers or Redis, and provide a means to feed data into this client library, making it more compatible with their own server-side logic within SvelteKit.

Overall, having a secure and well-architected integration between both the client and server sides is crucial. It ensures that the library can seamlessly bridge the gap between these two worlds while maintaining security and reliability.

Additionally, considering the potential for using a much faster server, let's say Go running on a serverless architecture, there are a couple of approaches. One only involves writing a Go server/function. Another approach could involve running both Go and Node servers, enabling you to harness Go's speed for specific tasks while continuing to use Node for the rest of your SSR setup.

At least this way I believe we might not compromise backwards compatibility for client-side Svelte components API at least, but later on with v1 it would be a breaking change anyway. For those who are still using old Appwrite self-hosted versions and can maintain their front-end, it will then be better to just stick to specific version of this library if it can satisfy the needs.

Also it will be better to upgrade stuff and in general ship components with Svelte 4, we just need to look for potentially incompatible things like any upcoming features in Svelte that are not available in Svelte 3. For new users having Svelte 3 in their Svelte 4 projects wouldn't be a nicest thing to deal with, but at some point you have to give up on something and introduce a breaking change.

[greendesertsnow]

You guys are expecting Bun and SSR support but this thing is running on PHP, a self hosted Appwrite function can only perform 1 request per second... I mean...
appwrite/appwrite#5629

[koodeau]

You guys are expecting Bun and SSR support but this thing is running on PHP, a self hosted Appwrite function can only perform 1 request per second... I mean... appwrite/appwrite#5629

SSR support implementation is still not entirely clear, but what I meant is that it's for SvelteKit or any other server implementation support, not to be deployed to cloud functions as a standalone thing, but making some kind of adapter for this use case makes more sense, I've been trying to discuss this idea in Appwrite discord.

[greendesertsnow]

You guys are expecting Bun and SSR support but this thing is running on PHP, a self hosted Appwrite function can only perform 1 request per second... I mean... appwrite/appwrite#5629

SSR support implementation is still not entirely clear, but what I meant is that it's for SvelteKit or any other server implementation support, not to be deployed to cloud functions as a standalone thing, but making some kind of adapter for this use case makes more sense, I've been trying to discuss this idea in Appwrite discord.

They're going to tell you to create a JWT and validate it in the backend every time you access a form of auth restricted area.
Here's a full discord thread on the same issue with Nextjs SSR...
Appwrite is not written for servers in mind, It's literally for mobile apps, SPAs and CSR. Going for SSR with Appwrite is a stretch.

[koodeau]

You guys are expecting Bun and SSR support but this thing is running on PHP, a self hosted Appwrite function can only perform 1 request per second... I mean... appwrite/appwrite#5629

SSR support implementation is still not entirely clear, but what I meant is that it's for SvelteKit or any other server implementation support, not to be deployed to cloud functions as a standalone thing, but making some kind of adapter for this use case makes more sense, I've been trying to discuss this idea in Appwrite discord.

They're going to tell you to create a JWT and validate it in the backend every time you access a form of auth restricted area. Here's a full discord thread on the same issue with Nextjs SSR... Appwrite is not written for servers in mind, It's literally for mobile apps, SPAs and CSR. Going for SSR with Appwrite is a stretch.

I can disagree because they support integration with your own backend, that's is what we might focus on as well. client side sdk and ingrations is not supposed to be a target for SSR, that's why it is client side. People mostly don't understand that and with react server components this misunderstanding only getting worse