Dev News: A POST/GET Debate, Yarn 4.0, and Node.js Updates
Programmer Matthew Phillips has an “unpopular opinion” that he shared via — where else — the X platform (formally Twitter):
“Don’t use http verbs PUT, PATCH, DELETE. Just use POST for everything,” the creator of web framework Astro and Lucy Lang wrote. His reasons for this, in his own words:
- doesn’t support the others. Frameworks that allow it to do so through hacks.
- URLs are free, you don’t gain anything by overloading them.
- Purity < practicality
The tweet solicited responses that ranged from “Nope” and “Yes, that is an unpopular opinion” to more nuanced opinions.
“The only exception would be large-scale systems that need a standard REST API for mass public consumption,” Findlay wrote. “HTTP was designed in different era and the prescriptive verbs don’t make a lot of sense.”
“I’ve never encountered an API that uses them and thought ‘Great, this will make this API easier to understand and use,” he said. “It’s been way over a decade — I’m ready to say that I haven’t found the value in them.”
“GET vs POST have meaningful behavior differences in browsers. Use GET for stuff without side-effects, otherwise, use POST,” Archibald wrote. “The other verbs? Nah. I’ve always found it easier to be expressive in the URL than the HTTP verb.”
“From a security perspective DELETE/PUT is safer because you cannot use them in forms,” he wrote. This blocks some attack vectors (CSRF). You could add some extra layers, but being safer by default is nice.”
“I think you’re in trouble if that’s your attack mitigation,” Archibald responded.
To which Nux countered, ”For me, security is always layers. Layers upon layers. And this one doesn’t cost much. For me at least.”
Several people piped up to say the problem is REST, which, they pointed out, isn’t a standard and is based on an old web paradigm. Not everyone was anti-REST, though.
“I think REST is amazing and beautiful and I wish people would take the time to actually learn how to do it,” Brantly Harris shared. “Unfortunately that has never happened, so I’m coming around to your position. Mostly out of spite, though.”
Yarn Version 4.0 Releases
Nison wrote that version 4.0 is “significantly faster at installs” than version 3.6
“For instance, here’s the difference in time to install Gatsby and its ~350MiB dependency tree from a cold cache,” he wrote. “The 3x improved performances are due to a new package metadata cache which significantly improves performances of repeated installs…”
A major change for those updating from version 3 is that version 4.0 requires Node.js 18+ to use, Nison wrote. Other noteworthy changes include:
- New projects created with yarn init will use Corepack rather than yarnPath.
- All official plugins (typescript, interactive-tools, …) are now included by default.
- The yarn workspaces for each command has a slightly altered syntax.
The introduction of a Hardened Mode will cause Yarn to perform two extra validations, which he explains in the blog post are checking that, first, the resolutions stored in the lock file are consistent with what the range could resolve to; and second, that the package metadata stored in the lock file is consistent with the remote registry metadata.
“The Hardened Mode is enabled by toggling on enableHardenedMode, but it’s also automatically enabled when Yarn detects that it runs within a GitHub pull request on a public repository,” the post added as a tip. “This can be disabled by explicitly toggling off enableHardenedMode in your yarnrc file.”
There are also changes to the team’s recommendations for installing Yarn; including there’s no longer a need to rely on yarnPath when installing, because Corepack is shipped with both Node 18 and 20.
“If you don’t know it, this feature lets you define a set of rules that your project must satisfy. For instance, the Yarn repository enforces that no two workspaces depend on different versions of any given dependencies, unless explicitly allowed,” he wrote.
“The journey to transition from Yarn 3 to Yarn 4 was a lengthy one, with a whopping 53 release candidates along the way, but we finally made it!” Nison wrote. “Our aim for this new iteration has been to both decrease Yarn’s learning curve and improve your user experience, without the migration feeling overwhelming.”
Node.js 21 Now Available
“If you’re interested in getting access to interesting new features early, Node.js 21 is a great way to test and see what’s coming. Our release schedule specifically covers this. If you’re already in active deployment or if you are planning for it, Node.js 20 and 18 LTS are for you,” Rafael Gonzaga, Node.js technical steering committee member, said in a prepared statement.
Node.js 21 has a new experimental flag to flip module defaults. It also incorporates new security measures, which Gonzaga credited to the work of OpenSSF and Project Alpha Omega.
Node.js 20 has been promoted to long-term support.