DEV Community: Ayoub Alouane

MuleSoft Associate Certification: Essential Tips and Key Concepts

Ayoub Alouane — Mon, 16 Sep 2024 21:22:01 +0000

I was a little stressed, do you know why? Because I forgot the date of the exam. Fortunately, I had a small reminder from my agenda 30 minutes before the exam. I tried my best to quickly review the documentation I wrote when I was preparing for the exam.

Make sure to have a good internet connection, and it might be helpful to restart your laptop. This will close all running programs that could potentially interrupt the browser required for taking the exam, which you will need to download before starting.

The first thing you should know is that the associate certification tests your knowledge of Enterprise Integration concepts. You need to understand why we use MuleSoft, not just how to implement a listener and an object store. These technical details are important but not sufficient for the associate exam.

It's also about your knowledge of cloud solutions. Having a good understanding of the differences between SaaS, PaaS, and IaaS, and knowing when to use them, will be beneficial. I can say that I had two or three questions about cloud solutions, including CloudHub and PCE. You should understand the differences, as well as the why and when of using these solutions.

Before starting the exam, make sure you are familiar with the structure of a YAML file. You might have a question about that, as well as about JSON and XML. Additionally, review communication protocols such as gRPC, REST, and SOAP. There will be questions on these topics as well.

Understanding systems such as Supply Chain Management (SCM), Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), and Content Management Systems (CMS) is crucial. You should know the purpose of each system and read some scenarios of their use to have a solid understanding of the differences between them.

Knowledge of project management methodologies is essential. You should understand what Kanban, Waterfall, Agile, and Scrum are. These concepts might seem irrelevant for a MuleSoft certification, but they are not. You will get at least one question about these concepts, so don't forget to review them.

A thorough understanding of Integration Patterns, such as Consolidation, Orchestration, Aggregation, and Choreography, are unavoidable. A good understanding of these concepts is required because the exam focuses heavily on them. My advice is to thoroughly read about each one and try to implement them, which will give you a solid understanding of these patterns.

Finally, ensure you know the components of the Anypoint Platform including Anypoint Exchange, Anypoint Runtime Plane, Anypoint Control Plane, Anypoint Runtime Manager, Anypoint API Manager, Anypoint Design Center, and Anypoint API Designer...Knowing the use of each component will help you answer at least three or four questions in the exam.

From Disconnected Chaos to Unified Systems: The Evolution of Enterprise Integration

Ayoub Alouane — Sun, 25 Feb 2024 22:08:02 +0000

Introduction:

Before explaining what an ESB (Enterprise Service Bus) is, we should establish some context. The first question to ask is: What brought us to here? The answer is not simple because it depends on problems that perhaps modern developers have not faced.

If you are working in a large company, you might constantly wonder how you arrived at the current state and what might have been overlooked. If you're an architect, or someone with a role that's complex to define, by examining multiple projects within your company, you'll notice that applications have cohesion among them. Yet, they are designed as if this isn't the case. This is often due to a lack of long-term vision. If these applications need to share information with each other, we're faced with a difficult technical and management process, because each app belongs to a different department and may be developed using different programming languages and tools. Here, I'm trying to highlight the importance of SOA (Service-Oriented Architecture).

Perhaps members of the hierarchy are hesitating to collaborate and discuss their apps, but they need to, because they should offer a good service to the user at the minimum cost, otherwise, another company will.

How could we integrate apps in the past?

When talking about sharing information (messages) between apps (services), we're not referring to someone who will write information on a sheet of paper and send it to a member of another team, who will then manually input it into their app. That method is inefficient, that's not what we're considering. We are trying to find a modern way to transfer messages that need to be secure, reliable, monitorable, manageable, and, finally, loosely coupled. It means that we should integrate our applications into a system so that they can communicate and share messages.

But, when you're reading this article, do you think that we started with a perfect solution? Of course not, so let's take a deep dive into history.

Point-to-point integration

Point-to-point integration was the first method employed to achieve integration between apps. Before I explain how it works, here is a figure that illustrates how point-to-point architecture functions:

The point-to-point integration approach connects two apps with a direct relationship. Imagine we want to establish communication between house 1 and house 2 using a P2P connection, we would have a direct line between the two, It means that if the line goes down, we will lose the connection between the two houses, herefore, we cannot confidently say that we have a reliable system. If we wanted to add house 3, we would need to add additional lines between houses 1 and 3, and 2 and 3, This means that our houses are tightly coupled. It's also insecure because we have a direct relationship, which becomes a single point of attack for spying on our data. Moreover, it's non-monitorible because we can't easily keep track of our communications due to the lack of a central monitoring system. And finally, it's non-manageable because managing direct lines between a large number of houses is challenging.

Now, we can draw a parallel between houses and a service-oriented architecture. For instance, as seen in figure 4, service CRM is directly coupled to Sales, and HR is directly connected to Finance. This setup is risky because if we make changes in the Finance service, we must initiate a new integration process to adapt the all other services. And that's a laborious task to undertake each time we need to make modifications to the services.

So, is this approach still applicable? Clearly not. After P2P, we moved on to something called Central EAI (Enterprise Application Integration) broker, which is a better approach. Let's explore this in the following paragraphs.

Central Enterprise Application Integration Broker

To be clear, this approach resolved all the P2P issues by connecting applications through a centralized system, and that's the key word: centralized. So, if we want to benefit from this approach, the leaders of each project or service must give up control to a centralized infrastructure where each service is integrated. Thus, our system will be secure, reliable, loosely coupled, monitorable, and manageable, but we will lose some control over our services.

Perhaps this seems a bit complicated, let's simplify it with a real-world example. Imagine our city has a single central post office instead of each person delivering their mail directly to recipients (P2P). Now, we need only to have the address of each recipient and send the mail to the central post office, which has complete control over the delivery process. This centralization ensures a secure process because the post office has invested in reducing the risk of theft or loss to a minimum. Additionally, the post office can easily monitor and manage mail through a system that keeps track of every parcel sent and received. This method is an improvement over the previous system, which was established to expedite mail delivery. If necessary, the post office will establish new processes to ensure delivery without involving the sender and the receiver in these issues.

Just like the post office, the centralized EAI broker features a central hub responsible for the routing, security, monitoring, and transformation of data to ensure it is in a format that can be understood by the receiving service.

Like we see, this architecture is great, it solved all of the P2P problems, but it created new ones. We now have a single point of failure, if the central hub id down, all the communications will fail, and it's really difficult to communicate with a service that we can't integrate into our centralized EAI broker because it's an external one that doesn't belong to our company.

Conclusion

Now that we have reviewed the approaches we had in the past, in the coming articles we will cover the modern ways to integrate our services, without having the issues we faced previously.
To give you a hint, imagine that instead of having a single centralized post office in our city, we have multiple small post offices that do the work and can scale if the city grows.
See you in the next articles of this series.

The Sisyphean Quest for Web Performance

Ayoub Alouane — Tue, 29 Aug 2023 13:23:42 +0000

It's been more than 12 years since we started using SPAs (Single Page Applications). This approach was revolutionary for DX (Developer Experience). However, in terms of web performance, we experienced a decline unlike any seen before, leading to catastrophic times for interactivity. Even now, we see this issue with applications built using frameworks that solely rely on SPAs. These frameworks have tried to improve their rendering methods. In this article, we will explain the evolution of rendering on the web, culminating with a spotlight on a new rendering technique that many believe will revolutionize web performance.

The history of web development often begins with a total SSR, PHP & JQuery, for example. During those times, DX (Developer Experience) was challenging, and riddled with errors, and the code was complex and difficult to debug. While this article won't delve extensively into those aspects, it's worth noting that these tools offered developers complete autonomy over their application's architecture. Thus, any performance issues were often the result of mistakes in their code. In contrast, with SPAs (Single Page Applications), it's usually the framework itself that becomes the root cause of major performance problems.

Client Side Rendering (CSR)

Single Page Applications (SPA) marked a significant shift in web development, a true revolution in building web apps. Initially, we were thrilled with the outstanding UX it provided. However, as time progressed, we began to encounter performance bottlenecks because we have started to use SPAs for startup critical applications such as ecomerce, where startup matters a lot . Our apps took longer to become visible and interactive. Often, users were greeted with a blank screen at the start, forced to wait. The more our apps relied on JavaScript, the longer these delays became. Regrettably, as we scaled our apps, we often sacrificed performance. This increasing complexity largely stemmed from one root issue: JavaScript's limitations.

The question here is, it's because of what? it's because we should wait for the browser to download, execute, and render all the javascript of our application, to be visible and interactive, this figure shows us how it works:

Image Source: https://www.youtube.com/watch?v=k-A2VfuUROg&feature=youtu.be

To address these performance challenges, we experimented with various methods like lazy loading, preloading, and code splitting. However, as history would have it, these enhancements proved insufficient.

Server Side Rendering (SSR)

As previously mentioned, SSR is a traditional method of rendering. However, it became essential to revisit this approach to tackle certain challenges. The primary concern was performance, prompting a reimagined approach to how SSR operates.

After addressing the SPA issue, frameworks such as Angular and React sought to enhance their method of delivering page content to the browser. Instead of sending a blank HTML and then downloading the JavaScript for the entire web app to execute, they choose to generate the webpage on the server. This server-rendered page contains HTML, CSS, and also data from a database or an API. Once this is sent to the client, we have a page that is visible, completely visible, but unfortunately not interactive, so the JavaScript should be delivered and executed on the client side in order to add handlers to the DOM nodes, it meas that our page will be visible twice. This process is known as hydration, re-executing of application code in order to make the static page interactive. In simpler terms, the DOM will be "hydrated" with JavaScript.

Image Source: https://developers.google.com/web/updates/2019/02/rendering-on-the-web

