Yeah definitely an overstatement. I probably should spend some time thinking about other services and how they might be built? Could be a fun system design exercise.
Limitations could include: Caching queries, netlify doesn’t offer any kind of firewall like you can when using aws directly so you have to roll your own auth, vendor lock-in, datadog is the best option for log monitoring since it’s the only option both netlify and hasura dump too, hasuras monitoring service is only available on their cloud (not the oss version).
Don’t get me wrong, there are definitely limitations. And we haven’t even scaled to something like 100k+ users so I’m sure other limitations haven’t even shown themselves.
But I can’t even comment on that since I’ve never worked on something of that scale yet. I guess my question was more for MVP crud apps.
Just run some migrations, you have a full backend accessible via GraphQL. Add some event triggers and you can hit rest endpoints from changes in your db. Add some custom actions and your fe can hit your rest api for more complex tasks without leaving gql land.
It’s just less code to get things done. But that’s why I’m leaning into the expertise that can be found on HN! I would never claim my opinions are “right”
you have a full backend accessible via GraphQL. Add some event triggers and you can hit rest endpoints from changes in your db. Add some custom actions and your fe can hit your rest api for more complex tasks without leaving gql land
a) You're assuming everyone agrees GraphQL is always the way to go, which is far from common wisdom. Why is superior - especially for MVPs?
b) You're assuming that create CRUD MVPS in something like Python/Ruby/Node is slower/more complicated than what you're describing here, which is also far from certain. If we're talking about Hackathon style level of code they are all perfectly capable in building CRUDs really quickly.
I'm not saying you're necessarily wrong, I just think you haven't thought hard enough about the tradeoffs.
Comments
Yeah definitely an overstatement. I probably should spend some time thinking about other services and how they might be built? Could be a fun system design exercise.
Limitations could include: Caching queries, netlify doesn’t offer any kind of firewall like you can when using aws directly so you have to roll your own auth, vendor lock-in, datadog is the best option for log monitoring since it’s the only option both netlify and hasura dump too, hasuras monitoring service is only available on their cloud (not the oss version).
Don’t get me wrong, there are definitely limitations. And we haven’t even scaled to something like 100k+ users so I’m sure other limitations haven’t even shown themselves.
But I can’t even comment on that since I’ve never worked on something of that scale yet. I guess my question was more for MVP crud apps.
Just run some migrations, you have a full backend accessible via GraphQL. Add some event triggers and you can hit rest endpoints from changes in your db. Add some custom actions and your fe can hit your rest api for more complex tasks without leaving gql land.
It’s just less code to get things done. But that’s why I’m leaning into the expertise that can be found on HN! I would never claim my opinions are “right”
a) You're assuming everyone agrees GraphQL is always the way to go, which is far from common wisdom. Why is superior - especially for MVPs?
b) You're assuming that create CRUD MVPS in something like Python/Ruby/Node is slower/more complicated than what you're describing here, which is also far from certain. If we're talking about Hackathon style level of code they are all perfectly capable in building CRUDs really quickly.
I'm not saying you're necessarily wrong, I just think you haven't thought hard enough about the tradeoffs.