You're welcome! It was a pleasure to share. I like GraphQL because it aligns with how I think about frontend queries and data. I had spent a bunch of time with

You're welcome! It was a pleasure to share. I like GraphQL because it aligns with how I think about frontend queries and data. I had spent a bunch of time with technologies like HATEOS that standardize sorta-similar REST-based approaches, but as soon as I saw GraphQL, in my mind it was immediately like: "THIS! This is it." There's just something about it for me. I can't say that that GraphQL is _important_ technologically, I'm sure I could have done it some other way, but it definitely is what has felt the most right of all other things I've tried, and I think that's really important. The front-end clients for GraphQL are also awesome. I've tried Relay and Apollo, and both are excellent. They normalize everything and provide reactive updates when something changes. > For example, if your client makes the same dozen or so queries day-after-day, would it ever make sense to use that knowledge to write a more static API? Hasura lets you turn GraphQL queries in REST endpoints! It's pretty amazing. But GraphQL also has this thing called "persisted queries" where instead of sending the queries every time that needs to be parsed, you send a hash for the queries, and the server already knows what the query is and has its representation stored in memory so it can satisfying it w/ the parse step. I can only hope to have to optimize like this :). > Is computer time and space too inexpensive to worry about these things? I don't think so... I've just been trying to ship without prematurely optimizing. It's been somewhat of a journey as it is :).