4 ms·

I’ve been using Hasura and PostgREST for a few years now with real big production apps, in enterprise and in startups, and honestly the only problem with them i

by whstl 2y ago

I’ve been using Hasura and PostgREST for a few years now with real big production apps, in enterprise and in startups, and honestly the only problem with them is that backend engineers feel threatened. They are great products that cover 95% of what a CRUD API does without hacks. They’re great tools in the hands of engineers too. To me it’s not about vibe coding or AI. It is that it's pointless to reinvent the wheel on every single CRUD backend once again.

NewJazz 2y ago
I have used them too, and I would say that at least for Hasura, performance can be poor for the generated queries. You have to be careful. Especially since they gate metrics behind their enterprise offering.
- whstl 2y ago
  This is the same for any GraphQL backend. And even REST backends can be misused: I've fixed way too many joins-in-the-frontend that were causing N+1 queries in lists.
  - deleted 2y ago
    [deleted]
TSiege 2y ago
Experienced backend dev here who also uses Hasura for work at a successful small business. I think it's great at getting a prototype to production and solves real business problems that a solo dev could do by himself. As engineer #2 it's a mess, and it doesn't seem like a viable long term strategy. I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns. Your entire schema is exposed. Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly. You're pushed into fake open source where you can't always run the software independently. Who knows what will happen when the VC backers demand returns or the company deems the version you're on as not worth it to maintain compared to their radically different but more lucrative next version. 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
- nawgz 2y ago
  > As engineer #2 it's a mess As a long-time Hasura stan, I can't agree with this in any way. > Your entire schema is exposed In what sense? All queries to the DB go thru Hasura's API, there is no direct DB access. Roles are incredibly easy to set up and limit access on. Auth is easy to configure. If you're really upset about this direct access, you can just hide the GQL endpoint and put REST endpoints that execute GQL queries in front of Hasura. > Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper > Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops ... How is an API that queries Hasura via GQL any different than an API that queries PG via SQL? Put your business logic in an API. Separating direct data access from API endpoints is a long-since solved problem. Colocating Hasura and PG or Hasura and your API makes these network hops trivial. Since Hasura also manages roles and access control, these "extra hops" are big value adds. > You're pushed into fake open source where you can't always run the software independently ... Are you implying they will scrub the internet of their docker images? I always self-host Hasura. Have for years. > 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 think your arguments pretty much sum up why people think it's just about backend engineers feeling threatened - your sole point with any merit is that there's one extra network leg, but in a microservices world that's generally completely inconsequential.
- whstl 2y ago
  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.
highwaylights 2y ago
I like PostgREST for some of it's use cases (views mostly), but the issue I have with it is that I don't often want a user to have direct access to the database, even if it's limited to their own data. Mike can edit his name and his bio. He could edit some karma metric that he's got view access to but no write access to. That's fine, I can introduce an RLS policy to control this. Now Mike wants to edit his e-mail. Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely. I can attach webhooks for this and use pg_net, but I could quickly have a lot of triggers firing webhooks inside my database and now most of my business logic is trapped in SQL and is at the mercy of how far pg_net will scale the increasing amount of triggers on a growing database. Even for simple CRUD apps, there's so much else happening outside of the database that makes this get really gnarly really fast.
- whstl 2y ago
  > Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely Congratulations: that's not basic CRUD anymore, so you ran into the 5% of cases not covered by an automatic CRUD API. And I don't see what's the dilemma here. Just use a normal endpoint. Keep using PostgREST to save time. You don't have to throw the baby away with the bathwater just because it doesn't cover 5% of cases the way you want. It's a rite of passage to realize that "use the right tool for the job" means you can use two tools at the same time for the same project. There are nails and screws. You can use a hammer and a screwdriver at the same time.
  - no_wizard 2y ago
    >You can use a hammer and a screwdriver at the same time How do you balance the nail and screw? I'm serious, I'm trying to picture this, hammer in one hand, screwdriver in the other, and the problem I see here is the nail and screw need to be set first, which implies I can't completely use them both at the same time. Perhaps my brain is too literal here, but I can't figure how to do this without starting with one or the other first

