These aren't JavaScript APIs, they're Web Platform APIs.
Intl could be considered a JS API, honestly.
But yeah, it's ridiculous still conflating the two after all these years of full-stack Javascript developments.
Readit Newspibi commented on Lesser-known JavaScript APIs smashingmagazine.com/2022... · Posted by u/fagnerbrack
pibi commented on Progressive Microservices Framework for Node.js moleculer.services/index.... · Posted by u/pibi
I'm working with microservices all the time. Even when working solo. It's easy to focus on a single domain while developing a single part of the system, just like coding modules or classes.
That said, I'm always wondering why we are conflating so many things when talking about microservices: deployment and scalability, multi-repo and code structure, integration tests and distributed transactions, and so on. I mean: you can definitely build your application as a monolithic process with a microservices' architecture. It's just separation of concerns all the way down and a proper abstraction for the communication channel between the "modules". You don't need to embed your deployment structure in your repos and your code. These are "framework" problems. Just use one that abstracts all the deployment details until it's time to push the code to prod, and you have to split your code in different containers. This is why I'm now settled on Moleculer (https://moleculer.services/). It just works.
pibi commented on Don't start with microservices – monoliths are your friend arnoldgalovics.com/micros... · Posted by u/galovics
Maybe it is just me, but I always understood that properly designed microservices have their own specific datastore, which is not shared with other microservices even if these all collaborate to the same process.
If this is actually (still) true, that means that "the way you organize your code" is a bit simplistic. Your example of an "http api that converts pdfs to ..." is surely a valid example of a microservice, but most business products have to handle much more "state" than those, and this will create further complications which go far beyond "how to organize your code" (and make monoliths more appealing).
Well, it's all about the data responsibility: who is the owner of the data, how others can access the data. Once you have defined these, you see that you can "share the access" with other microservices (for example read only mode on a view), as long as the ownership and the access rules are preserved.
pibi commented on Don't start with microservices – monoliths are your friend arnoldgalovics.com/micros... · Posted by u/galovics
There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either.
maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code.
Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice.
Did you write a 150 repo application that can not be deployed seperatly anyway? welp thats a monolith.
You can also build a microservice ecosystem without kubernetes on your local network. We have done it for years with virtual machines. Software defined networking just makes things more elegant.
So dont stop using microservices because its "hard" or start writing monoliths because its "easy", because none of that is true in the long run.
What is true is that you have a group of people trying to code for a common goal. The way you reach that goal together defines how you organize your code.
Clarify the microservice architecture concept with "how you are going to deploy your system", as per your example, is exactly what I'm trying to explain to my teams since the microservice architecture inception. There are too many concepts conflating into the "microservice" term: code architecture(separation of concerns), source code organization, deployment, etc. This is very confusing, which is the reason why it's now common to say that microservices are "hard".
pibi commented on Sweden asks EU to ban Bitcoin mining... theregister.com/2021/11/2... · Posted by u/oblib
It's not deciding what algorithms you are allowed to run. It only has to be actually useful. If you find the bitcoin algorithm has use then you are free to run it. If you consider that fascist. Then it's also fascist that you aren't allowed to burn trash in your own backyard, which is illegal in many countries. The government is simply doing the job it's supposed to. Protecting their subjects.
Actually useful is subjective. What's the carbon footprint of all the gpu rigs in the world used to play video games? Is that useful for you?
pibi commented on NPM – "is-even", 160k weekly downloads npmjs.com/package/is-even... · Posted by u/st_goliath
Yes and is-odd contains
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};I love the fact that this small code is still wrong:
var isOdd = require("is-odd");
console.log(isOdd([1])); // TRUE!!pibi commented on JSON Schema bundling formalised json-schema.org/blog/post... · Posted by u/relequestual
> This already helps to eliminate lots of unnecessary code.
Well, I think you just moved the validation code to another place. Instead of putting it in your app, where (in my opinion) it belongs, you are putting it in a hard-to-read and difficult to understand external JSON file. I'm not sure how that's an improvement.
It's really not that hard-to-read or to-write. I have instructed dozens of young developers on that with almost no-supervision and no-issue. It's really pretty straightforward.
Also, I can replicate my validations at many levels down the stack: from the client to API-GW to the database model. All with a single definition.
pibi commented on ClickHouse: An open-source column-oriented database management system github.com/ClickHouse/Cli... · Posted by u/tosh
Fast, battle tested, vue2-like approach, great documentation, good community. The automatic indipendent-scalability as an option is usually the main selling point of these solutions, but honestly I think the real pro is the "composition" approach, which is essential if you want to keep a clean and well-organized codebase. On this regard, I found moleculer pretty great even for large teams.