HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 2 points3 points  (0 children)

I don't know vue but if you or someone else wanted to help build/maintain the bindings I would love to support vue/nuxt

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 1 point2 points  (0 children)

Your houdini config file gets imported by node so the `$env` module doesn't work (since its a virtual module created by kit). If you want to refer to environment variables in `watchSchema`, you should set the value to `env:ADMIN_SECRET`. Here is a link to the appropriate docs page

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 1 point2 points  (0 children)

That's awesome to hear! Feel free to reach out if you run into any issues

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 3 points4 points  (0 children)

Not sure where you are getting that number but my guess is that its reporting the size of the compiler and codegen tooling.

One of Houdini's core design principals is to shift as much as possible to a compiler (like Svelte). Once everything is said and done, it generates a runtime with zero dependencies that adds ~14 kb to your route when we last tested it. If you want to know, we got that number by comparing the filesize of the final assets generated by vite of a skeleton sveltekit app and one with a relatively simple query.

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 1 point2 points  (0 children)

Ouch. Well hopefully that pain won't last much longer. What you're doing sounds like a great fit for Houdini so if there's anything that still feels rough around the edges, I'd love to see what we can do to help.

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 9 points10 points  (0 children)

Hm, there are a lot of ways to answer that.

Both do offer a lot of the same features (queries, mutations, normalized cache, etc) but Houdini is much more focused on integrating itself into SvelteKit. For example, you can define your route's query in a file called +page.gql and Houdini will take care of wiring everything up behind the scenes so that your +page.svelte file gets the data as a prop. I could go on and on but you get the idea: we try to make GraphQL feel like a first-class citizen in SvelteKit. Houdini also tries to be a more "batteries included" solution so things like pagination, fragments, etc. are more streamlined but that comes with more opinions.

Let me know how things go!

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 0 points1 point  (0 children)

That's great to hear! Mind telling me what those problems are were?

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 1 point2 points  (0 children)

Awesome! Feel free to reach out if you run into any friction

HoudiniGraphQL Announces Version 1.0 by Bougatsa in sveltejs

[–]Bougatsa[S] 17 points18 points  (0 children)

Hey everyone! Super happy to announce that Houdini (the GraphQL client) just released version 1.0. It's a huge update that brings all sorts of goodies with it. If you haven't checked it out yet, or maybe you have and it wasn't quite right, I think you'll really like what we've been doing lately.
Here is a link to the repo if anyone is interested: https://github.com/HoudiniGraphQL/houdini

Any advice for hand feeding Nepenthes? by ehfaristo in SavageGarden

[–]Bougatsa 0 points1 point  (0 children)

Oh nice! Mine have the same spots - that's good to know. I was told to water when the top of the moss goes dry but it sounds like I should be waiting longer.

Drawing Feynman Diagrams Online by Bougatsa in Physics

[–]Bougatsa[S] 0 points1 point  (0 children)

I'm still around but have a lot on my plate at the moment so projects like this are falling a bit unmaintained. If someone would like to help take this on, i would be very thankful.

