undefined | Better HN

0 pointsJonovono2y ago0 comments

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)

0 comments

timr2y ago

> 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

Yeah, I hear this argument a lot, but it hasn't been a problem in my lived experience. Certainly for small teams (and absolutely for apps written by one person), it's not that hard to keep track of the endpoints. Even for larger orgs, teams tended to want to keep their endpoint counts low, and would push back on the sorts of expansions in back-end complexity that these frameworks (i.e. GQL) make "easy" (but in reality, just kick the technical complexity can down the road; it's a lot easier to see the horrible DB queries when they're not invented dynamically by the one GQL query you didn't think of, written by some Future Intern who doesn't know any better).

I can see how this becomes more of a concern when you've got a massive org that has doubled down on microservices, but that's not most orgs.

JonovonoOP2y ago

That's fair. In my experience, once the endpoints get above a handful id rather not have to keep that all in working memory. And say you have several clients: android, ios, web, internal tooling, cli, rebase, etc. You make a change to 1 endpoint, now you have to remember everywhere you consume that client? Even 5 endpoints, 5 clients things are getting complex to keep in your head.

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 should also note that WG doesn't require graphql. I have a few graphql operations, but you could use it completely without any graphql operations.

timr2y ago

> 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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

timr2y ago

I can see how this becomes more of a concern when you've got a massive org that has doubled down on microservices, but that's not most orgs.

JonovonoOP2y ago

I should also note that WG doesn't require graphql. I have a few graphql operations, but you could use it completely without any graphql operations.

timr2y ago

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.

1 more reply

j / k navigate · click thread line to collapse