DEV Community: Renato

Will Bun.js replace Node.js?

Renato — Wed, 28 Feb 2024 23:01:41 +0000

This is a question that often surfaces whenever a new technology emerges. Recently, this buzz has been around Bun.js v1, reminiscent of the curiosity and debate when Deno.js was introduced. Understanding the nuances of such technological shifts is crucial, and here's my perspective on it.

Introducing Bun.js

Let's delve into what Bun.js is and the reasons behind its growing popularity:

According to the official documentation, Bun.js is "an all-in-one JavaScript runtime & toolkit designed for speed, which includes a bundler, test runner, and a Node.js-compatible package manager." What sets it apart from Node.js is its foundation in Zig and utilization of JavaScriptCore, offering significant improvements in startup times and memory efficiency.

Here are some key advantages of Bun.js:

Speed: Bun.js boasts a startup time that is four times faster than that of Node.js.
TypeScript & JSX Support: Directly execute .jsx, .ts, and .tsx files. Bun.js transpiles these into vanilla JavaScript, streamlining the development process.
ESM & CommonJS Compatibility: As the industry gravitates towards ES modules, Bun.js embraces this transition while maintaining support for the vast number of CommonJS packages.
Web-standard APIs: Implementing familiar Web APIs (fetch, WebSocket, ReadableStream) and leveraging JavaScriptCore, Bun.js offers a robust and standard-compliant environment, even utilizing Safari's implementations for certain APIs.
Node.js Compatibility: Bun.js is not just forward-thinking but also respects the vast ecosystem of Node.js, aiming for comprehensive compatibility with its modules and globals. Although this compatibility journey is ongoing, Bun.js continuously integrates more Node.js APIs, ensuring a smoother transition for developers.

The commitment to compatibility alongside innovation is what makes Bun.js a compelling choice for both new and existing Node.js projects.

Why the Hype Around Bun.js?

The excitement surrounding Bun.js is not just about its technical prowess. It represents a broader trend toward more integrated, efficient, and web-standard-compliant tooling in JavaScript development. By offering a single solution that encompasses a runtime environment, package manager, and test runner, Bun.js simplifies the developer's toolkit, potentially reducing the cognitive load and streamlining the development process.

Performance benchmarks

Bun.js has demonstrated impressive performance metrics when compared to established JavaScript runtimes like Node.js and Deno.js, especially in server-side rendering tasks for React applications. According to benchmark results shared in the documentation, Bun.js achieves almost 5x the speed of Node.js and nearly 2x that of Deno.js in similar conditions.

These benchmarks, performed under specific test conditions, highlight Bun.js's efficient handling of server-side rendering requests. While such performance gains are noteworthy, they can vary based on numerous factors, including workload characteristics and deployment environments. Readers interested in a deeper dive into these benchmarks are encouraged to review the detailed results and methodologies provided in the Bun.js documentation, ensuring a comprehensive understanding of its performance capabilities.

Production Readiness and Future Potential

While Bun.js showcases impressive performance and a promising set of features, it's crucial to recognize its status as an early-stage project. As with any new technology, adopting Bun.js in a production environment should be approached with careful consideration of its maturity and the specific needs of your application.

Current Limitations

Stability: As an evolving project, Bun.js may still be ironing out bugs and stability issues. Frequent updates and changes are expected as it matures.
Ecosystem Compatibility: While Bun.js aims for broad compatibility with the npm ecosystem and Node.js modules, there may still be gaps or edge cases that could affect complex deployments.
Community Support: The user and support community around Bun.js is growing but may not yet offer the depth of resources available for more established technologies.

Summary

In summary, while Bun.js may not be the go-to solution for every production scenario at this stage, its rapid development and the enthusiasm surrounding it suggest a bright future. Developers should consider experimenting with Bun.js in non-critical projects or development environments to gauge its benefits and watch its evolution with interest for potential future adoption.

Practical Example with Bun.js and Elysia

To demonstrate Bun.js's capabilities in a real-world scenario, I've developed a simple API using the Elysia framework, an elegant solution optimized for Bun.js. This project serves not only as a proof of concept but also as a sandbox where I've experimented with various features and integrations.

Key Features of the API:

Framework: Utilizes Elysia, a framework designed for efficiency and simplicity in Bun.js environments.
Logging: Implements advanced logging mechanisms to monitor and debug the API's behavior effectively.
Security: Integrates the helmet package to enhance the API's security posture against common web vulnerabilities.
Documentation: Includes Swagger integration for comprehensive and interactive API documentation, facilitating easier testing and integration for developers.

Explore and Contribute:

I encourage you to explore the API and delve into its codebase to see Bun.js and Elysia in action:

🔗 Check out the API on GitHub

