An alternative to both REST & GraphQL, combining the benefits of each, based on https://tools.ietf.org/id/draft-snell-http-batch-00.html.
Batch multiple related requests into one HTTP request, which can be sent once & processed once on the server-side, but otherwise keep all the benefits of REST & HTTP. This is one single raw HTTP request:
POST /batch
Host: example.com
Content-Type: multipart/batch
The git repo of the kata is here: https://github.com/sandromancuso/cleancoders_openchat/
The "starting-point" branch is where both implementations began: https://github.com/sandromancuso/cleancoders_openchat/tree/starting-point
"openchat-outside-in" branch captures the tomato by tomato history of the London approach."openchat-unclebob" branch captures the tomato by tomato history of the Chicago approach.
| [Unit] | |
| Description=WeeChat in a tmux server for nicd | |
| [Service] | |
| Type=forking | |
| User=nicd | |
| ExecStart=/home/weechat_start | |
| [Install] | |
| WantedBy=multi-user.target |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n concurrent flows.
After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?
It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed
https://www.facebook.com/notes/kent-beck/functional-tdd-a-clash-of-cultures/472392329460303
I have been taking Bryan O'Sullivan's excellent Haskell course and noticed something during the homework: TDD wasn't working for me, at least not as I apply it in object languages. This has forced me to take a step back and rethink what is really essential about TDD and what is an artifact of the languages I have been using.
A warning: I'm only on week two of the course. I did quite a bit of functional programming in the Dinosaur Computing Era, so the style is familiar, but everything contained herein is subject to change. I'm mostly just thinking aloud (and hoping for contributed wisdom.)
When I use TDD with an object language like Smalltalk, Java, or PHP I typically start programming with a trivial case--a List with no elements, for example. Working through it encourages me (sounds better than "forces") to think about the metaphors I am using and style of the API