Explore if its possible to push mutation side effects and query loads from the server to the client

[AlecAivazis]

Describe the feature

In situations where a mutation happens on the server, I wonder if we would be able to serialize the side effects for the cache and push them to the client to update the browser....

Criticality

game changer, I'll speak about it everywhere

[douglasward]

We really need this feature in order to update our client cache when running mutations in form actions - which is currently the only way when using superforms.

Is there any news on this front?

[jycouet]

I never played with it but I think they also have a story around client side. https://superforms.vercel.app/concepts/client-validation What specific things are you doing in actions?

[douglasward]

Nothing specific (just validating and mutating), but if you do it client-side then you cannot benefit from the form enhancement (no-js) from sveltekit.

I am going to see if I can write a wrapper so that I can define the form validation + mutations once and call them either on the client (if js is enabled) and benefit from cache, or on the server (if js in disabled).

But it would be nice not to have to think about these details 🙈

[jycouet]

Let me provide my point of view.

With GraphQL, traditionally, you have an endpoint with schema, resolvers, validation, everything...
Then you have a client part doing some queries/mutations. It's nice at this level (client side) to perform a few validations to have a pleasant user experience and avoid a go & back to the endpoint to know that this field needs 3 characters. (Anyway, this 3 characters check will also be done in the endpoint!)

Now, doing the "client-side validation" in an action, will perform a go & back to Sveltekit server that will do a validation, and if this is ok, it will do another call from SvelteKit to the GraphQL Endpoint (then will go back to SvelteKit, then to the client). To me, it looks like you are doing two times a server validation. (Be careful not to have different validations!). Yes, this is working with js disabled. So, the question is: Do you have a significant portion of users with js disabled?
If your focus is an app with js disabled, you will not benefit from universal load, caching, loading state, list operations, ... It's ok, but you need to be aware of it.

---

So the request is to use Houdini with Actions? Or Houdini without js?

I believe that it's possible to have Houdini working with actions (but it would require a lot of work). Without js, I don't see this possible. But then, it's not meeting your requirements?

Today, a mutation updates the cache, and everything is in sync. Without js, the mutation will not sync everything, so behavior would be different and I guess that it's not good.

---

Let me know what you think, I'm totally open to ideas & challenges 👍

[douglasward]

I agree with a lot of what you are saying @jycouet, but here are some more thoughts from my side.

The sveltekit server doesn't necessarily need to be the man in the middle and be performing mutations agains an external graphql server, that just happens to be how it currently is in our scenario. The graphql API could quite easily be part of the sveltekit server, which I think is what KitQL aims to achieve or something along those lines.

Anyhow, Houdini advertises itself to seemlessly integrate with sveltekit and to be a dissapearing GraphQL client. And for me this includes that it works with form actions which are heavily pushed for and recommended. I love the ideology that I can progressively enhance the form. If JS didn't load for some reason then I can still use the form to complete my task. If it did, then great I can benefit from optimistic resoponses, client side cache and all the other great things houdini offers.

All this is of course already possible by duplicating code / wrapping the functionality so it can be used both server side + client side, but is hacky / makes extra work. Instead it would be great to have some kind of supported / "invisible" way to work with form actions. Allowing people to use them if they wanted/needed to carry out operations on the server and allowing them to seemlessly update the cache on the client (if it is present).

[AlecAivazis]

I totally agree that a feature like this is "on brand" for Houdini. The goal of our SvelteKit integration is to make GraphQL feel like a natural extension and that would ideally include the full spectrum of features. The biggest issue right now is more of an alignment of priorities. Neither @jycouet nor I have applications that are set up how you are describing.

Wiring this is up is technically possible and it probably wouldn't require any deep dives into the core caching infrastructure but it does require some careful wiring of virtual endpoints (similar to what we do for the session infrastructure). A feature like that is something that's really best owned by a champion who has a strong incentive to push through the complexities.

If this is something that you are interested in working on @douglasward i would love to provide any guidance you need.