Feedback, questions, or suggestions? I'm keen to engage with the community and discuss any thoughts you might have about this project or Bun.js in general. Your insights could provide valuable perspectives and contribute to further improvements.

Feel free to leave a comment or reach out directly. Let's explore the potential of Bun.js together! 😄

Getting started with Node.js API

Renato — Thu, 02 Sep 2021 20:46:25 +0000

Node.js API development powered by Express

Note: this post is not recomended for SSR or SR developers due to its simplicity.

Let’s start with a brief conceptual review 💪

First of all let’s talk a little bit about client-server architecture. This is a strongly used model to define a way to communicate one or more parts that request some services (clients) and one or more service providers (servers). First of them could be a website or in fact a mobile application, second of them could be a SOAP webservice, Rest API, among others.
We are going to explain one specifical server service called Rest API, in this opportunity applied with Node.js

Express at a glance 👀

This amazing framework will help you build a robust Node.js Rest API. It’s important to know that there are other options to take into account like Sails, Meteor, Happi, among others. In this case we will use Express which is the most used one but it doesn’t limit you to use other one. You can read the whole Express documentation here

Requirements 🛠

Node.js.
Nodemon (Optional), used to reload the Rest API when a change is introduced on your code. You can install it with npm globally: npm install -g nodemon, also you can use it with npx.

Installation ⚙️

Once the repository is cloned you should install npm packages to be able to run it. To achieve this, just open a terminal on root directory and run the following command:

    npm install

Let’s start with some code 💻

First of all, I will present the folder structure I chose. That’s so simply and I didn’t include some concepts like services or database acceses.

.
├── .env
├── .eslintrc.json
├── .gitignore
├── README.md
├── package-lock.json
├── package.json
└── src
    ├── common
    │   └── error.js
    ├── index.js
    ├── middlewares
    │   └── errors.js
    └── routes
        ├── index.js
        └── public.js

.env file contains environment variables and you must add this file because it won’t be pushed due to .gitigonore file. We will use API_PORT variable, then you need to add it just like API_PORT=20000 where 20000 is your desired port.
.eslintrc.json is used to follow some basic coding rules. You can use it or just ignore it.
.gitignore to defined everything you don’t want to push to git repository. Here is so import to add node_modules.
README.md just to show some information about the project.
package-lock.json keeps the packages dependencies tree tracked.
package.json has every needed dependency for this project.
src folder where will leave our core code.
- common folder to define common functions used along whole project.
- index.js that contains main API configuration.
- middlewares as the name says, contains every API middleware. In this case we only will use just one for error handling.
- routes folder where the API routing is defined. Here you can find every endpoint of the API.
  - index.js works like a routes mixer, just that.
  - public.js contains the unique endpoint we have.

Running ▶️

Once npm packages are installed you will be able to run the API. If you have installed nodemon you can run it with:

    nodemon ./src/index.js

Otherwise:

    node ./src/index.js

After this you should show a message like this on your terminal:

Node.js API listening on port: {Your port defined on .env}

At this point, you can go to your favourite browser, put http://localhost:{yourDesiderPort}/api/v1/en and check that the response will be:

{
    "success": true,
    "message": "Node.js API - Hello world"
}

Available endpoints ✔️

GET /api/v1/:lang where lang is related to a language code. The possible values are ['en','es', 'it', 'fr']. This endpoint will return a specific message depending on the language code sent.

Github repository link

You can access to the full code in this Github link

Thanks for reading! 🙌

Do we learn from mistakes/bugs? 💻

Renato — Sun, 18 Jul 2021 14:58:17 +0000

Introduction

Hi guys, how are you doing?
The main idea of this post is to talk a little bit about our experiences fighting with some bugs or mistakes we know and need to fix but at the end of the problem we learn something. Some of them are invalidating and we can't continue developing and others are just warnings but sometimes we really need them fixed.

I don't wanna motivate you to "learn from bugs/mistakes" because I think the best way to do it is from documentation, but due to my experience I guess we can learn from them.

To the point...

I have learnt a lot from some struggling situations, from coding to setting up an environment. I will give a simple example that could help you to understand what I mean.

I remember facing with Apache Cordova setting up issues a few years ago and with React Native some time after that. In both cases I had to read, to study and to find out a lot of info about that, not just a light search. That time I was using Ubuntu and it was too interesting for me find out how ~/.bashrc or ~/.bash_profile works, and $PATH as well.

Simple things maybe for someone with some years of developing experience, but I found it so awesome to learn from that situation.

Conclusion

This is just a simple sample, but do you think the same? do you learn from bugs/mistakes?

Thanks for reading 🙌 👋

Node.js - Getting started with Typescript

Renato — Sat, 24 Apr 2021 01:53:42 +0000

Hi folks! How are you?

This project is just a simple and conceptual REST API trying to get the best of Typescript on Node.js using MongoDB. In this case I've created just a proof of concept. In order to run the project, please go to the end of this post, where you can find out the GitHub repository link.