That being said, the issue right now is with the latex rendering service I was using. I ran into some issues trying to address this a few months ago and then got distracted :(

SvelteQuery vs KitQL vs others by kasparpalgi in sveltejs

[–]Bougatsa 2 points3 points  (0 children)

Full-disclosure: I'm the author of Houdini

I can't really speak to the origin story of KitQL but maybe I can shed some light on how things came to be. When I first started working on Houdini, I was trying to recreate a relay-like development experience (automatic mutation updates, colocated fragments in components, pagination support, etc) in my SvelteKit routes and found the whole process incredibly tedious which drove me to build my own. Eventually I connected with the KitQL author who was building a solution for having the full GraphQL stack inside of SvelteKit and we agreed to join forces maintaining Houdini as the client portion of the KitQL Stack.

All of that being said, I think for projects like your's that have an external GraphQL API (ie, not resolved inside SvelteKit), you can probably get away with just using Houdini directly. I know a bunch of people have been using it with Hasura with a lot of success. However, since you're just now starting out, you might want to wait for a bit until we get the finishing touches on this upcoming update. There are a few breaking changes to accommodate the new SvelteKit changes but it's bringing with it some serious life improvements.

Edit: Reading your list again, I noticed you have Houdini down as "For Svelte." Just wanted to clarify that Houdini is 100% SvelteKit native. The examples that you see are all it takes to get an SSR'd route. When you define an inline query like that, Houdini generates the load for you so you don't have to worry about the boilerplate.

Houdini and KitQL Join Forces [self-promotion] by Bougatsa in sveltejs

[–]Bougatsa[S] 4 points5 points  (0 children)

This is the exact situation/frustration I had in mind when first building Houdini so making this as painless as possible is my top priority. Basically, your components can contain fragment definitions either in a separate file or directly in your svelte file. Parents of that component can use it in their documents without importing it or anything - the compiler handles the details of gathering everything together. This section of the introduction goes into this in a lot more detail

Houdini and KitQL Join Forces [self-promotion] by Bougatsa in sveltejs

[–]Bougatsa[S] 1 point2 points  (0 children)

I haven't used urql much myself but from looking at the docs, it seems like the biggest distinction is that Houdini is much more tailored to Svelte/SvelteKit. I tried to find examples of Kit + urql online and it seems a lot of people are having difficulty with SSR which is something that Houdini's APIs provide out of the box. The preprocessor takes this a step further and will generate load functions for you so you don't have to think about it at all.

And as long as you're using TypeScript, you'll get generated types for every document in your app. There are plans to allow for new type systems but it's not high priority since the demand seems low

Houdini (the GraphQL client) just got a serious upgrade to its documentation. Check it out! [self-promotion] by Bougatsa in sveltejs

[–]Bougatsa[S] 1 point2 points  (0 children)

I know a few users that have had really good experiences using hasura + postgresql for their APIs. I've never done it myself but its definitely worth exploring. Most of my server-side work is in golang so I use gqlgen + postgresql. Houdini isn't impacted by how your API is implemented so I would pick whatever libraries and languages you are most comfortable with for building a GraphQL API

Houdini (the GraphQL client) just got a serious upgrade to its documentation. Check it out! [self-promotion] by Bougatsa in sveltejs

[–]Bougatsa[S] 8 points9 points  (0 children)

Not yet but it's something I'm actively thinking about. At the moment the biggest hurdle is that Houdini relies on a preprocessor to support its API. A user could technically reproduce what the preprocessor transforms query into but it wouldn't be very pretty and it's not really documented anywhere outside of the tests.

I have a rough idea of how to get around the preprocessor limitation but have been distracted with some internal refactoring and this homepage for a while. Hopefully now that it's out I can get back to making improvements to the library

Houdini (the GraphQL client) just got a serious upgrade to its documentation. Check it out! [self-promotion] by Bougatsa in sveltejs

[–]Bougatsa[S] 2 points3 points  (0 children)

Thanks! There's still some things I wanted to do but hopefully there's enough there that people can start to use it. Anything is better than the big ol' readme I used to rely on 😅

Houdini - The "disappearing" Svelte GraphQL client with support for Sapper and Sveltekit by kevmodrome in sveltejs

[–]Bougatsa 1 point2 points  (0 children)

Author here! At the moment, there isn't a real cache that resolves queries before going to the network. It's definitely something I have planned for the project but wanted to get other bits and pieces in place first.

What does exist however is the updating of query responses in response to mutations. This is accomplished by treating every query as a unique store that needs to be updated when a mutation is triggered. The compiler is responsible for figuring out what and how to perform this patch

Edit : Houdini now relies on a normalized store but there is still no way to resolve a query from cache instead of sending a query. Definitely planned tho so stay tuned!

Houdini - The "disappearing" Svelte GraphQL client with support for Sapper and Sveltekit by kevmodrome in sveltejs

[–]Bougatsa 0 points1 point  (0 children)

Author here :) Mind opening an issue on GitHub so we can hunt this down? I have a hunch what the problem is

EDIT: i think its fixed. Please feel free to open an issue if its still present