undefined | Better HN

0 pointspeterldowns1y ago0 comments

Ha, I gave this exact speech at the 2021 Hasura Conference [0]. You hit the nail on the head.

Sometime in 2022 we switched back to REST endpoints for all of the reasons listed in the OP's article. Didn't hurt that we had hired for more fullstack engineers rather than "frontend only", so they saw exactly why we wanted to make the switch.

EDIT: to be fair, using Graphql and Hasura absolutely did help us iterate more quickly early on. But once we had a firmer idea of what we wanted to build, switching to REST was the right call. One of our most talented engineers wrote some helpers to make sure the frontend types were synced up with the backend types and that pretty much replaced the main benefit of using Graphql.

[0] https://hasura.io/events/hasura-con-2021/speakers/peter-down...

0 comments

tangkikodo1y ago

Things will be very interesting if we treat each single rest endpoint as a GQL query.

With static typing definition and OPENAPI, we can declare the response type first, and then borrow the concepts of resolver and dataloder to easily construct the response we want.

Using resolver and dataloader can iterate as fast as GQL, and after the requirement is stable, we can refactor each single endpoint on demand.

for FastAPI user, pydantic-resolve is developed for this purpose.

peterldownsOP1y ago

Yeah basically this!

j / k navigate · click thread line to collapse