I will explain the main parts of the project and you can reply this post with any question you have.

Let's start with the project structure

.
├── README.md
├── docs
│   └── OBJECTS\ API.postman_collection.json
├── docker
│   └── docker-compose-dev.yml
├── nodemon.json
├── package-lock.json
├── package.json
├── src
│   ├── constants
│   │   └── index.ts
│   ├── controllers
│   │   ├── object.ts
│   │   └── public.ts
│   ├── index.ts
│   ├── interfaces
│   │   └── object.ts
│   ├── models
│   │   └── object.ts
│   ├── router.ts
│   └── services
│       ├── object.ts
│       └── public.ts
└── tsconfig.json

The root level files:

tsconfig.json: Typescript configurations (Visit https://aka.ms/tsconfig.json).
nodemon.json: nodemon configuration file.
package.json: project's dependencies.
package-lock.json: automatically generated that contains the dependencies' tree.

Folders:

/docker: used only if you don't have a MongoDB server and you wanna run it with docker. To achieve that you have to have Docker and Docker Compose installed and run docker-compose -f docker/docker-compose-dev.yml
/docs: there is a Postman json file that you can import to test the API.
/src: contains the core of the project.

Then inside of /src:

index.ts: define the API structure and routing and also set MongoDB connection.
/constants: constants that we need.
/controllers: manage and define the different routes, but they don't process any thing.
/interfaces: define the interfaces with data types.
/models: define the model we need to map to MongoDB.
/services: process information and connect to the db.

Notice that I'm starting using Typescript and I've just read a few pages about documentation and best practices. My main idea is to improve this code during the next weeks and also to start a kind of discussion with suggestions and comments.

Thanks for reading and have fun!
👩‍💻🧑‍💻

IMPORTANT: I was working based on this post mainly. Changes were inserted to improve some patterns according to my knowledge.

Get the full code on GitHub

Deno REST API / MongoDB or PostgreSQL

Renato — Mon, 15 Jun 2020 22:12:27 +0000

Hi folks! This is my first project working with Deno. It's only a 'getting started' kind of project with a simple Rest API and MongoDB/PostgreSQL connection.

Installation

First we need to instal Deno following this link.
In order to use MongoDB or PostreSQL we include them with Docker implementation (Install Docker and Docker compose). Otherwise you can use your own database engine, and obviously you have to change your connection string.

Features

With this simple project you will be able to test /users endpoints (GET, POST, PUT and DELETE). And you can decide which db use only adding the query string db=mongo or db=postgres.

Running the project

If you will use docker-compose you have to run on the root of the project:

docker-compose -f docker/docker-compose.yaml up

Await a few seconds until databases are ready and then run in another terminal window:

deno run -A --allow-net --allow-write --allow-read --allow-plugin --unstable index.ts

After this the server has to start and you will be able to make requests.

Repository

You can find the repository code here

Note: I'm working on this project and I will be adding more details and explanations. Let me know if you have a doubt.

Node.js REST API with Docker, Redis and MongoDB

Renato — Sun, 26 Apr 2020 14:51:50 +0000

Hi guys, this is my first post and I want to share a simple Node.js REST API (Express) that includes Docker, Redis and MongoDB.

You can run this project with docker-compose, we won't explain anything about it but you refer these links Docker and Docker Compose. Check the repo link at the end to be able to run the GitHub project.

In the file api.js, we use mongoose to connect to MongoDB server:

mongoose.connect(`mongodb://${process.env.MONGO_INITDB_ROOT_USERNAME}:${process.env.MONGO_INITDB_ROOT_PASSWORD}@${process.env.MONGO_CONTAINER_NAME}/${process.env.MONGO_INITDB_DATABASE}?authMechanism=SCRAM-SHA-1&authSource=admin`,
    { useNewUrlParser: true, useCreateIndex: true, useFindAndModify: false, useUnifiedTopology: true }
, (err) => {
    if (err) {
        console.log('could\'t connect to Mongo DB ', err);
    }
});

Inside libs/redis-client.js you can see the Redis connection:

const redis = require('redis');
const { promisify } = require('util');
const client = redis.createClient(process.env.REDIS_URL);

client.on("error", (error) => {
    console.error(`Error to connect Redis: ${error}`);
});

Then let's use it:
mongoose -> api/routes/users.js. (Check User schema inside models/user)

// retrieve users
let users = await User.find({}).lean().exec();

redis -> api/routes/users.js.

// retrieve user
const rawData = await redisClient.getAsync(req.params.email);
// save user
await redisClient.setAsync(req.params.email, JSON.stringify(user));

The repo is available at: https://github.com/renacargnelutti/express-mongo-redis

I hope you enjoy the post!
Let me know any question.