4 ms·

> I think the industry is strangely blind to the consequences of this Well, I think if you're not blind to those things to some degree, you're stuck forever in

by nawgz 6y ago

> I think the industry is strangely blind to the consequences of this Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack. For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way. I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen. Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack. So I think the blinders are key to progressing in the short term despite the productivity losses you're taking in the long term, and then when you phrase it like this it is surely no surprise companies behave like that.

eloff 6y ago
> Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack. Can you expand on that? The chain of reasoning is probably clear to you, but I can't follow it. > For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way. I like Hasura a lot, I've advocated it at a previous company I worked for, and after many months of meetings I got it approved to add to our stack - which was then never prioritized, but that's another story. > I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen. I don't think writing GraphQL is superior to writing SQL, and again you have to think not just in terms of GraphQL but also in terms of how Hasura translates that to SQL under the hood. I am slightly biased though, because I'm creating on a framework to query the db using SQL from the frontend, I'm curious how you think that would compare with Hasura: https://github.com/sqljoy/sqljoy https://github.com/sqljoy/sqljoy > Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack. I'm not really sure how this connects to my argument about complexity, although I think the link is clear to you, can you expand on that?

by nawgz 6y ago

eloff 6y ago

> Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack. Can you expand on that? The chain of reasoning is probably clear to you, but I can't follow it. > For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way. I like Hasura a lot, I've advocated it at a previous company I worked for, and after many months of meetings I got it approved to add to our stack - which was then never prioritized, but that's another story. > I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen. I don't think writing GraphQL is superior to writing SQL, and again you have to think not just in terms of GraphQL but also in terms of how Hasura translates that to SQL under the hood. I am slightly biased though, because I'm creating on a framework to query the db using SQL from the frontend, I'm curious how you think that would compare with Hasura: https://github.com/sqljoy/sqljoy https://github.com/sqljoy/sqljoy > Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack. I'm not really sure how this connects to my argument about complexity, although I think the link is clear to you, can you expand on that?