the Time to Interactive is comparable to that of an SPA, if not longer, due to larger HTML payload. This marks the beginning of an extensive journey during which all frameworks will strive to optimize the hydration process as much as possible.

Static Site Generation (SSG)

For websites focused on content that requires minimal interaction and feature content that doesn't frequently change, SSR might be an overkill. It can hinder the Time to First Byte, and CSR might negatively impact our Core Web Vitals. This calls for an alternative method, introducing Static Site Generation (SSG). With SSG, an HTML page is produced during build time for each potential route. So, if there are 3,000 articles, an individual HTML page will be generated for each during the build phase.

Image Source: https://www.patterns.dev/posts/incremental-static-rendering

This approach appears to be efficient with great performance, but it's clear it has a drawback. For instance, every time a new article is created in the database, the entire website must be rebuilt and redeployed for that article to become accessible to users, here comes another approach.

Incremental Static Site Generation (iSSG)

The name is clear, and the goal is clearer, iSSG is to fix the problem that we had with SSG, we don't need to rebuild and redeploy our websites, with iSSG we will be able to add new pages and also update existing pages.

It's important to note that SSG or iSSG is best suited for sites that require minimal interactions and don't frequently update page content. While these rendering methods excel in terms of SEO and performance, they aren't ideal for web applications that demand extensive interactions with APIs or frequent changes to the page's state.

While these methods aim for peak performance, they don't fit every scenario. Hence, a more versatile approach that addresses a broader range of cases is necessary.

Progressive Hydration

The concept of progressive hydration in SSR is straightforward: enhancing the hydration process. With traditional Server-Side Rendering, while the page is visible, it isn't interactive – meaning buttons won't function initially. This is because we must wait for the entire JavaScript code to be downloaded and executed on the client side. However, progressive hydration, as its name implies, allows for the step-by-step hydration of our page. This means the hydration occurs node by node within the DOM. As a result, some buttons may become interactive immediately, while others lag behind due to the ongoing hydration process. Once this process concludes, the entire page achieves interactivity.

Image Source: https://www.patterns.dev/posts/progressive-hydration

This method is good, but it still uses hydration, just in a better way. The challenge is guessing which part of the page a user might interact with next. It's great that users can quickly use parts of the page, but they might have to wait if they want to use other parts. They won't get full interaction until the whole page is ready.

Streaming Server-Side Rendering

We've just delved into progressive hydration, where the DOM is hydrated step by step. Now, picture a scenario where the entire rendering process for the web page, including HTML and CSS, is also done progressively.

Image Source: https://www.patterns.dev/posts/streaming-ssr

With this method, we send chunks of HTML and JavaScript to paint the user interface as quickly as possible. This ensures that users can interact with parts of the page almost immediately. This technique is effective in minimizing the Time to First Byte (TTFB), which is beneficial.

Selective Hydration

Every server-side rendering technique we've discussed so far has its merits, but they aren't one-size-fits-all solutions. Consider a page we want to render using SSR that has a component requiring data on its initial load from an external API. This means there will be a delay in rendering the HTML on the server, which isn't ideal.

Enter Selective Hydration. Instead of halting the entire page's rendering while waiting for a data-intensive component, this approach sends other components to the client first. These components are rendered and made interactive while the browser awaits the server-fetched data for the specific component in question.

Image Source: https://github.com/reactwg/react-18/discussions/37

Clearly, the hydration process for other components continues uninterrupted. This method boosts performance without negatively affecting other parts of our website.

React Server Components

In the React world, this marked a revolutionary shift. RSC introduced a new approach to building web apps, transforming how components are managed and rendered more efficiently and effectively.

RSC is more server-centric to enhance the client-side rendering, delivering only what's necessary. For exemple, if a component should only be visible under a certain condition, instead of making that decision on the client-side, it can be determined server-side. This avoids sending the component to the client, benefiting web performance since there's no need to download and execute a component that will never be displayed.

RSC has a zero-bundle size, allowing us to render static content that might have previously required JavaScript libraries for construction. In the past, this was done client-side, using libraries for content that didn't need interactivity. With RSC, we can handle this server-side, producing only static content with no additional bundle size.
For more details: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#zero-bundle-size-components

With RSC, we gain secure, full access to the backend, as server components are never delivered to the client. This approach allows us to fetch data directly from the database, eliminating the need for an endpoint.
For more details: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#full-access-to-the-backend

RSC enhances both user experience (UX) and developer experience (DX). In RSC, all imports automatically become code-splitting points, eliminating the need for additional configuration. This not only facilitates the developer's work but also boosts performance, as the server determines whether or not a component should be rendered.
For more details: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#automatic-code-splitting

To deep dive in RSC you can consider reading this RFC: https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md

Islands Architecture (Partial Hydration)

Now we are in a new era, an era of 0 JavaScript, the Island Architecture, It's a new way of building websites without having the need to hydrate all our website in the first load, this concept of Islands Architecture was popularized first by Astro Framework using a technique called Partial Hydration.

The concept of partial hydration allows developers to determine what aspects are loaded and when in order to provide fast interactivity. This is done by being able to put some client-side JS only where it is needed. Partial hydration definitely is a wise and practical strategy. Our webpage is initially sent as pure HTML from the server to the client. JavaScript is not shipped by default.

In the example of Astro, the guiding principle is to build Islands of Interactivity that the browser can hydrate on its own. We can optimize how the page loads javascript by treating each component (Island) independently.

Resumability

In our earlier discussions, we delved into how various frameworks aimed to optimize the hydration process. Hydration, traditionally seen as a bottleneck for website performance, has often been the focal point for improvement. Yet, instead of merely enhancing what's existing, it might be time for a revolutionary shift in our approach. The question isn't just about doing it faster but possibly about doing nothing at all.

Introducing "Resumability." The name itself gives a clue: to "stop and resume." This concept suggests picking up right where the server left off, eliminating the repetitive nature of traditional hydration processes. Resumability's primary goal is optimal performance, emphasizing minimalistic javascript and pure HTML.

Consider a contact form on the page's bottom. Traditional methods preload the necessary JavaScript, while partial hydration slightly improves this. But with Resumability, the JavaScript loads only upon direct interaction, such as clicking the send button. This innovative perspective, championed by the emerging framework Qwik, offers a fresh take on web app development, focusing on scalability without sacrificing performance.

If we try to think deeply about the figure above, we will understand the reel problem, scaling. If we have an extensive web application, it will take a lot of time to load with hydration.

How it is done in Qwik? in Qwik there is code extraction for optimizing performance. For each event on our page, a specific JavaScript file is linked. If an action isn't taken, like pressing a button, its JavaScript isn't loaded. Qwik doesn't only load files upon interaction.

After the initial interactive page load, it preemptively downloads the necessary javascript code for the current page via a service worker, storing it in the browser's cache. This prevents constant server requests. Instead, it pulls from the cache, or if not yet available, fetches it from the server—this is called prefetching. Unlike other frameworks that bog down initial loads with JavaScript, Qwik remains interactive without waiting for the JavaScript to be downloaded.

Using this approach, Core Web Vitals like FCP, LCP, and TTI experience significant enhancements directly through the framework, without requiring developer interventions or specific optimization techniques. In contrast, many other frameworks necessitate manual optimizations, from code splitting and lazy loading to caching and more.

Qwik takes away this pressure from developers. Instead of getting bogged down with configuration, they can focus solely on app development. The framework takes care of the rest, ensuring optimized performance. This innovative approach not only enhances user experience (UX) by improving performance but also streamlines the developer experience (DX).

For more details, you can read this article:

Qwik – The Post-Modern Framework

Ayoub Alouane for Playful Programming ・ Jul 11 '23

#javascript #qwik #frontend #typescript

Conclusion

In web development, the quest for the best web performance possible has been nothing short of Sisyphean. The evolutionary journey through CSR, SSR, SSG, and others showcased the industry's relentless pursuit of excellence. However, each approach had its limitations, and none seemed capable of fully overcoming the performance bottlenecks. Then emerged a glimmer of hope "Resumability.", offering a promising future where performance no longer feels like an uphill battle.

Article resources:

-https://www.patterns.dev/
-https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md
-https://dev.to/this-is-learning/qwik-the-post-modern-framework-3c5o
-https://dev.to/this-is-learning/astro-framework-169m
-https://developers.google.com/web/updates/2019/02/rendering-on-the-web
-https://web.dev/vitals/

The Future Is Here: Qwik Meets Prisma Innovatively

Ayoub Alouane — Thu, 17 Aug 2023 18:14:45 +0000

If you're coming from PHP, you have Doctrine. From JAVA, you have Hibernate. In Javascript and TypeScript, we have Prisma that allows you to do Object Relational Mapping by providing a type-safe and intuitive query API to work with. The Prisma team, best known for their work on "GraphQL Yoga,” introduced Prisma 1 in 2018, which was a GraphQL data access layer for databases, but in 2019 the team decided to change the vision and deprioritize GraphQL to have a more general solution for databases to cover more use cases. So 2020 was the year of Prisma 2.0. The team announced on different dates of the year the three primary components Prisma Client, Prisma Migrate, and Prisma Studio.

Prisma 2 Components

Prisma Client

Writing SQL queries will not be the case in Prisma 2. Prisma Client provides us with built-in intuitive API calls, which make it simple for developers to manipulate the database and execute complex queries using only pre-defined functions. Prisma Client has multiple features:

Type-safety: TypeScript is a type-safe programming language that ensures that we are using the data that we should use based on the defined types. Prisma client takes advantage of this because the generated TypeScript types are based on our database schema, so it will help us to catch errors at the compile time.
Intuitive API: it abstracts complex SQL queries into simple and clear functions, which gives the developer the ability to focus on the logic of his application.
Performance: Query batching is the key to having a great performance in Prisma Client. This feature enables Prisma to minimize the number of query requests made to the database by grouping queries and sending them as a single batched request to the database. The result of this is reducing the latency.

