There are also a few wrappers around cluster to make orchestration and mgt easier[1].
It's also worth looking at the new Worker Threads API[2] for node. If you're spinning off for compute intensive things, wrapping worker threads in a pool is a pretty good option.
NOTE: If you are using Kubernetes, do *NOT* use clustering in node. You're better off using the external management of k8s and launching multiple instances that way. It'll simplify your management and communications interfaces.
[1] https://www.npmjs.com/package/cluster-service
[2] https://nodejs.org/api/worker_threads.html
There's really not enough in the article to recreate the solution... It discusses a potential client api for a queue, and that it can be backed by redis.
This is kind of a solved problem repeatedly... There are also dedicated queue servers and services and libraries available.
If you want a Message Queue style interface, backed by redis, I'd suggest you look at Kue[1], which is widely used and has a pretty rich ecosystem around it.
If you need more complex queuing, then I'd look at RabbitMQ specifically as an AMQP compatible queue server, or if you're already using a cloud provider, there's usually the option of a simple queue system and a more complex workflow system as other options.
Also, as an adjacent issue, there are RPC systems you can look at behind MQ systems (like kue or rabbit), or orchestration options behind Function as a Service (FaaS) hosting such as AWS Lambda or Azure Functions. This area is really interesting for micro-service orchestration behind compute heavy operations.
[1] - https://www.npmjs.com/package/kue
Frankly, you should have looked at the source code for the material-ui project and the components there. They're using the theme system and reusing or inheriting from there... It's actually really easy to create your own components from the base components outlined. There are also tools for creating customized themes and colors, etc.
It's really in a similar vein to when I talk about Bootstrap, as it's also really easy to look at and use/modify the styling from the source scss files. Likewise you can definitely use the primitives, themes, cards, etc in material-ui's library to create more customized components with the events you need for your own reuse.
Probably a bit more than 10 minutes... nice getting started walk through with Angular.
Aside: most of the advertorials from 2mc get deleted, it's nice to see actual content worth keeping on this feed.
While I agree with the sentiment... I'd add a couple things.
First, you should have a global error trap (for client side apps/spas) that blows up the world, logs to the console and replaces the entire body content with a generic error. This ensures you are properly capturing errors. This should include the same error trap inside your main react component. By doping this, you can then prioritize trapping expected error conditions to avoid the fallback, while always having a fallback. Too many applications blindly swallow, or worse don't handle uncaught errors (promises, react render, global error handler). If this is a Node application, also stop the world, log, wait a full minute then restart.
Second: always have a *UNIQUE* code for each location in code where you may raise an error condition for your own errors. This allows you to track down where it was raised quickly... If you are bubbling up...
catch(error) {
// catch and ensure a unique code is attached for
// finding where errors are coming from.
throw Object.assign(error, {code: error.code || 'UNIQUEID' });
}
Yes, you should absolutely display better error messages to the user... however, too many application projects I've come into don't even get the basics down right first.
I would recommend updating the article to use the *CURRENT* version of go, not a year and a half old release. The only reason I am not removing the article (off topic for JS site) is that it *could* be useful to someone that wants to use Go for webassembly development.
Go and Rust in particular seem to be two of the better options for wasm. C# is gaining some ground. C/C++ are also options, but often require more tweaking and knowledge to get started with.
I was probably overly critical, but even the libraries I looked at that did break them up were pretty big... I understand that it may be useful or worth it when you do need more complex, or larger visuals without the time to work through the math/render yourself. With a JSX supported interface, you can actually do a lot of SVG work with far less additional overhead in the browser, right now that's generally my goto for the few areas of the apps I'm working on requiring more complex/interactive visuals.
I'm not a total minimalist here. I strive to keep my payload (min+gz) as small as reasonable, generally under 300-500k, though I love when I can deliver under 100k. This often turns into 1-2mb parsed, and a 3-5mb logic tree in memory. Some of the charting libraries in the article take that much by themselves. This may not seem like much, but it's often quite a bit of overhead on a modest laptop. 300kb is actually enough room to bring in a *LOT* I'm using several react/redux libraries and a couple dozen Material-UI components as well as quite a few SVG icons (mdi-material-ui) and a lot of custom components for the project (about 20-25% of total payload)
There is absolutely no mention of or consideration of size delivered, parsed or computed in the article. Your referenced AnyChart, the core is over 300kb delivered by itself... the pie chart on top of that isn't bad at around 18kb, though there are other pie chart libraries that are stand alone in the 4-5kb range. Both min+gz. I could probably run core + pie through closure compiler to see how small it can be though. Right now, my main projects are an SPA where the entire payload is at 380k min+gz, and another where it's around 130kb. AnyChart's core would just about double my larger app. And is 2.5x the size of the smaller.
In the end, you and anyone else can make their own decisions on how/what to bring into their projects. That said, all of the charting libraries mentioned (I only looked at a few of them, admittedly) are considerably larger than I would consider for *MOST* applications. I know a lot of people are fine sending many megabytes of various modules/libraries down to the browser and either don't know or care about the impact/overhead. I know a lot of others that go to the opposite extreme, working hard to keep delivery under 30-50k max. I'm a bit more pragmatic, and even then these charting libraries are over the top for me.
material-components vs material-ui ... The name of the design style is "Material Design". material-ui is a React component library that implements Material Design. material-components is a Web Component library that implements Material Design. material-ui for React is the most popular material design library.
The only thing I really hate about all of them, is they are huge monolithic libraries and upwards of a meg of JS because you can't pluck out just enough for say a pie chart with overlays.
While I agree with the sentiment... I'd add a couple things. First, you should have a global error trap (for client side apps/spas) that blows up the world, logs to the console and replaces the entire body content with a generic error. This ensures you are properly capturing errors. This should include the same error trap inside your main react component. By doping this, you can then prioritize trapping expected error conditions to avoid the fallback, while always having a fallback. Too many applications blindly swallow, or worse don't handle uncaught errors (promises, react render, global error handler). If this is a Node application, also stop the world, log, wait a full minute then restart. Second: always have a *UNIQUE* code for each location in code where you may raise an error condition for your own errors. This allows you to track down where it was raised quickly... If you are bubbling up... catch(error) { // catch and ensure a unique code is attached for // finding where errors are coming from. throw Object.assign(error, {code: error.code || 'UNIQUEID' }); } Yes, you should absolutely display better error messages to the user... however, too many application projects I've come into don't even get the basics down right first.