Paolo Insogna's Slidesets

It is a well-known fact that if bees go extinct, many things in the world (if not the world itself) would disappear.

The same goes for third-party APIs (which, with a horrible pun, translates to bees in Italian). Most of the time vendors providea SDK for your language to interact with their API. While this speeds up productivity, it slows down performance and makes you dependent on SDK bugs or supply chain vulnerabilities, that are not always addressed at the speed you would expect. Moreover, you never deal with the API directly and this removes the pressure to vendors for a developer-first designed APIs.

In this talk, I will show how most of the time you don’t need an SDK since you can easily code everything you need by yourself using a simple HTTP call.

You started creating a new amazing framework, or library, or proof-of-concept. Then you are amazed by your work and want to enable other to use it. A new Open Source Software (OSS) is just born and you are now responsible for it.

Not too late, new people start using, and contributing to it. The community grows and with it, its maintenance burden and complexity. If only you knew which good choices to make from the very first day…

Fear no more, this talk will give you a pletora of good indications and advices on how to breed a healthy OSS community from the very first day.

Every time we send a message on the most popular messaging platforms, we want to make sure that our communication is private and inaccessible to malicious users.

We also want to ensure that in case of a data breach, the messages will be encrypted so that no one could potentially easily decrypt them. But how do we do that?

How does end-to-end encryption work, and is it really that secure?

In this interactive talk, we will see how to make our communications secure by implementing one of the most popular e2e encryption algorithms... with some help from the public!

GraphQL is powerful technology to retrieve and send complex structures from remote locations with a simple and effective syntax. One of its perks is avoid under-fetching and over-fetching as the client specifically requests the fields it’s interested in.

But what happens if we need to enrich or customize the data set and we can’t modify the upstream GraphQL server? Shall we break the spec?

In this talk I will show you how to use the resources the GraphQL specification already gives us to solve this issue without having to break the rules.

No developer is an island and no developer is perfect. This means that you cannot create anything without using components written by someone else and these components will have defects or missing features. At some point in our life we all asked for support to someone else.

But being a maintainer is not an easy task at all. Think about receiving tons of reports with partial or missing information, or being yelled by strangers for not being responsive or fast enough.

For the health of our industry we must love our maintainers more: in this talk I’ll show how to politely ask for help and how to make sure you provide all the necessary informations.

In our daily studying effort, we all read article, blogs, books, watch video or attend conferences to learn something new about this bizarre industry we live in.

But we are not only developers and we have a life far from our keyboards. If we bring our other passions and philosophies in our coding experience we reach a broad new set of possibilities.

For instance, I’m a martial art practitioner (Which one? No spoilers!) and I recently started noticing that when I bring that art principles in my coding activities I get unblocked much faster. In this talk I will show how.

Node.js HTTP parsing currently relies on llhttp, a parser which provides very good performance but has currently some challenges for the health of the runtime.

Is it possible to create a modern, maintenable, well documented, secure and performant alternative? Yes it is!

Let me introduce you Milo, a new Rust based HTTP parser which I plan to integrate into Node.js and let me show you how you can help be a part of its first Rust component.

Despite being 30 years old, QR codes have only recently started becoming widely used in mainstream applications, thanks to the availability of mobile phones and ease of implementation.

Have you ever wondered how these codes work? How hard would it be to implement a rendering service?

Bear with me on this amazing journey where I will show you how Platformatic makes it very easy to create a QR code rendering service in just a few minutes.

Web applications are commonly vulnerable to several Distributed Denial of Service attacks, sometimes in unexpected ways. An example is the SlowLoris attack, an exploit that leads to service interruption by simply sending the data to the server as slowest as possible.

In this talk I will tell the tale of how it took almost 13 years for Node to be completely protected by SlowLoris attack. I will also show that sometimes prioritizing performance can lead to incorrect fixes that can result in a false sense of protection.

When going online and searching for new gadgets for our home, we often find Alexa, HomeKit or Google Assistant compatibility badges. Are these compatibility layers hard to code? What if I want to code mine?

The truth is that every gadget that is connected to the internet is probably speaking to an HTTP or MQTT API. And this means you know how to use it.

In this talk, I will show you how I easily made my cat’s life way technological.

It is a well-known fact that if bees go extinct, many things in the world (if not the world itself) would disappear.

The same goes for third-party APIs (which, with a horrible pun, translates to bees in Italian). Most of the time vendors providea SDK for your language to interact with their API. While this speeds up productivity, it slows down performance and makes you dependent on SDK bugs or supply chain vulnerabilities, that are not always addressed at the speed you would expect. Moreover, you never deal with the API directly and this removes the pressure to vendors for a developer-first designed APIs.

In this workshop, I will show how most of the time you don’t need an SDK since you can easily code everything you need by yourself using a simple HTTP call.

Have you ever wanted to contribute to a foundational open source project like Node.js? Maybe you don’t know where to start. Maybe you always assumed that was work reserved for “someone else.”

Join experienced contributors who will guide you through your first (or second or third or fourth) commit to the Node.js core. They will be available to help troubleshoot any development environment issues and also to provide guided tours through specific areas of the Node.js core source code.

Contributors of all skill levels and experiences are welcome (not every contribution has to be a code change).

Come and make your first Node.js core contribution!

In the last years, the JavaScript ecosystem has grown exponentially.

With it, many different compilers and build systems came to life to compete to reach the best possible performances, better stability, and compatibility with the language features.

While five years ago, we had a few choices for compiling and bundling JavaScript (for either client or server), today, we have many good alternatives. ESBuild, SWC, Vite, WebPack... what are the differences between those tools? How do I choose the right one for my project?

What can we predict about the future of the JavaScript ecosystem?

web3.storage is a system living on top of Interplanetary File System (IPFS) to provide non technical people access to a completely decentralized file sharing network designed to preserve and grow humanity's knowledge.

The massive success of the initiative quickly brought the system to a point were it was not able to handle the growth. Uploaded files were only available for downloads after several days due to limited capacity. Adding new processing nodes took literally days due to the complex bootstrap procedures mandated by the different network protocols involved.

In this talk I will show how we have been able to migrate to a new fully stateless system by carefully making assumption and leveraging AWS services. We developed a system that now can perform infinite horizontal scalability and it is able to consistently handle millions of uploads per day.

Node.js HTTP relies on llhttp parser, which is a both a semi-obscure piece of code and semi-abandoned project.

As the parser is a critical part of Node.js, do we have better alternatives for easier maintainability? Let's find out.

Thanks to a community of passionate contributors, Node.js is constantly evolving. Streams have been a core feature since the beginning but are still very much in active development.

In this talk I will guide the audience through the changes that have been added in the last five years of Node.js development and how they impacted performance. Do you already know how to use them properly?

Finally I’ll introduce readable-stream v4.0.0, a full refactor which brings all these changes to user-land, regardless of the Node.js version installed on the system.