Prisma Migrate

Prisma Migrate is a special feature of Prisma. Using only files that we call “migration files,” we can implement the process of creating, updating, and managing databases using SQL commands. Prisma Migrate has multiple features:

Prisma Schema: it's the core of Prisma. It contains the information needed for our Database. It's a file “schema.prisma”, defined using Prisma Schema Language (PSL), used for migration file generation.
Migration Files: these are the files responsible for keeping the history and the actual state of our Database. Prisma Migrate can detect the changes that we make in our Prisma scheme and generates migration files for that.
Migrate CLI: it's a command-line interface that helps us to manage our migrations(create new migrations, apply existing ones, and also rollbacking).
Introspection: it's a feature that allows us to do reverse engineering by generating a Prisma schema file based on an existing database

Prisma Studio

Prisma Studio is a user-friendly Graphical User Interface that allows us to visualize and interact with our database. It supports multiple databases: PostgreSQL, MySQL, SQLite, and SQL Server. Prisma Studio has multiple features:

Data Management: it allows us to perform queries such (Create, Read, Update, and Delete), so with that, it will be easy to manipulate data using a graphical interface.
Real-time Data: with Prisma Studio, we can visualize changes in real-time. If a change occurs in the Database, it is automatically displayed on the graphical interface.
Cross-platform Compatibility: it's is available in multiple OSs Windows, macOS, and Linux, and also it has a web version that we can access via the browser that we use.

Brief Introduction to Qwik

Qwik is a framework created by the creator of Angular, Miško Hevery, with a collaboration of Adam Bradley, who created Ionic, and Manu Almeida, who created Gin Framework.

Qwik, the HTML first framework’s philosophy is clear: make the fastest possible time-to-interactive (to do it faster by doing nothing).

The framework delays the invocation of the javascript as much as possible and invokes it only when it is needed. The focus is on the first load.

If you want to dive deep into Qwik, we already have an article about it:

Qwik – The Post-Modern Framework

Ayoub Alouane for Playful Programming ・ Jul 11 '23

#javascript #qwik #frontend #typescript

Integrate Prisma to Qwik

Prerequisites

To get started with Qwik locally, we need the following:

Node.js v16.8 or higher
Your favorite IDE (vscode recommended)

App Creation

Using the Qwik CLI, we will start by starting a new Qwik Project:

npm create qwik@latest

To run the server, we will need the following command:

npm start

On port 5173, we will have our application running. Now we will install Prisma:

npm run qwik add prisma

After installing Prisma, we will have a folder added in the root of our project:

The core file where we will define our scheme is schema.prisma, in this tutorial, we will define a model named Company and another one named Employee, and we establish between them a relation of one-to-many, so a user can have one company and a company can have multiple employees, here is how we will implement it:

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

model Employee {
  id    Int     @id @default(autoincrement())
  email String  @unique
  company Company @relation(fields: [companyId], references: [id])
  companyId Int
  name  String
}

model Company {
  id    Int     @id @default(autoincrement())
  website String  @unique
  name  String
  descriptions String
  employees Employee[]
}

After modifying the file schema.prisma, we should run this command to update the migration files and create another one:

npx prisma migrate dev

Now we will try to seed some companies in the database. To do that, we will create a file called seed.ts in Prisma directory:

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

const companies = [
  {
    name: "Adservio",
    description: "Great Place to Work",
    website: "www.adservio.fr",
  },
  {
    name: "Adservio Academy",
    description: "Great Place to Learn",
    website: "www.adservio-academy.fr",
  },
  {
    name: "Iriguard",
    description: "Great Place to be Secure",
    website: "www.iriguard.fr",
  }
];

async function main() {

  for (const company of companies) {
    const { name, description, website } = company;
    const categoryData = await prisma.company.upsert({
      where: { website },
      update: {},
      create: {
        name,
        description,
        website
      },
    });

  }
}
main()
  .then(async () => {
    await prisma.$disconnect();
  })
  .catch(async (e) => {
    console.error(e);
    await prisma.$disconnect();
    process.exit(1);
  });

After that, we should add this line to the package.json:

"prisma": {
    "seed": "ts-node --compiler-options {\"module\":\"CommonJS\"} prisma/seed.ts"
  },

And finally, we should execute this command:

npx prisma migrate reset

If you get this error:

An error occurred while running the seed command:
Error: Command failed with ENOENT: ts-node --compiler-options {"module":"CommonJS"} prisma/seed.ts
spawn ts-node ENOENT

You should install ts-node:

npm install ts-node

After re-executing the command, to show the results, we can execute Prisma Studio with the command:

npx prisma studio

Here are the results:

Now we will create a route that will help us to create users. Here is the code of the index.ts of this route:

import { component$ } from '@builder.io/qwik';
import { routeAction$,routeLoader$, zod$, z, Form } from '@builder.io/qwik-city';
import { PrismaClient } from '@prisma/client';

export const useGetCompanies = routeLoader$(async () => {
  const prisma = new PrismaClient();
  const companies = await prisma.company.findMany();
  return companies;
});

export const useCreateEmployee = routeAction$(
  async (data) => {
    const prisma = new PrismaClient();
    console.log(data);
    const employee = await prisma.employee.create({
      data
    });
    return employee;
  },
  zod$({
    name: z.string(),
    email: z.string().email(),
    companyId: z.string().regex(/^\d+$/).transform(Number)
  })
);

export default component$(() => {
  const createEmployeeAction = useCreateEmployee();
  const companies = useGetCompanies();
  return (
    <section>
      <h1>Create User</h1>
      <Form action={createEmployeeAction}>
        <label>
          Name
          <input type="text" name="name" />
        </label>
        <label>
          Email
          <input type="email" name="email" />
        </label>
        <label>
          Companies
          <select  name="companyId" data-choose-theme>
            <option  value="0">Default</option>
            {companies.value.map((company) => (
                <option class="text-primary" value={company.id} key={company.id}>{company.name}</option>
            ))}
          </select>
        </label>

        <button type="submit">Create</button>
      </Form>
      {createEmployeeAction.value && (
        <div>
          <h2>Employee created successfully!</h2>
        </div>
      )}
    </section>
  );
});

In the creation, we should choose a name, an email, and the company. To get the list of companies, we used routeLoader$ with a findMany() that will return the list of companies. RouteLoader$ is good for having data rendered in the server and sent it to the client as a serialized HTML.

After that, we use routeAction$ to create a user after submitting the form. It allows us to perform submitting and return from the server a result to the client in order to update our UI.

Here are the results:

And if we click on company:

As we can see, Prisma Studio helps us to visualize all the relations between our tables.

Qwik and Prisma can be integrated easily, and with Qwik, we benefit from using routeLoader$ and routeAction$, which help us to have a great performance with an exceptional DX because, with these features, we don't have to keep track of which code we will execute in the server or in the client, the framework does that for us.

Unlocking Web Performance: Core Web Vitals Clarified

Ayoub Alouane — Wed, 09 Aug 2023 10:56:18 +0000

All of us nowadays are talking about web performance, it’s the subject that is taking the most important place in talks, blogs, and podcasts, everyone is trying to give his point of view on why it’s primary and how we can achieve it. We are also witnessing rising competition in the JS Frameworks field, the discussion now is only about performance rather than Developer Experience, which was the subject with SPA Frameworks, but fortunately, now we consider that DX is becoming an acquired value that no one needs to argue about. New Frameworks are showing their ability in having big scores in PageSpeed Insights.

Here is a tweet from the CEO of Vercel, who is showing how with NextJS we will be able to build websites with extremely great performance.

// Detect dark theme var iframe = document.getElementById('tweet-1687591561377525760-568'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1687591561377525760&theme=dark" }

Focusing on performance is an indirect approach to enhancing the User Experience, the user should have the best page load speed on our websites, he should not wait for a page to start loading, to be visible, to be interactive, and to be stable. These factors all play a part in what is known as Core Web Vitals, key metrics Google uses in its ranking algorithm. They are sort of standards that we will talk about in this article to test website speed. So developers utilize several performance testing tools such as GTmetrix or Google PageSpeed Insights to ensure that they respect the metrics to optimize their sites for better speed.

Why Web Performance is Important?

Engaging in a discussion about performance in general will not be significant without considering the real concern about it, the User, for whom we want to build performant websites, in other words without using political correctness the CONSUMER. To illustrate this we can draw a parallel to dining at a restaurant, Imagine you are in a restaurant, you ordered a beef bourguignon dish, you’re so hangry but you should wait 40 minutes for it, as the minutes tick away, your hunger grows, patience wears thin, maybe you will cancel your order within 15 minutes, maybe you will wait but vow never to return, you will share your disappointing experience with friends, write a bad review in google.

This scenario is remarkably comparable to the user experience on a website.

If a website fail to deliver a functional page quickly, the user's initial excitement can quickly evolve into frustration, a slow e-commerce website, for example, can lead the consumer to abandon his order and search for it on other websites, so like we can see performance is not only about technical issues but it’s a human phenomenon, an emotional state, and a psychological experience because it’s not about the website and what it’s offering, it’s about the user who searches for efficiency and immediate response. If we analyze for example apps like TikTok or Instagram Reels we will understand that users are searching for information in only 30 seconds, they don’t want to watch a documentary or a long video about a subject, a TikTok video with a minimum of seconds and a maximum of pieces of information that matches their needs.

But having Performance and UX as the main factors for building websites is not something coming from nowhere, in this article we will explore also how Google managed to establish these factors as important axes to respect when building websites.

History of Google's Website Ranking

Every website's goal is to appear on the first page of Google search results, perhaps even at the top of the list when users search for something related to the website's content. Google has the ability to define the criteria for displaying these results, and these criteria have been changing over the past few decades.

