undefined | Better HN

0 pointstimr2y ago0 comments

> I'd much rather if I make a change to an endpoint, my project literally won't build and my IDE yells at me. I can make sweeping changes and go to sleep knowing I didn't mess anything up. And I know if I bring another engineer on, they can make sweeping (or tiny) changes and not have to know all of the places that consume that.

I think you're making an allusion to GQL typing here, which I grant. A big downside of REST+JSON is that you've pushed most of the "interface contract" to the structure of the JSON file.

> I should also note that WG doesn't require graphql.

Sure. The common element to both (for me) is the layering of abstractions that hide what's really going on.

0 comments

Jonovono2y ago

It's not GQL typing. None of my clients make GQL requests. I don't have apollo or any other junky Graphql client anywhere in my clients. All my clients still just make simple rest rpc requests. The benefit is that I have generated these clients to make these requests from simple typescript operations, or graphql operations (which the GQL is just specified on the server)

Ya, for rest and json that was my challenge. I liked the idea of openapi, but manually creating openapi docs was just not much fun.

If you are really curious about WG approach this is a good intro: https://www.youtube.com/watch?v=m3YrZav5-CU. They have some contrarian takes within the graphql community

j / k navigate · click thread line to collapse

0 comments

Jonovono2y ago

Ya, for rest and json that was my challenge. I liked the idea of openapi, but manually creating openapi docs was just not much fun.

If you are really curious about WG approach this is a good intro: https://www.youtube.com/watch?v=m3YrZav5-CU. They have some contrarian takes within the graphql community

j / k navigate · click thread line to collapse