Anch’io non ho prestato molta attenzione a Webpack sin dall’inizio. Quando però mi sono reso conto che avrei potuto fare le stesse cose che facevo con Gulp, ma con molto meno codice e salti mortali, ho deciso di dargli una possibilità.
Immagina di svegliarti una mattina e di trovare una brutta sorpresa nella Search Console: centinaia di errori di scansione Google sul tuo sito web (URL non trovati).
Per qualche motivo hai eliminato diverse pagine senza sostituirle con il corrispondente Redirect 301. Oppure ti sei fatto migrare l’e-commerce ma nessuno ti aveva avvisato che bisognava impostare una strategia per redirezionare i link dei prodotti dal vecchio al nuovo sito.
Immagina anche che tu debba sistemare velocemente questi errori in modo che Google possa assorbire i 404 più in fretta possibile.
Mocha and Chai are the way to go when it comes to testing a Node API but I couldn’t resist to give Jest a try. Lately I’ve covered Test Driven Development by building a basic RESTful API. My goal today? Rewrite a bunch of tests by switching to Jest and async/await.
Looks like everybody is building chat apps with Socket.IO these days and while that’s completely fine, messaging applications are only the tip of the iceberg. Think a moment about it: there are literally a million of other things you can build within the real-time domain.
If you want to see an example, here’s something I’ve built recently: io-monitoring-proxy. It’s a minimal ExpressJs proxy for interacting with two monitoring APIs. The application makes a call to the APIs as soon as a Socket.IO client gets connected. The frontend is represented by a React application which is in charge for displaying the data in real time: io-monitoring-dashboard
In the following post I would like to explore some interesting use cases and hopefully give you ideas about what to build next with Socket.IO. We will start with some basic concepts all the way through exploring what Socket.IO and React can do for us when paired together.
By the end of the article you will build a super simple real-time application:
That will be quite a long post! Grab a cup of tea and take a seat before getting started!
In this post you will see how building an API with Ruby on Rails can be fast and delightful at the same time. But first, a bit of backstory.
I was building a small app for a client lately and I found myself in the need to rapidly create a prototype before moving on to the serious stuff. I said to myself “let’s try Laravel for this project!” and I thought I could use VueJS too, which is integrated inside Laravel, to build the frontend of the application. I know, having the frontend and the backend inside the same basket is far from ideal but I was in a rush.
While everyone seems to agree about the fact that premature optimization could be detrimental, you must care about performances either way: in the most simplest case you may want to know how much memory a given Node.js process uses during its execution.
In this post we will see how to use a Node.js builtin method in order to gain knowledge about the memory usage of any given process.