In the beginning, Google ranked websites based on links from other high-quality websites. For example, if you had a new website for your restaurant, it would likely have a low ranking because no one was linking to it. However, if a well-known blog with a large user base were to mention and link to your website in an article, Google would adjust its ranking, resulting in a higher placement in the search results.

But this approach was not efficient because there were a lot of spammers, so Google started implementing different methods such as keyword relevance and user experience and they did a lot of updates to chase websites who are spamming and buying links.

In the last years, Google decided to spotlight User Experience and Performance, so websites should not be slow or insecure to have a great user experience, for that, Google introduced Core Web Vitals in the game in 2020, which are a set of measures that give us a detailed view on the experience that will have a user in our website, and Google utilize them to rank results in Google Search. So to do things correctly from the start or to optimize an existing project we should have a deep understanding of Core Web Vitals.

Web Performance as a Criteria

// Detect dark theme var iframe = document.getElementById('tweet-1686013850791841792-993'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1686013850791841792&theme=dark" }

Yes, we should be concerned about Core Web Vitals if we worry about our users. Core Web Vitals are increasingly becoming a topic and a challenge for new frameworks, or more precisely, meta-frameworks. Meta-frameworks such as NextJS, Astro, or Qwik City are more concerned with improving the performance of web applications. These tools each have their ways of rendering, hydration, partial hydration, and resumability, but the purpose is the same: to make websites faster to provide a better user experience.

Now let’s deep dive into our main subject, Core Web Vitals. These are metrics that Google uses, like we said to judge if a website has good performance or not, if it has a good user experience or not, and if it should be well ranked or not.

Largest Contentful Paint (LCP)

This metric measures the time that website takes to render the largest area (element) of the page, for example, if we take the adservio.fr, here in https://pagespeed.web.dev it indicates the element that is considered as "Largest Contentful Paint”:

On our page the LCP takes 2,5 s, which is not good to have a performant website, after 2,5s the user will see most of the page painted, so he will say that the page is almost ready.

Cumulative Layout Shift (CLS)

This measures the score for a page based on the entire time a page need to stop moving or shifting elements around in the DOM. If for example, we have a website for e-commerce, but after finishing showing the page, suddenly we have a bar that appears at the top of the page and moves the page to the bottom, that’s not good if we want to have a better score. Here is an example from the ft.com, in first we have the page correctly but suddenly it moves down to show an ad (colored in red):

It’s all about unexpected element shifting that will occur on our page, we should not keep injecting new elements in the DOM.

So now we can imagine the nightmare that we will have with Single Page Application, and how the score will be catastrophic.

First Input Delay (FID)

That’s an interesting metric, FID measures the necessary time that we should wait between when the page looks ready and when the user can interact with it, which means when the browser can fire an event.

Page visible but not Interactive	After 3ms the page is interactive

If for example, we are working with frameworks that do hydration, we will show the HTML page that is rendered the first time with SSR, but we should wait to download and execute our javascript files in order to add the necessary code to each node of the DOM. After doing this reconciliation, we will have our page ready.

First Contentful Paint (FCP)

This metric is used to calculate the necessary load time for meaningful content to be visible, from entering the URL to having something on our page, not a blank div, something visible must be rendered, here we show an example:

Blank Page	First Meaningful Content

When a user sees something on the page, he feels safe, he is sure now that he will have a result, that the website is working.

For more details here is a link to look at.

Conclusion

Our Article now was an overview of how Google ranks websites, and we focused more on modern metrics, Core Web Vitals, to give an overview and simple explanation of each one.

This article is one of a series that we will have. In the next article, we will deep dive into Core Web Vitals, and tools to measure them. If you found this article helpful? Share your thoughts in the comments below or share it with your network!

The Power Of RUST: Introduction and Deep Dive in Advanced Concepts: Ownership, References and Borrowing.

Ayoub Alouane — Wed, 26 Jul 2023 23:35:18 +0000

Rust is a language created by an employee in Mozilla before 2010, but after this date the programming language was sponsored by the company, inspired by C/C++, but with more efficiency, compiled, strongly typed, safe and performant but without a garbage collector.

A language empowering everyone to build reliable and efficient software.
-rust-lang.org

Rust is used by multiple big companies like Mozilla of course, Microsoft and Dropbox, it’s used for a lot of cases, building web servers, command-line interfaces, native desktop application, web apps using WebAssemblly, and also for operating systems.

Having a safe and multithread language is already great, but with the maximum performance it will be greater, Rust is here for that, it’s a systems programming language with a compiler, so it’s not interpreted like javascript, it’s compiler is the key for having performant programs and a safe memory. Not only performance, Rust has also productivity due to the package of tooling that it has, like package manager, testing and documentation.

If just start using Rust, maybe you will find it complexe and not easy to understand, but the good thing about Rust is that it makes sure that you understand the concepts before using them.

In this article we will try to cover the basic and advanced concepts that differentiate Rust from other languages in order to give an accessible introduction to all developers who are trying to start coding using Rust.

Basic Concepts

How Mutability works?

The principal feature of Rust is that variables are immutable by default, it means that when we give a value to a variable, we can’t change it anymore, for exemple:

fn main() {
    let a = 7;
    println!("a is: {x}");
    a = 1;
    println!("a is: {x}");
}

If we run this code it will show an error “cannot assign twice to immutable variable a”, because we tried to assign a new value to an immutable variable, so the compiler is able to show us errors in the compile time in order to have a safe code. But maybe in other cases we will need a mutable variable, it's possible in Rust, but we should specify that in the code by adding the keyword mut, for exemple:

fn main() {
    let mut a = 2;
    println!("a is: {x}");
    a = 9;
    println!("a is: {x}");
}

The compiler in this case will not show us an error, because we specify that the variable is mutable, so we can change its value.

Now we have an understanding of how to define variables using the let keyword and how we can change its nature with mut in order to be mutable, but there is another keyword to define variables, its const, using this keyword will allow us to declare constants.

Maybe you will say that let without the keyword mut is already used for defining constants that will not change, but there are some differences:

Constants are immutable, always immutable, there is no chance that they will become mutable, we can’t use the keyword mut.
Constants must have there values in the compile time, they should not have values that we will be calculated in the runtime.
When we declare Constants we should annotate the type of the value.

Exemple:

const RESULT: u32 = 57 * 24;

You can notice that the variable has a specific naming, it’s the convention of naming constants in Rust. u32 is the type of the value that we assigned to the variable RESULT.

We should mention also that constants are also available in the scope where they were defined the entire time of the running of our program.

What is exactly Shadowing?

Another important concept, before introducing it, we should show an exemple:

Exemple 1	Exemple 2
let a = 4;	let a = 4;
let a = a * 2;	a = a * 2;

As we learned, we can’t re-assign a value to a variable defined with only let, it must be immutable, so the exemples that we have will show error normally, that’s the case for Exemple 2, but the exemple 1 is different, it’s not about re-assigning, it’s about declaring a variable with the same name of the last variable. In Rust we say that the first variable is shadowed by the second one, in other words, the second variable overshadows the first, it means that if we print variable a, we will have the first value multiplied by 2. But it’s also about scope, for exemple:

fn main() {
    let a = 4;
    println!("(1) a is: {a}");
    let a = a * 2;
    println!("(2) a is: {a}");
    {
        let a = a + 6;
            println!("(3) a is: {a}");
    }
    println!("(4) a is: {a}");
}
//result
Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 0.57s
     Running `target/debug/playground`
Standard Output
(1) a is: 4
(2) a is: 8
(3) a is: 14
(4) a is: 8

So, as we can see, a was equal to 4, but after re-declaring it, the first variable was shadowed by the second so it equals 8. Now, after opening an other scope we re-declare the variable, so the third variable will shadow the second, but after closing the scope, we returned to the previous declaration that we had in the parent scope.

In this process, we didn’t change the variable, we transformed the value, but the variable itself still immutable after any transformation that we can perform on the value.

We can also change the type of the value in the transformation if we want, but like we said we should use the keyword let in order to create a new variable but with the same name.

Introduction to Data Types

Data Types in Rust are really different, they have a specific syntax. the first thing that we should know is that Rust is statically typed, in other words we should specify the types of all variables at the compile time, Rust can also understand the typed of a variable based on the value that we assigned to it.

We have here two types of Data Type: Scalar and Compound:

Scalar

Single value: integers, floating-point numbers, booleans and characters.

Integers

In Rust there is Signed and Unsigned integers. Signed are integers that can be negative (they can have a signe), unsigned are only positive integers so they will never have a sign. Here is a table that illustrate multiple types:

Length	Signed	Unsigned
8-bit	i8	u8
16-bit	i16	u16
32-bit	i32	u32
64-bit	i64	u64
128-bit	i128	u128
arch	isize	usize

Floating-Point

Floating-point types are numbers with decimal points, they are always signed, there is no unsigned floating-points, and they have two types: f32, f64 (it’s the default type).

fn main() {
    let a = 6.0; // f64

    let b: f32 = 2.9; // f32
}

Boolean

In Rust Boolean Types are: true and false, to define a boolean we use the keyword bool.

fn main() {
    let condition: bool = true;
}

Character

The Character type is a primitive alphabetic type. In Rust we define char with single quotes, but string literals with double quotes.

fn main() {
    let a: char = 'B';
}

Compound Types:

Compound types in rust represent a group of values inside one type, in Rust we have two: Tuples and Arrays.

Array

In Rust an Array is a group of values that have the same type, and the group itself has a fixed length.

fn main() {
    let arr: [i32; 5] = [34, 51, 11, 42, 87];
    let result = arr[2]; // result = 11
}
// i32 is the type of the values
// 5 is the size of the array

Tuple:
In Rust a Tuple is like an array but it can have values with different types.

