| I completely disagree. Backends are far messier (especially when built over time by a team), more expensive and less flexible than a GraphQL or PostgREST's api. > I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns Writing backend code without knowing what you're doing is also an insecure nightmare that forces anti-patterns. All good engineering practices still need to apply to Hasura. Nothing says that "everything must go through it". Use it for the parts it fits well, use a normal backend for the non-CRUD parts. This makes securing tables easier for both Hasura and PostgREST. > Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly I'm gonna disagree a bit with the sibling post here. If you think that going through Hasura for everything is not working: just don't. This is 100% a self-imposed limitation. Hasura and PostgREST still allow you to have a separate backend that goes around it. There is nothing forbidding you from accessing the DB directly from another backend. This is not different from accessing the same database from two different classes. Keep the 100% CRUD part on Hasura/PostgREST, keep the fiddly bits in the backend. The kind of dogma that says that everything must be built with those tools produces worse apps. You're describing it yourself. > I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing I have heard the arguments and all I hear is people complaining about how hard it is to shove round pieces in square holes. These tools can be used correctly, but just like anything else they have a soft spot that you have to learn. Once again: "use right tool for the job" doesn't mean you can only use a single tool in your project. |