Thanks for the feedback here. I modified the post a bit to not show the arrays because the library doesn't return arrays but rather aync generators. The power of this is that you have a single interface for interacting with all data no matter if there are zero or many results.
This is library is a proof of concept. In a perfect world, there would be a nice wrapper around this query result for interacting with the data.
queryResult.get('order').first()
This would provide a single order by calling the first yield for the generator. No need to worry about the underlying result.
With all of this said, it doesn't have to be this way. I'm exploring ideas here. The important concept is that GraphQL can be used to express the expectations of the client and a library like Graphable JSON can go find the needed data in the API. This gives the expressiveness of GraphQL with the benefits of REST. The sky is the limit. Thanks again for the feedback!
I wrote my own feedback below but left out this crucial piece you've mentioned here. I think to add to it, my family treats it as if I'm not there. I can't watch the kiddos for a few minutes or help get the laundry during work time. It's easy to do a lot of small things and have a completely disjointed day.
And the opposite is true, when I'm off work I'm off. My team can't treat me as always available because I'm remote. That takes time to establish.
One of the most transformative things I've come across for how to structure and test code has been Gary Bernhardt's talk on Boundaries [0]. I've watched it at least ten times. He also has an entire series on testing where he goes deeper into these ideas.
In this video, he talks of a concept called functional core, imperative shell. The functional core is your code that contains your core logic that can be easily unit tested because it just receives plain values from the outside world. The imperative shell is the outside world that talks to disks, databases, APIs, UIs, etc. and builds these values to be used in the core. I'll stop there—Gary's video will do 100x than I can do here :)
I've seen some use a versioned media typed like GitHub [0] or add a version parameter like "vnd.example-com.foo+json; version=1.0" [1]. People may use this version for the entire API or for versions of that specific resource as well.
I think one the biggest draws of something like Hugo would be that it's amazingly fast. You can check out the video [0] here that shows a benchmark. It generates 5,000 pages in around 6-7.
Another is that it's a single file to deal with. This may be different when you get into making your own themes, but to get going you just need to download the single file for your platform.
Thanks for the feedback here. I modified the post a bit to not show the arrays because the library doesn't return arrays but rather aync generators. The power of this is that you have a single interface for interacting with all data no matter if there are zero or many results.
This is library is a proof of concept. In a perfect world, there would be a nice wrapper around this query result for interacting with the data.
This would provide a single order by calling the first yield for the generator. No need to worry about the underlying result.
With all of this said, it doesn't have to be this way. I'm exploring ideas here. The important concept is that GraphQL can be used to express the expectations of the client and a library like Graphable JSON can go find the needed data in the API. This gives the expressiveness of GraphQL with the benefits of REST. The sky is the limit. Thanks again for the feedback!