fn main() {
    let tup: (u64, f32, i8) = (902, 2.2, -1);
    let result = tup.1; //result = 2.2
}

How Functions works in Rust?

Functions in Rust are defined with keyword fn, main function is the entry point of our program:

fn main() {
    hello_adservio(28); //here we pass the value 28 as an argument
}

//Declaring the type of each parameter in a function is mandatory
fn hello_adservio(a: u32) { //the function here has a parametre of type u32
    println!("The age is: {a}");
}

fn main() {
    let x : u64 = multiply_3(5);// the function has a return value of type u64

    println!("The value of x is: {x}");
}

// '-> u64' means that our function has a return type of u64
fn multiply_3(x: u64) -> u64 {
        // we can see here that we don't have a semicolon ';' in the end of our ligne
    x * 3 
}

//result: The value of x is: 15

In this exemple, x * 3 has not a semicolon, so Rust will see it as an expression that will return a value, if we add a semicolon in the end of the line we will get an error:

Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
  --> src/main.rs:8:26
   |
8  | fn multiply_3(x: u64) -> u64 {
   |    ----------            ^^^ expected `u64`, found `()`
   |    |
   |    implicitly returns `()` as its body has no tail or `return` expression
9  |         // we can see here that we don't have a semicolon ';' in the end of our ligne
10 |     x * 3;
   |          - help: remove this semicolon to return this value

How OWNERSHIP Wokrs ?

What is Ownership

Being able to manage the memory is the key, Rust is able to test a set of rules through its compiler. These set of rules represent ownership, it's a new concept for developers, it may appear complexe but when we will have a deep understanding of how it works, we will be more productive and we will be able to make safe and performant programs.

Stack and Heap

Before talking about ownership rules, we should give a reminder about "stack and Heap". In a system programming language like RUST, we should have a total control over the memory, the stack and the heap, both are parts of our memory.

Last in first out is the definition of the stack, it’s the part of the memory where we push and pop data from, this data should have a fixed size. Therefore the Heap is for data with unknown size at the compile time. In the Heap we don't push data, we allocate the memory for it, so in other words, when we want to store data in the heap. The memory allocator will search for a place in the heap that can store this data, and it will return a pointer to it, this pointer will be stored in the stack, because its size is fixed, the pointer is the address for the data stored in the heap, after having a deep dive in ownership we will have a deep understanding of how the memory works.

Variable Scope

All variables have a defined scope, in where they are valid, exemple:

let a = "Adservio";

The variable is a String Literal type, it's valid when it is between the brackets, the a variable is immutable, so it's stored in the stack. In order to go deep in ownership we should choose another exemple, STRING type, can be mutable, so we can change it in the runtime.

let mut a = String::from("Adservio");

a.push_str(", Great Place!"); 

println!("{a}"); // this will print `Adservio, Great Place!`

The variable now is mutable, so in order to support a size that can be changed in the runtime, we should allocate memory in the heap.

Now I should throw a reminder, RUST doesn't have a Garbage collector, so in programming languages that has a GC, the GC will take the responsibility to free the memory from a variable when it detects that it will never be used, but in languages that don't have GC, it's up to us to free the memory when we identify that the variable will never be used, but if we forget, the variable will be always there occupying the memory for nothing, so we will have a wasted memory.

Rust is different, it has not a GC, but it manage to do that for us, its approach is to free the memory automatically when the variable go out of scope by calling a function called drop.

Deep Dive in How variables work

Starting with a simple exemple:

let a = 7;
let b = a;

Variables a and b are immutable, so they will be stored in the stack, because they are integers that have a fixed size, so we will create a variable a with the value 7, copy this value and assign it to b, so we have two variable with different data, now let us look to another exemple that will give us a different case:

let a = String::from("Adservio");
let b = a;

We know that String variables are mutable, so the variable a is made of 3 things, the pointer, the length and the capacity, but now we will have a focus on the pointer. The pointer is stored in the stack, the value of the string in the Heap. Now, we assigned the a to b, so we copied the pointer but without copying the data in the Heap that the pointer refers to.

So the two pointers now point on the same value in the heap, the question that we will have now, is if the variable a goes out of scope, normally Rust will free the memory by calling the function drop, the error here is that we will clean a value that is used by other pointer. Another case is that both variables a and b go out of scope in the same time, so Rust will try to free the memory twice, it’s called “double free error”. So what is the solution? In order to have a safe memory, Rust will invalidate the variable a, so after its assigning to the variable b, we will no longer have access to the variable a. Exemple:

fn main() {
    let a = String::from("Adservio");
    let b = a;
    println!("The value of a is: {a}");
}

Result:

Compiling playground v0.0.1 (/playground)
error[E0382]: borrow of moved value: `a`
 --> src/main.rs:4:35
  |
2 |     let a = String::from("Adservio");
  |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait
3 |     let b = a;
  |             - value moved here
4 |     println!("The value of a is: {a}");
  |                                   ^ value borrowed here after move
  |
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let b = a.clone();
  |              ++++++++

The error generated by the Rust compiler suggested us to do “let b = a.clone();” which is a deep copy instead of “let b = a;” which we called a “move”, the variable a was moved into b.

Rust is here for better performance, so it will never decide to go by default with a deep copy because of the cost in term of the runtime performance (for values stored in the Heap).

Another case, for types like integers that have a fixed size, the variables are stored completely in the stack, so their copying is not expensive. This code will not have errors:

fn main() {
    let a = 7;
    let b = a;
    println!("The value of a is: {a}");
    println!("The value of b is: {b}");
}

How Functions Work with Ownership

Assigning a variable to another is like passing a variable to a function, it works with same concept, Exemple:

fn main() {
    let a = String::from("Adservio");  
    print_var(a); 
    println!("{a}");            
}

fn print_var(value: String) { 
    println!("{value}");
}

Result:

Compiling playground v0.0.1 (/playground)
error[E0382]: borrow of moved value: `a`
 --> src/main.rs:4:14
  |
2 |     let a = String::from("Adservio");  
  |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait
3 |     print_var(a); 
  |               - value moved here
4 |         println!("{a}");            
  |                    ^ value borrowed here after move
  |
note: consider changing this parameter type in function `print_var` to borrow instead if owning the value isn't necessary
 --> src/main.rs:7:21
  |
7 | fn print_var(value: String) { 
  |    ---------        ^^^^^^ this parameter takes ownership of the value
  |    |
  |    in this function
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
  |
3 |     print_var(a.clone()); 
  |                ++++++++

The code will throw an error which is normal, because the function took ownership of the value of a and Rust will automatically invalidate it. We have an other exemple for integers:

fn main() {
    let a = 7;                      
    print_var(a); 
    println!("{a}");
}

fn print_var(value: i32) { 
    println!("{value}");
}

This code will work normally, it will not throw an error. Like the exemple of assigning integers. The function will not take ownership.

References and Borrowing

To start this part, we should have an idea about how return values work in Rust, the question here is returning a value from a function can transfer ownership? the answer is a big YES, here is an exemple:

fn main() {
    let a = init_value();
    let b = String::from("Group");  
    let c = takes_and_gives_back(b);  
}
fn init_value() -> String {       
    let value = String::from("adservio"); 
    value                              
}
fn takes_and_gives_back(value: String) -> String { 
    value
}

Looking now in the main function, we start by initiating a variable called a, we give it the value returned by the function init_value(), so here we have the function moving its owenership of the value returned to the variable a.

Now let us define a variable b that we will initiate with the value “Group”, and we define now a variable called c, that will get the returned value of the function takes_and_gives_back(b) that will took b as argument, here the function takes_and_gives_back() took ownership of the variable b, and returned a new value and transfer it's ownership to c.

So, is that the only way to keep using a value? by transferring ownership? The answer is NO, Rust has a feature called references.

let us took another exemple now:

fn main() {
    let a = String::from("adservio");
    let b = calculate_length(a);
    println!("The length of '{a}' is {b}.");
}
fn calculate_length(value: String) -> usize {
    value.len()
}

This exemple will clearly throw an error, because the ownership of the value of a is moved to the function calculate_length() that returned a value to assign to b, but when we try to print a:

error[E0382]: borrow of moved value: `a`
 --> src/main.rs:6:31
  |
2 |     let a = String::from("adservio");
  |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait
3 |
4 |     let b = calculate_length(a);
  |                              - value moved here
5 |
6 |     println!("The length of '{a}' is {b}.");
  |                               ^ value borrowed here after move
  |
note: consider changing this parameter type in function `calculate_length` to borrow instead if owning the value isn't necessary
 --> src/main.rs:9:28
  |
9 | fn calculate_length(value: String) -> usize {
  |    ----------------        ^^^^^^ this parameter takes ownership of the value
  |    |
  |    in this function
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
  |
4 |     let b = calculate_length(a.clone());
  |                               ++++++++

The error here is “note: consider changing this parameter type in function calculate_length to borrow instead if owning the value isn't necessary” is trying to told us already what we should do.

The Magical Symbole &

Here is the correct version that will not throw an error:

fn main() {
    let a = String::from("adservio");

    let b = calculate_length(&a); //&...

    println!("The length of '{a}' is {b}.");
}

fn calculate_length(c: &String) -> usize {
    c.len()
}

We can see here that the variable we passed has & just before it &a, and the type of the parameter in calculate_length() has a & before it: `&String`, the symbole & here is telling the rust compiler that the function will only borrow the variable, and that we will pass only a reference to it instead of moving the ownership.

By & we can create a reference to a, so that if we stopped using the reference the value will not be dropped because de reference doesn't own it.

In the function calculate_length the c will not take the ownership of the value passed, because we added & symbole to the type, so when c goes out of scope nothing will happen to the value passed because c holds only a reference to the value not the ownership. And that's what we called borrowing, is the concept of “to borrow” not “to own”.

The question here, are we able to modify a value that we have reference to (that we borrow)? the answer is NO:

fn main() {
    let a = String::from("adservio");

    add_string(&a);
}

fn add_string(b: &String) {
    b.push_str(" Group");
}

Here we are trying to append a string to the one that we passed to the function add_string(), here is the error:

error[E0596]: cannot borrow `*b` as mutable, as it is behind a `&` reference
 --> src/main.rs:8:5
  |
8 |     b.push_str(" Group");
  |     ^^^^^^^^^^^^^^^^^^^^ `b` is a `&` reference, so the data it refers to cannot be borrowed as mutable
  |
help: consider changing this to be a mutable reference
  |
7 | fn add_string(b: &mut String) {
  |                  ~~~~~~~~~~~

The error: b is a & reference, so the data it refers to cannot be borrowed as mutable, the compiler is telling us that we cannot modify the data that b refers to because it is immutable.

Mutable References

Yes we can modify a borrowed data with using a mutable reference:

fn main() {
    let mut a = String::from("adservio");
    add_string(&mut a);
}

fn add_string(b: &mut String) {
    b.push_str(" group");
}

Here we should start by defining a as mutable value, and when we will try to pass it to the function, we should tell the compiler that it's a reference to mutable value by using a mutubale reference &mut a, in the function declaration we add &mut, in order to tell the compiler that b is a reference to a mutable value so that the function will be able to mutate the value that is borrowing.

We cannot have a reference to a value that already have a mutable reference to it. BUT

let mut a = String::from("adservio");

let b = &mut a;
let c = &mut a;

println!("{b}, {c}");

This code will throw an error:

error[E0499]: cannot borrow `a` as mutable more than once at a time
 --> src/main.rs:6:13
  |
5 |     let b = &mut a;
  |             ------ first mutable borrow occurs here
6 |     let c = &mut a;
  |             ^^^^^^ second mutable borrow occurs here
7 |     
8 |     println!("{b}, {c}");
  |                - first borrow later used her

Her we have a big WHY? why we have this behaviour? Rust here is preventing data races at compile time. Because here we can modify the value using the references that we have, so how we will synchronise the modification here? how we will track our code in compile time.

So to prevent data races Rust is throwing an error at the compile time, but we can have multiple mutable references by using scopes, each reference that we create has a defined scope for it, exemple:

   let mut a = String::from("adservio");

   {
       let b = &mut a;
   } 
   let b = &mut a;

the code here compile successfully because, there is no data races thanks to defining scopes using curly brackets.

We cannot have mutable reference to a value when we have an immutable one to it.

We can have multiple immutable references to a value, because it will not produce data races, users of the references will not modify the value, so that will not affect the other references.

Conclusion

In this article we had a global view of why using Rust is great, we had a look also to the syntax and some basic concepts like mutability, and how it offer us a high level of safety and performance, we talked also about ownership, references and borrowing which are an essential concepts in Rust, if we understand them, we will have a total control of Rust when we are working with it.

Qwik Authentication with Auth.js

Ayoub Alouane — Tue, 18 Jul 2023 22:01:25 +0000

Introduction to Auth.js

Auth.js is a well-known library for authentication that is used by JS Frameworks; with Auth.js we have less complexity. We also had a set of auth providers like GitHub, Google, Facebook, and others, and it can be integrated into multiple frameworks like NextJS, SveltKit, SolidStart, and Qwik.

Auth.js comes with multiple features, that enable simplicity, productivity, flexibility and multiple providers. Here is the main features of Auth.js:

Providers: Auth.js has the support of multiple providers that simplify for us the authentication process in our applications (Github, Google, Facebook, Twitter …). It also offers SSO services and also a simple traditional authentification.
Management: Auth.js is doing a lot to help us focus on our business logic, so it manages Tokens, stores them, and takes care of refreshing them automatically.
Configuration: Auth.js is simple to configure, with an easy installation, error handling, custom forms for login and registration, and simple integrations with providers.
Integrations: Auth.js integrates with JS frameworks easily thanks to its documentation that provide a simple guide to follow.
Security: Auth.js provides a high level of protection, it's a developer-friendly library, but we should not forget that it has a complexity under the hood that offers us a great level of security for our data.

Brief Introduction to Qwik

Qwik is a framework created by the creator of Angular, Miško Hevery, with a collaboration of Adam Bradley, who created Ionic, and Manu Almeida, who created Gin Framework.

Qwik, the HTML first framework’s philosophy is clear: make the fastest possible time-to-interactive (to do it faster by doing nothing).

The framework delays the invocation of the javascript as much as possible and invokes it only what is absolutely needed. The focus is on the first load.

If you want to dive deep in Qwik, we already have an article about it:

Qwik – The Post-Modern Framework

Ayoub Alouane for Playful Programming ・ Jul 11 '23

#javascript #qwik #frontend #typescript

Integrate Auth.js to Qwik

Prerequisites

To get started with Qwik locally, we need the following:

Node.js v16.8 or higher
Your favorite IDE (vscode recommended)

App Creation

Using the Qwik CLI we will start by starting a new Qwik Project:

npm create qwik@latest

Steps to create the project:

┌  Let's create a  Qwik App  ✨ (v1.0.0)
│
◇  Where would you like to create your new project?
│  ./qwik-auth
│
●  Creating new project in  /Users/mac/Documents/articles/qwik-auth  ... 🐇
│
◇  Select a starter
│  Basic App (QwikCity)
│
◇  Would you like to install npm dependencies?
│  Yes
│
◇  Initialize a new git repository?
│  Yes
│
◇  Created App 🐰
│
◇  Git initialized 🎲
│
◇  Installed dependencies 📋
│
○  Result ────────────────────────────────────────────────╮
│                                                         │
│  🦄  Success!  Project created in qwik-auth directory   │
│                                                         │
│  🐰 Next steps:                                         │
│     cd qwik-auth                                        │
│     npm start                                           │
│                                                         │
│  🤍 Integrations? Add Netlify, Cloudflare, Tailwind...  │
│     npm run qwik add                                    │
│                                                         │
│  📄 Relevant docs:                                      │
│     https://qwik.builder.io/docs/getting-started/       │
│                                                         │
│  💬 Questions? Start the conversation at:               │
│     https://qwik.builder.io/chat                        │
│     https://twitter.com/QwikDev                         │
│                                                         │
│  👀 Presentations, Podcasts and Videos:                 │
│     https://qwik.builder.io/media/                      │
│                                                         │
│                                                         │
├─────────────────────────────────────────────────────────╯
│
└  Happy coding! 🐇

To run the server, we will need the following command:

npm start

On port 5173 we will have our application running. Now we will install Auth.js:

npm run qwik add auth

After installing Auth.js we should go to the file vite.config.js in order to add some configuration "optimizeDeps":

import { defineConfig } from 'vite';
import { qwikVite } from '@builder.io/qwik/optimizer';
import { qwikCity } from '@builder.io/qwik-city/vite';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig(() => {
  return {
    plugins: [qwikCity(), qwikVite(), tsconfigPaths()],
    preview: {
      headers: {
        'Cache-Control': 'public, max-age=600',
      },
    },
    **optimizeDeps: {
      include: [ "@auth/core" ]
    }**
  };
});

In this tutorial we will work with GitHub as our provider, so after installing Auth.js we will find that it added a file called: plugin@auth.ts:

import { serverAuth$ } from '@builder.io/qwik-auth';
import GitHub from '@auth/core/providers/github';
import type { Provider } from '@auth/core/providers';

export const { onRequest, useAuthSession, useAuthSignin, useAuthSignout } = serverAuth$(
  ({ env }) => ({
    secret: env.get('AUTH_SECRET'),
    trustHost: true,
    providers: [
      GitHub({
        clientId: env.get('GITHUB_ID')!,
        clientSecret: env.get('GITHUB_SECRET')!,
      }),
    ] as Provider[],
  })
);

Connecting to Github

In the file: plugin@auth.ts, we had some variables that we should define in our application AUTH_SECRET, GITHUB_ID and GITHUB_SECRET. To do that, we should create a file .env.local :

GITHUB_ID=*********************
GITHUB_SECRET=****************************
AUTH_SECRET=***********************************

To generate the AUTH_SECRET we can use this website: https://generate-secret.vercel.app/32

To generate the GITHUB_ID and GITHUB_SECRET we should go to our GitHub: Setting ⇒ Developer Setting ⇒ OAuth Apps, and we should create a new Auth App:

The result we are the generation of GITHUB_ID and GITHUB_SECRET.

Final Integration in our Code

Auth.js provides us with multiple functions that will simplify for us the process of authentication:

useAuthSignin: it is a function that returns the action of sign-in to start the flow of authentication with redirection to a page with all the possible ways to sign in, example:
useAuthSession: if we are not connected, it will return an empty object, but if we are connected, it will return a session object that contains multiple information, exemple:
useAuthSignout: it is a function that provides us an action of signing out from our application, so all the parameters and objects that concern our session will be removed, example:


import { component$ } from '@builder.io/qwik';
import { QwikLogo } from '../icons/qwik';
import styles from './header.module.css';
import { useAuthSignin, useAuthSession, useAuthSignout } from '~/routes/plugin@auth';

export default component$(() => {
  const signIn = useAuthSignin();
    const session = useAuthSession();
  const signOut = useAuthSignout();


  return (
    <header class={styles.header}>
      <div class={['container', styles.wrapper]}>
        <div class={styles.logo}>
          <a href="/" title="qwik">
            <QwikLogo height={50} width={143} />
          </a>
        </div>
        <ul>
          <li>
            <a href="https://qwik.builder.io/docs/components/overview/" target="_blank">
              Docs
            </a>
          </li>
          <li>
            <a href="https://qwik.builder.io/examples/introduction/hello-world/" target="_blank">
              Examples
            </a>
          </li>
          <li>
            <a href="https://qwik.builder.io/tutorial/welcome/overview/" target="_blank">
              Tutorials
            </a>
          </li>
          <li>
            <span>
              {session.value?.user?.email}
            </span>
          </li>
          <li>
            {session.value?.user === undefined && <button onClick$={() => signIn.submit({ providerId: 'github', options: { callbackUrl: 'http://localhost:5173/' } })}>Sign In</button>}
          </li>
          <li>
            {session.value?.user !== undefined && <button onClick$={() => signOut.submit({ callbackUrl: '/' })}>Sign Out</button>}
          </li>
        </ul>
      </div>
    </header>
  );
});

In the code above, we have a header that will have a button to sign in that we will show only if we are not connected:

So if we sign in successfully the button will disappear, and we will show the sign-out button with the user email in the header:

How SolidJS Works? The Easiest Introduction!

Ayoub Alouane — Sun, 16 Jul 2023 21:34:10 +0000

The first thing that come in mind is the fact that it’s the first framework for category (would use again) and third for the category (want to learn) in stateofjs 2022’s statistics, so we have here a really competitive framework that is getting its part in the market, it’s created by Ryan Carniato, a great fan of React as he said in much of his conferences.

Ryan Carniato is a Principal Engineer at Netlify, he was also a member of MarkoJS Core Team in eBay, he is known for his knockout.js background and also for his admiration of ReactJS. After being in the field for 25 years, he ended with creating one of the most innovative frameworks SolidJS, he started it in 2016 and the first release was in 2021, so we have here 5 years of development.

Reactivity: the key concept of SolidJS

Before talking about Reactivity in SolidJS we should have a good understanding of what is reactive programming, to illustrate the concept here is a simple exemple:

a = b + c
//* where the value of a updates whenever the value of b or c changes.

Reactive programming is a paradigm of building software systems that is based on data flow. Instead of viewing the system as a sequence of assignments, consider it to be a collection of continually changing dynamic equations. The code specifies the interactions between various system components and how they evolve over time. With reactive programming, the system may automatically adjust to changes without the need for continual intervention.

Now let’s return to our reactivity in web development, it’s an important feature of user interface design because it guarantees that changes to the interface are reflected instantly. This is critical for providing users with a consistent and responsive experience.

Reactivity was all time a subject of a lot of discussion between experts, they were continually arguing about the reactivity of every frameworks, for exemple ReactJS is known as reactive framework but for Hevery Misko (The creator of AngularJS, Angular ans Qwik) Angular and ReactsJS are not reactive frameworks.

// Detect dark theme var iframe = document.getElementById('tweet-1593260994469367809-484'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1593260994469367809&theme=dark" }

But the same person will talk about SolidJS as a reactive framework:

// Detect dark theme var iframe = document.getElementById('tweet-1613525081430413313-486'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1613525081430413313&theme=dark" }

By the way Mr Hevery has created a new Framework called Qwik that we covered in multiple articles, here is an introduction to his framework:

Qwik – The Post-Modern Framework

Ayoub Alouane for Playful Programming ・ Jul 11 '23

#javascript #qwik #frontend #typescript

Here in this tweet, Mr Misko mentioned a core principe in reactivity, fine-grained reactivity, so what is it?

Fine-grained Reactivity

Fine-grained reactivity is a type of reactivity that is applied at the most granular level possible. Ryan Carniato in his famous article has talked about it with a significant exemple:

Fine-grained reactivity is built from a network of primitives. By primitives, I am referring to simple constructs like Promises rather than JavaScript's primitive values like strings or numbers.
Each act as nodes in a graph. You can think of it as an idealised electric circuit. Any change applies to all nodes at the same time. The problem being solved is synchronisation at a single point in time. This is a problem space we often work in when building user interfaces.
-Ryan Carniato

This is the core concept of SolidJS, and to have a solid understanding, we should be aware of 3 important concepts: Signals, Memos and Effects.

Signals

Signals are the elements that we want to watch, they are composed of a getter, a setter and the value. Exemple of code:

const [count, setCount] = createSignal(0);

// read a value
console.log(count()); // 0

// set a value
setCount(3);
console.log(count()); //result: 3

Effects

So Signals are the ones we watch, but who is the watcher? it’s the Effect, it’s role is to observe the Signal, exemple pf code:

Like we can see in this exemple, the signal that we created is the Observable, and the effect is the one who is watching the change that happen in the Signal, so whenever the value of the count changed, the effect is here to execute an instruction.

But importantly, the updates occur in real time. The Effect has already executed before we can log the following instruction.

Memos

Memo we can consider it as an observer and a Observable in the same time, in other words it combines the Signal and the Effect, here is an exemple:

In this exemple Memos represent a Signal for the the Effect that we created in line 5, so Memo here change if one of the first 2 signal changes, so it depends to its dependencies.

As we can see this approach will save us a lot of work, and it’s not limited to giving values, we can do more of that, the Memo can have instructions (if…else) to have more control on the actions that we want to perform.

Conclusion

SolidJS as we can see is a revolutionary Framework, a lot of work done in it, the present article doesn’t cover all the principle subjects in SolidJs, but it’s a sort of an Overview of the Framework and how it works.

This article provided an overview of fine-grained reactivity, a notion that become a subject of lot of innovations in JavaScript front-end development.

Astro Framework: Revolutionizing Web Development with Island Architecture and Zero-Javascript Approach

Ayoub Alouane — Thu, 13 Jul 2023 14:06:31 +0000

Astro is a tool known for making things easier by building a multi page application and shipping with no Javascript by default. Meaning, only the HTML file will be sent to the browser, with zero JS needed to get loaded on the browser and slow you down.

Introduction to Astro

Instead of heavy interactive apps, Astro is designed to target content-based websites. Astro is a really great option for that, as much as we want to publish some content.

It's a kind of server-first, it privileges server-side rendering over client-side rendering as much as possible.

Astro was created for creating webpages with lots of content. This covers the majority of e-commerce sites, blogs, publishing sites, documentation sites, and blogs.

We need to know something crucial before beginning our review. The distinction between a web application and a website;

WebSites (as opposed to web applications) lack dynamic content updates and are hence static. Visitors cannot engage with them or send messages back to the site.
WebApps: Web apps are websites with interactive features and capabilities. A web application is computer software that is accessed through a web browser and frequently linked to a database to offer a customized interactive experience for the user.

Having said this, you should be aware that Astro might not be the ideal option for your project if you're trying to build a web application.

For your web application-focused project, exploring over Next.js framework as an option would be more appropriate in your situation.

Astro team made sure we can utilize any favorite UI component language that we already are familiar with. Frameworks such as Svelte, React, Vue, Lit, Solid, etc. are compatible for creating new UI components in Astro projects.

All web developers should be able to use Astro, this is what the team behind Astro had in ming. Regardless your previous web development expertise or skill level, Astro is built with an easy to use approach.

Partial Hydration, what is it?

The concept of partial hydration allows developers to determine what aspects are loaded and when, in order to provide fast interactivity. This is done by being able to put some client-side JS only where it is needed using something referred as "island architecture".

Partial hydration definitely is a wise and practical strategy. Our webpage initially is sent as pure HTML from the server to the client. JavaScript is not shipped by default.

However, we know that JavaScript is what makes our page interactive. This is where hydration comes into play as the procedure of loading JavaScript.

Hydration is cool, it’s in place only when we need it, for example, if we have a page that starts with content that doesn’t need interaction, javascript is not needed.

So we load nothing, but if scroll down to the footer when we have a form-contact that need interaction with the user, here the hydration comes in place to hydrate our page with the javascript needed for the form.

How is Partial Hydration implemented in Astro?

The guiding principle of Astro is to build Islands of Interactivity that the browser can hydrate on its own. Astro Island is the solution.

We can optimize how the page loads javascript by treating each component (Island) independently.

We divide the page into multiple components, each element has its own case. Image carousels need javascript, text or image doesn’t need it, a comment section needs javascript, and so on.

In Astro we are able to tell the component how to be rendered, it's up to us to choose, we can for exemple decide that the component's JavaScript code should be rendered in the initial load of the page, or maybe hydrate the component with JavaScript after finishing the first load, also we can be more precise ad say That the component should be hydrated only if it's visible to the user, that's some of the cases that we can choose fo rendering.

Pros of Island Architecture

The Islands design incorporates principles from several rendering approaches, including server-side rendering, static site generation, and partial hydration.

The following are some of the major advantages of integrating islands:

The Pattern provides all of the benefits of component-based architecture, such as reusability and maintainability.
Improves performance by decreasing the quantity of JavaScript code sent to the client. The code delivered only contains the script needed for interactive components, which is significantly less than the script required to build the virtual DOM for the full page and rehydrate all of the page's elements.
Websites are SEO-friendly because all static content is rendered on the server.
Using standard static HTML links to reach other pages helps to increase the website's accessibility.

Astro is MPA or SPA?

Astro is unique in that it is both a static site generator and strives to keep JavaScript out of the final build as much as possible. It also prefers multi-page apps over single-page apps (SPAs).

A website may be built in a variety of ways. The Single Page Applications (SPAs) concept promoted by Angular and React, has mostly overtaken MPAs, but Multi-Page Applications (MPAs) are making a comeback due to the amount of Javascript we transport to the browser using SPAs.

Fast startup is crucial for many websites, for many sites and apps with little interactivity, a client-rendered framework like Angular is overkill.

This generation of MPAs is distinct from earlier generations. Astro has a component-based approach employing the island's architecture.

Conclusion

A lot of specialists in the field believe that Astro may probably completely change how websites are built.

The fact that astro build websites without a client-side JavaScript by default will have a major impact on the performance because it removes all the unused JavaScript code.

A Brief History of Web Apps – Why Qwik is Innovative

Ayoub Alouane — Wed, 12 Jul 2023 13:31:57 +0000

Let us together see how web applications were built over different generational approaches. Before talking about Qwik, there is a history before it, which we can split by generations, each generation has a concept that changed everything.

Before starting here is our first article about Qwik.

1st Generation of Web Apps

The first generation of rendering, as Hevery (The Creator of Angular and Qwik) said, was done on the server with technologies such as PHP. The server rendering was made interactive on the client with javascript (JQuery.) The role of the server here is to send a template every time it is called.

The server renders a sort of document that contains HTML and javascript. We use JQuery as a tool to add interactivity within the template.

So what’s the problem with this approach?

The issue is that we have to deal with two languages, one on the server (such as PHP) and another on the client side, which is undoubtedly Javascript which may cause confusion between the element that was written in PHP and its behavior in javascript and that leads to writing a functionality multiple times.

That's why this approach is hard to scale.

2nd Generation of Web Apps

Here comes the second generation, the famous SPA (Single Page Application), the modern frameworks like AngularJS, Angular, React, or VueJS.

The first generation had an MPA (Multiple Page Application) approaches. Now, let’s return to SPA.

The concept is never reloading the page and only making calls to the server to update the state on the client side, but in the first launch, we load all the applications as a javascript code.

That was a revolutionary approach in the history of web development, but the history of the idea started with AJAX, which gives us the possibility to update data without reloading the page.

After that, JQuery came into play, which introduced an optimized approach to make dynamic pages or to give life to our pages, and other frameworks also, like KnockoutJS and BackboneJS, that tried to fix multiple issues.

Still, if we want to talk about the first SPA framework, it is by far AngularJS that was the most complete, because it contained dependency injection, two-way data binding, and templating.

All of that is based on an MVC (Model-View-Controller) architecture. The surprise here is what?

Misko Hevery, who created Qwik, is the same who created AngularJS, the first SPA framework.

So, what’s the problem with the SPA? It’s the first load, it will start with a blank page taking a long time to load, and it’s not scalable if we want to work on big applications.

Between 2nd & 3rd generation of Web Apps

Before the third generation, we should talk about the second and a half-generation, and its SSR (Server Side Rendering) with frameworks like NextJS or SvelteKit.

These ones introduced a different but not revolutionary approach. In SSR, we still build SPA applications but with a different concept.

We pre-render HTML, and we hydrate it with javascript after that, so the result here is only to reduce the time of seeing a blank page. So, it’s not interactive until we hydrate it with the Javascript needed for the elements.

For example in the process of loading JS, if the JS needed for a button is loaded we can interact with it, but the JS needed for a form is not loaded yet, the form is still not interactive.

Here comes another framework that tried to reduce the time consumed in this process, it’s the Astro framework.

Astro has a concept called Partial Hydration, so it doesn’t hydrate the page with JS until it’s visible.

For example, if we have a contact form at the bottom of the page and we are at the top of it, the contact form won’t be visible, and this way we don’t need to load the javascript needed for the form.

Only if we scroll down to the section where we have the contact form, this is when the hydration takes place to hydrate the components in our form with the Javascript needed.

3rd generation of Web Apps as the new era

The revolution has already started after the first revolution created by Misko Hevery. Here is the second one he created, Qwik Framework introduces Resumability.

We now have a solid understanding of hydration and partial hydration, but Resumability has an approach of “stop/resume,” resuming the application where the server left off in place of replaying all of the work.

If you have the contact form at the bottom, we don’t call his javascript even if you scroll down, we call it only if you click on the send button. In order to understand this a bit further, let’s dive into some technical aspects.

The secret here is about entry points. Unlike other frameworks, Qwik gives us the ability to stop and resume the application from everywhere, and because it’s not limited to one entry point like modern frameworks.

The entry point provides us the possibility to download the code needed for a given interaction that we want to perform, whereas in the 2nd generation we can’t click on a button until all the application is loaded, and that’s the opposite of what resumability provides.

We load the javascript needed for the interaction only if we click on the button. The challenge here is how we do that.

The question is quickly answered: Listeners!

Qwik has a global listener that ensures that every time an event happens, it searches for the specific listener needed and attaches it to the DOM in order to call the entry point needed.

It does that with the serialized information that is attached to the click event, for example.

Conclusion

In this article, we had a look at the evolution of rendering and how it used to impact the performance of web apps versus how it's impacting nowadays.

Now, a new generation is here, and Qwik is one among those who represent it in the best way. Other modern frameworks do not have the same approach because the difference is fundamental. It’s all about having (n) entry points so we can provide resumability and lazy loading.

Qwik – The Post-Modern Framework

Ayoub Alouane — Tue, 11 Jul 2023 10:38:57 +0000

Qwik introduction

Modern frameworks face a big challenge of performance, they are not on top of what companies are looking for.

Some of these frameworks have adapted performance as the real utility of them, for example, Svelte, but none of them have reached the real expectations because they are looking to make web apps faster in the run-time, but no one is looking for the source of the problem.

Here comes Qwik, which adopted a different approach, the focus shift from "doing faster" to "doing less”. It’s a key difference that will change the game. Ultimately, the fastest tool is probably the one doing the least amount of (repetitive) work.

Qwik is a framework created by the creator of Angular, Misko Hevery, with a collaboration of Adam Bradley, who created Ionic, and Manu Almeida, who created Gin Framework.

These are pioneers of web development. I don’t think we are dealing with just another javascript framework. Maybe we should be prepared for a new framework that will change the paradigm.

Why Qwik?

Qwik comes with a clear goal: achieving top performance, perfection, 0 javascript, and pure HTML. Yes, we are here. It’s time for that. Qwik is trying and also succeeding to go beyond what other frameworks can do.

The last framework that came with a new concept was Astro, which introduced partial hydration, a revolution in javascript frameworks.

For example, if we have a page that starts with a text that does not need javascript, we load nothing, but if we scroll down to a component that needs javascript for the interaction, we hydrate the page with the needed javascript.

Qwik killed the game, with no partial hydration but zero hydration and 0 javascript on the first load.

For instance, if we have a form contact at the bottom of a page, Angular, React, or VueJS will load the javascript needed on the first load, Astro will load it if we scroll down, Qwik will load it only and only if we click on the send button of the form, it loads javascript not when we have the form in front of us but if we interact with it.‍

Qwik key concept

Qwik, the HTML first framework’s philosophy is clear: make the fastest possible time-to-interactive (to do it faster by doing nothing).

The framework delays the invocation of the javascript as much as possible and invokes it only what is absolutely needed. The focus is on the first load.

As such, it only loads pure HTML. To achieve this, Qwik is based on an important concept. In this paragraph, we will dive deep into it.

Resumability

The modern frameworks now compete to improve hydration. Qwik is unique in that it has resumability.

The name of the concept gives us a perception of what we are talking about, “stop/resume,” resume the application where the server left off in place of replaying all of the work.

Serializing event handlers is the key to stopping and resuming the application. But doing this is not something new, we did it before through jQuery.

For example, using pure javascript. The difference with Qwik is that working on Qwik is like working on React, it has adopted the modern DX.

If we try to think deeply about the figure above, we will understand the reel problem, scaling. If we have an extensive web application, it will take a lot of time to load with hydration.

Even with Partial Hydration, it will be challenging to scale, Qwik with the resumability only loads HTML, which does not take a lot of time.

It’s a fraction of a second and you have your application loaded in your browser.

Prefetching

To be precise, Qwik will not download every file only when you click, but after doing the first load to show the page (that is interactive), the framework will start automatically downloading the code necessary fo the web app using a service worker, and it will store it in the browser's cache, so we will not send a request to the server every time, but it will grab it instantly from the cache, if the code is not downloaded yet it will download it from the server, and that's what we call prefetching.

So when we say "load the javascript" we are talking about getting the JavaScript code from the cache and executing it only when we need it, other frameworks download and execute the JavaScript code in the first load, and that's what cause a lot of performance issues. Qwik is interactive from the first load without the need to wait for all the javascript to be downloaded.

Qwik City

On the 1st of May 2022, Hevery said in a podcast that their goal is building a router that offers the capability of doing MPA (multiple page application) routing with the benefits of SPA (Single page application) routing. In other words, doing MPA rooting without refreshing the page.

Only render the parts that need refreshing. That may sound like fiction, but it’s already done, they did it, and its name is Qwik City.

So Qwik is a mix of server-side rendering and client-side rendering. It takes advantage of the two of them.

Qwik City is the meta-framework designed for Qwik, like Next.js for React.js. The routing in Qwik City is so simple, it’s based on the structure of our directories in the routes directories.

src/

└── routes/

    └── some/

        └── path/

            └── index.tsx       <https://example.com/some/path>

With our 0 javascript meta-framework, the application is loaded without a single javascript dedicated to Qwik city, but there is more than that. It also offers:

Directory-based routing
Nested layouts
File-based menus
Breadcrumbs
Support authoring content with .tsx or .mdx file formats
Data endpoints

Conclusion

Modern frameworks download all the javascript, and after that, they execute all of it.

Qwik downloads a little bit of javascript, and it doesn’t execute it until we need it. The framework is changing the mental model.

We think that Qwik will be one of the pioneers in the JS frameworks. It has improved startup performance, which is a real problem of modern frameworks, but with Qwik, it’s not the case.

Let us see the future and stay tuned because this is our first article about the framework, and of course, it’s not the last. In the coming articles, we will dive deep into the core concepts, and we will do some examples of building Qwik applications.

This article has been reviewed kindly by Mr Havery Misko (The creator of Angular and Qwik), we thank him a lot for his contribution.

Link to Original Article.