by whstl 2y ago

NewJazz 2y ago

I have used them too, and I would say that at least for Hasura, performance can be poor for the generated queries. You have to be careful. Especially since they gate metrics behind their enterprise offering.

whstl 2y ago
This is the same for any GraphQL backend. And even REST backends can be misused: I've fixed way too many joins-in-the-frontend that were causing N+1 queries in lists.
- deleted 2y ago
  [deleted]

TSiege 2y ago

Experienced backend dev here who also uses Hasura for work at a successful small business. I think it's great at getting a prototype to production and solves real business problems that a solo dev could do by himself. As engineer #2 it's a mess, and it doesn't seem like a viable long term strategy. I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns. Your entire schema is exposed. Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly. You're pushed into fake open source where you can't always run the software independently. Who knows what will happen when the VC backers demand returns or the company deems the version you're on as not worth it to maintain compared to their radically different but more lucrative next version. 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

nawgz 2y ago
> As engineer #2 it's a mess As a long-time Hasura stan, I can't agree with this in any way. > Your entire schema is exposed In what sense? All queries to the DB go thru Hasura's API, there is no direct DB access. Roles are incredibly easy to set up and limit access on. Auth is easy to configure. If you're really upset about this direct access, you can just hide the GQL endpoint and put REST endpoints that execute GQL queries in front of Hasura. > Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper > Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops ... How is an API that queries Hasura via GQL any different than an API that queries PG via SQL? Put your business logic in an API. Separating direct data access from API endpoints is a long-since solved problem. Colocating Hasura and PG or Hasura and your API makes these network hops trivial. Since Hasura also manages roles and access control, these "extra hops" are big value adds. > You're pushed into fake open source where you can't always run the software independently ... Are you implying they will scrub the internet of their docker images? I always self-host Hasura. Have for years. > 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 think your arguments pretty much sum up why people think it's just about backend engineers feeling threatened - your sole point with any merit is that there's one extra network leg, but in a microservices world that's generally completely inconsequential.
whstl 2y ago
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.

highwaylights 2y ago

I like PostgREST for some of it's use cases (views mostly), but the issue I have with it is that I don't often want a user to have direct access to the database, even if it's limited to their own data. Mike can edit his name and his bio. He could edit some karma metric that he's got view access to but no write access to. That's fine, I can introduce an RLS policy to control this. Now Mike wants to edit his e-mail. Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely. I can attach webhooks for this and use pg_net, but I could quickly have a lot of triggers firing webhooks inside my database and now most of my business logic is trapped in SQL and is at the mercy of how far pg_net will scale the increasing amount of triggers on a growing database. Even for simple CRUD apps, there's so much else happening outside of the database that makes this get really gnarly really fast.

whstl 2y ago
> Now I need to send a confirmation e-mail to make sure the e-mail is valid, but at this point I can't protect the integrity of the database with RLS because the e-mail/receipt/confirm loop lives outside the database entirely Congratulations: that's not basic CRUD anymore, so you ran into the 5% of cases not covered by an automatic CRUD API. And I don't see what's the dilemma here. Just use a normal endpoint. Keep using PostgREST to save time. You don't have to throw the baby away with the bathwater just because it doesn't cover 5% of cases the way you want. It's a rite of passage to realize that "use the right tool for the job" means you can use two tools at the same time for the same project. There are nails and screws. You can use a hammer and a screwdriver at the same time.
- no_wizard 2y ago
  >You can use a hammer and a screwdriver at the same time How do you balance the nail and screw? I'm serious, I'm trying to picture this, hammer in one hand, screwdriver in the other, and the problem I see here is the nail and screw need to be set first, which implies I can't completely use them both at the same time. Perhaps my brain is too literal here, but I can't figure how to do this without starting with one or the other first