4 ms·

I never really got graphql until I stumbled upon Wundergraph. (https://github.com/wundergraph/wundergraph https://github.com/wundergraph/wundergraph). I have n

I never really got graphql until I stumbled upon Wundergraph. (https://github.com/wundergraph/wundergraph https://github.com/wundergraph/wundergraph). I have no affiliation with them except that I have been building an app with it. I'm honestly puzzled how it's not more popular. Maybe people are solving these problems in other ways? But I tried out a bunch of stuff: Vapor, Supabase, Hasura, firebase, nhost, etc. None of it simplifies building complex systems the way WG does. Once I ship I plan to put together a nice sample repo talking about why I like it, but you can see the WIP here of how I use WG to build a system with (potentially) multiple databases being consumed in a type safe manner from my ios app, nextjs app (and anything else) https://github.com/Jonovono/WGStack https://github.com/Jonovono/WGStack

jensneuse 3y ago
I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")
- codetrotter 3y ago
  > I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
  - deleted 3y ago
    [deleted]
  - SlickStef11 3y ago
    If you say it 3 times, one of the founders will appear behind you with a Federetzel https://twitter.com/meixnertobias/status/1704565814022770857 https://twitter.com/meixnertobias/status/1704565814022770857
  - jensneuse 3y ago
    Say it 5 times and a genie appears who creates you a federated Graph of 100 Microservices although a single boring monolith would have been enough.
owlstuffing 3y ago
Using manifold-graphql[1], at least on the client side, has had a similar productivity gain here. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-graphql https://github.com/manifold-systems/manifold/tree/master/man...
- Jonovono 3y ago
  I'll take a look. What I like about WG is with the defined operations on the server, I then get a typed client I can use in Typescript, Openapi (which I can use to generate clients for ios, android, etc), I get postman collection. Pretty much any client I want to consume my api from, I have a client ready to go. Now, I make changes to any of my operations, my clients will complain.
  - owlstuffing 3y ago
    manifold does the same by working directly from graphql, no codegen steps to screw sync. if changes are made to graphql definitions, the client fails to compile.
    - Jonovono 3y ago
      ah, sounds interesting thanks. Will give it a look!
deleted 3y ago
[deleted]
timr 3y ago
So...you've got a thick abstraction layer on the front end calling into a thick abstraction layer on the back end, and it's all congealing together the results of different API calls? And it's all done by a third-party library? This seems like such a vastly overcomplicated way of doing things that I cannot fathom it. Throw GQL in the mix (which is already itself a thick abstraction layer), and it overwhelms me. The number of implicit failure cases, alone, makes my head spin. Maybe I'm old school, but my solution is to write a bespoke version of what the kids call a "back end for front end" that calls the APIs, handles the error cases, and consolidates the data into a single REST endpoint built-to-purpose. You don't need GQL. You don't need a library. It makes your life less complicated -- you have a single endpoint to test, there's no leakage of the back end into the front end, and it's easy to get things (like, say, logging and analytics) without depending on expensive JS proxies such as Segment. The only difficulty is that your back end engineers and your front end engineers have to actually talk to each other and coordinate (to be fair, this seems to be the difficulty driving 95% of this stuff: the front end engineers want to make arbitrary changes without depending on coordinating changes in the back-end API.)
- Jonovono 3y ago
  haha, I don't disagree. What makes it "simple" is the code generation, abstractions etc thats going on. But ya, thats also what makes it complex. At the end of the day tho, I feel like the complexity is going to be somewhere. Especially for a small team (single dev), I don't know any other better system. Either you will have complexity maintaining a bunch of endpoints, keeping track of where each one is used, what is returned, where the contracts are defined, writing tests to make sure nothing breaks, .... Sure, you might not have much abstraction and it will be cleaner that way, but it will be a nightmare to maintain, especially in the phase when you are moving fast and breaking things as you find market fit Or you can rely on heavy abstraction and code generation with end to end type safety so if you change something you instantly know if you broke anything at compile/deploy time (or earlier). Something about building this way is really nice, and quite different than anything else. Personally, i'm betting big on code gen. If coding behind layers of abstractions make you uncomfortable, whats coming down the pipeline is going to be giving you nightmares (https://twitter.com/hrishioa/status/1748346491528532344 https://twitter.com/hrishioa/status/1748346491528532344)

jensneuse 3y ago

I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")

codetrotter 3y ago
> I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
- deleted 3y ago
  [deleted]
- SlickStef11 3y ago
  If you say it 3 times, one of the founders will appear behind you with a Federetzel https://twitter.com/meixnertobias/status/1704565814022770857 https://twitter.com/meixnertobias/status/1704565814022770857
- jensneuse 3y ago
  Say it 5 times and a genie appears who creates you a federated Graph of 100 Microservices although a single boring monolith would have been enough.

owlstuffing 3y ago

Using manifold-graphql[1], at least on the client side, has had a similar productivity gain here. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-graphql https://github.com/manifold-systems/manifold/tree/master/man...

Jonovono 3y ago
I'll take a look. What I like about WG is with the defined operations on the server, I then get a typed client I can use in Typescript, Openapi (which I can use to generate clients for ios, android, etc), I get postman collection. Pretty much any client I want to consume my api from, I have a client ready to go. Now, I make changes to any of my operations, my clients will complain.
- owlstuffing 3y ago
  manifold does the same by working directly from graphql, no codegen steps to screw sync. if changes are made to graphql definitions, the client fails to compile.
  - Jonovono 3y ago
    ah, sounds interesting thanks. Will give it a look!

deleted 3y ago

[deleted]

timr 3y ago

So...you've got a thick abstraction layer on the front end calling into a thick abstraction layer on the back end, and it's all congealing together the results of different API calls? And it's all done by a third-party library? This seems like such a vastly overcomplicated way of doing things that I cannot fathom it. Throw GQL in the mix (which is already itself a thick abstraction layer), and it overwhelms me. The number of implicit failure cases, alone, makes my head spin. Maybe I'm old school, but my solution is to write a bespoke version of what the kids call a "back end for front end" that calls the APIs, handles the error cases, and consolidates the data into a single REST endpoint built-to-purpose. You don't need GQL. You don't need a library. It makes your life less complicated -- you have a single endpoint to test, there's no leakage of the back end into the front end, and it's easy to get things (like, say, logging and analytics) without depending on expensive JS proxies such as Segment. The only difficulty is that your back end engineers and your front end engineers have to actually talk to each other and coordinate (to be fair, this seems to be the difficulty driving 95% of this stuff: the front end engineers want to make arbitrary changes without depending on coordinating changes in the back-end API.)

Jonovono 3y ago
haha, I don't disagree. What makes it "simple" is the code generation, abstractions etc thats going on. But ya, thats also what makes it complex. At the end of the day tho, I feel like the complexity is going to be somewhere. Especially for a small team (single dev), I don't know any other better system. Either you will have complexity maintaining a bunch of endpoints, keeping track of where each one is used, what is returned, where the contracts are defined, writing tests to make sure nothing breaks, .... Sure, you might not have much abstraction and it will be cleaner that way, but it will be a nightmare to maintain, especially in the phase when you are moving fast and breaking things as you find market fit Or you can rely on heavy abstraction and code generation with end to end type safety so if you change something you instantly know if you broke anything at compile/deploy time (or earlier). Something about building this way is really nice, and quite different than anything else. Personally, i'm betting big on code gen. If coding behind layers of abstractions make you uncomfortable, whats coming down the pipeline is going to be giving you nightmares (https://twitter.com/hrishioa/status/1748346491528532344 https://twitter.com/hrishioa/status/1748346491528532344)