A world where every life, even a dogs life is different f value.
Can the path to a solution exclude the solution itself.
48 karma · joined November 10, 2015
A world where every life, even a dogs life is different f value.
Can the path to a solution exclude the solution itself.
Github repository that powers the typescript function to Hasura connector bit: https://github.com/hasura/ndc-typescript-deno
...leads to the common impression that building out a GraphQL API is busy work... And moreover, this is true! This way of doing things sells GraphQL short.
...serious GraphQL users like Meta and Netflix have their own entity based frameworks to construct supergraphs.
Building an app or API without a supergraph is like storing your data in files instead of a relational database.
GraphQL keeps getting more mature and adding more and more tooling/features/middleware, but we also need to work on de-risking the technology from a more fundamental perspective to get to a rock solid foundation.
Isn't GABA downregulation the main reason for extreme withdrawal with alcohol?
Also the facts show Apple lobbied against usb c in the EU: innovation and patents, phone too thin.
This is available in Relay today and is coming up as a graphql RFC.
Some ideas from the post: BFF should be outside the security boundary (so it can be owned by product teams) RSC is a view layer! Don't put business logic in it.
I suppose the nice thing here is that we both now have two ways of doing the same thing.
I've explained why I prefer running the underlying tooling; hopefully it will be useful as one of those snippets of internet knowledge.
Independent of debugging, I would contend that this set up is better than running babel-node with something like nodemon, again, because of much better reload times.
Again, thanks for babel-node-debug, I've used it before, and I won't be too surprised if I find myself reaching for it again in the future.
There's babel-watch (https://github.com/kmagiera/babel-watch) that attempts to solve some of that, but I found that support for flags (debug) was limiting.
In the end, I figured why not just put together the fundamental tools. I use tmux and it's really not a problem to run multiple commands. Reloads are very rapid, and I never have to worry about things like flags or any other configuration being passed to the underlying tools, even as the ecosystem continues to evolve.
In my mind the debugger is a last resort tool, when other feedback loops don't provide enough information.
Where it really shines though, is when debugging rather terrible spaghetti like code, where a debugger really helps by allowing you to step through code, and see the whole state change. I guess most cases are in between the ideal and that.
Another nice thing is to be able to set a breakpoint and then actually mess with the variables at that point. That actually tightens the feedback loop because you can test out different states without having to go back, edit, and run the code path again.
Some insight into systems at Google scale, and the fact that in the end it's people running the show :)
Examples: https://status.cloud.google.com/incident/compute/15062 https://status.cloud.google.com/incident/compute/15064
- To treat a Kubernetes cluster and Kubernetes nodes as the fundamental units of infrastructure, abstracting out the underlying provider.
- Excellent developer workflow: https://github.com/hasura/pangaea/blob/master/pangaea/docs/w...