Forem: Léo Pradel

Create a typescript package with Parcel

Léo Pradel — Tue, 14 May 2024 20:07:15 +0000

So, you've got this idea for a TypeScript package, but configuring build tools isn't your idea of a good time? Parcel is there to save the day!

Parcel is a fast and zero-configuration web application bundler designed to simplify the build process for modern web projects. It's not limited to web applications, and it can be used to build packages targeting the browser or Node.js.

In this tutorial, we will create a new typescript package using Parcel and configure it to output both CommonJS and ECMAScript modules.

Create a new typescript package

Start by creating a new directory and initializing your project with npm:

mkdir my-package
cd my-package
npm init -y
npm install --save-dev typescript parcel @parcel/packager-ts @parcel/transformer-typescript-types @parcel/validator-typescript

This will create a new directory called my-package and initialize a new package.json file with the default values and install the required dependencies.

Configure Parcel

To configure Parcel, we need to edit the package.json file and add the following configuration:

{
  "type": "module",
  "source": "src/index.ts",
  "main": "dist/index.cjs",
  "types": "dist/index.d.ts",
  "module": "dist/index.js"
}

This configuration tells Parcel to use src/index.ts as the entry point for our package, and to output the CommonJS module to dist/index.cjs, the ECMAScript module to dist/index.js, and the types to dist/index.d.ts.

Then, we add the scripts to the package.json file to build our package. Add the following scripts to the package.json file:

{
  "scripts": {
    "watch": "parcel watch",
    "build": "parcel build"
  }
}

Parcel do not automatically typecheck the code, so we need to tell it to use the typescript validator. To do this, add the following configuration to a new .parcelrc file:

{
  "extends": "@parcel/config-default",
  "validators": {
    "*.{ts,tsx}": ["@parcel/validator-typescript"]
  }
}

Configure typescript

To configure typescript, add the following configuration to a new tsconfig.json file:

{
  "include": ["src/**/*"],
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  }
}

Create the source code

Now, let's create the source code for our package. Create a new directory called src, and create a new file called index.ts inside the src directory. Add the following code to the index.ts file:

export const hello = (name: string) => `Hello, ${name}!`;

Build the package

To build our package, run the following command in your terminal:

npm run build

This will compile the typescript code and bundle the package using Parcel. You should see the CommonJS, ECMAScript, and types output in the dist directory.

In development, if you want to watch for changes and rebuild the package automatically, you can run the following command:

npm run watch

Conclusion

Thanks to Parcel, creating a modern typescript package is a breeze. With zero configuration, Parcel simplifies the build process and allows you to focus on writing code. It's a great alternative to other bundlers like Webpack, Rollup or tools like tsup.

Now you are ready to publish your awesome package to npm and share it with the world! 🌍✨

Dockerize a nitro application

Léo Pradel — Thu, 09 May 2024 10:18:37 +0000

Nitro is a server toolkit/framework that allows you to create web servers with ease and deploy them wherever you prefer.

In this tutorial, we will create an optimised Docker image so you can deploy your app on any VPS or provider.

Create a new simple nitro server

Let's start by creating a new Nitro server. We will use a really simple "hello world" app for this tutorial. To create and install the template, run the following command in your terminal:

yarn dlx giget@latest nitro nitro-app --install
cd nitro-app

Let's try the application to make sure that everything is correct. To run the application in development mode, run this command:

yarn run dev

In your terminal, you can see from the logs that the application is running properly.

> dev
> nitro dev

  ➜ Local:    http://localhost:3000/
  ➜ Network:  use --host to expose

✔ Nitro Server built in 181 ms

Now, open your browser and go to the URL http://localhost:3000, you should see the following message Start by editing server/routes/index.ts..

Let's edit server/routes/index.ts and change it to the following:

export default eventHandler((event) => {
  return { message: 'Hello world!' };
});

Save the file and refresh your page and you should now see some JSON returned by the nitro server.

{
  "message": "Hello world!"
}

Finally, let's close the development server by running Ctrl+C in your terminal.

Dockerize the nitro app

Our application is now ready, let's create the docker config. First, we create a new .dockerignore file that will tell Docker to not copy these local files and folders when building the image.

# .dockerignore

node_modules
# Files generated by nitro
.nitro
.output

Create the optimized Dockerfile

Next, let's create a new Dockerfile file that will contain the instructions for building the Docker image. We will use a multi-stage build to create an optimized image.

The fist step is to install the dependencies, this is done as a separate step to take advantage of Docker's caching mechanism, so that we don't have to reinstall the dependencies every time we rebuild the image.

# Dockerfile
FROM node:20-alpine AS base

# Install dependencies
FROM base AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile

Then, we build the nitro app in a separate step. This will generate the optimized output in the .output folder.

# Dockerfile

# Install dependencies
# ... (same as before)

# Build the nitro app
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN yarn run build

Finally, we create an optimized runner image that will run the nitro app. We copy the optimized output from the builder image and set the user to nitro to run the app as a non-root user. If you are familiar with Docker, you will notice that we don't copy the node_modules folder to the runner image, this is because nitro already includes all the dependencies in the optimized .output folder.

# Dockerfile
FROM node:20-alpine AS base

# Install dependencies
# ... (same as before)

# Build the nitro app
# ... (same as before)

# Create an optimised runner image
FROM base AS runner
WORKDIR /app
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nitro
COPY --from=builder /app/.output ./.output
USER nitro
EXPOSE 3000
ENV PORT 3000
CMD ["node", ".output/server/index.mjs"]

Our final Dockerfile should look like this:

FROM node:20-alpine AS base

# Install dependencies
FROM base AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile

# Build the nitro app
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN yarn run build

# Create an optimised runner image
FROM base AS runner
WORKDIR /app
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nitro
COPY --from=builder /app/.output ./.output
USER nitro
EXPOSE 3000
ENV PORT 3000
CMD ["node", ".output/server/index.mjs"]

Build the Docker image

Let's build our application Docker image, the -t flag is used to tag it with the name we want. Run the following command:

docker build . -t nitro-app

Run the Docker container

Finally, we can run the docker container to test that the app is working properly. Run the following command:

docker run -p 3000:3000 nitro-app

In your terminal, you can see in the Docker logs that the application is running on port 3000.

Listening on http://[::]:3000

Open your browser at http://localhost:3000 and see the same "Hello world!" JSON as before.

Conclusion

Dockerizing a nitro server is very similar to other Node.js applications, except that the optimised build step will generate a smaller Docker image. You can now deploy your Docker image whenever you want (VPS, fly.io, Render etc..).

Simplifying Your Node.js setup with pnpm

Léo Pradel — Mon, 03 Apr 2023 17:39:08 +0000

With so many tools available to manage Node.js installations it can be hard to choose the best option. So, do you still need a tool like nvm or volta in 2023?

Let me introduce you to pnpm, my new go-to package manager. It's not only fast and disk-space efficient but also replaces npm or yarn for managing Node.js projects. And guess what? pnpm can handle your Node environment and directly install or update Node.js too! That's right, with just one tool, we can manage everything - project dependencies and the Node.js environment.

First, let's get the latest version of pnpm up and running with this simple command:

curl -fsSL https://get.pnpm.io/install.sh | sh -

Once that's done, selecting the version you want to use is simple:

# Install LTS release
pnpm env use --global lts

# Install Node.js 16
pnpm env use --global 16

So, although pnpm is mainly a package manager, it's turned out to be great for managing my Node.js environment too. With its efficient disk space usage, faster installations, simple configuration, and better compatibility, pnpm has become my go-to choice. Give it a try, and experience the benefits for yourself!

Sending a message with the Twitter API in a Cloudflare worker

Léo Pradel — Sun, 01 May 2022 12:10:51 +0000

If you are trying to use the Twitter API, you probably saw many examples using the twitter-api-v2 npm package which works fine in Node.js but unfortunately does not work in a Cloudflare Worker as it relies on Node.js APIs.

In order to use the Twitter API, you have to handle the OAuth authentication and use fetch to send the request. At the time I wrote this post there were no examples of this, so it took me some time to figure out how to do it. The following snippet shows you how to send a tweet, but you can use any API method you want.

import OAuth from 'oauth-1.0a';
import { HmacSHA1, enc } from 'crypto-js';

const oauth = new OAuth({
  consumer: { key: TWITTER_API_KEY, secret: TWITTER_API_SECRET },
  signature_method: 'HMAC-SHA1',
  hash_function(baseString, key) {
    return HmacSHA1(baseString, key).toString(enc.Base64);
  },
});

const oauthToken = {
  key: TWITTER_ACCESS_TOKEN,
  secret: TWITTER_ACCESS_TOKEN_SECRET,
};

const requestData = {
  url: 'https://api.twitter.com/1.1/statuses/update.json',
  method: 'POST',
  data: { status: 'Hello from Cloudflare worker' },
};

const response = await fetch(requestData.url, {
  method: requestData.method,
  headers: {
    ...oauth.toHeader(oauth.authorize(requestData, oauthToken)),
    'Content-Type': 'application/x-www-form-urlencoded',
  },
  body: new URLSearchParams(requestData.data),
});

console.log(await response.json());

Detect GraphQL breaking changes on any CI with graphql-inspector

Léo Pradel — Sun, 09 May 2021 10:55:01 +0000

GraphQL Inspector is a set of tools to help you better maintain and improve GraphQL API as well as GraphQL consumers.

GraphQL Inspector provides an amazing GitHub action with a lot of cool features. But if you are using another CI you will have to code them yourself.

When integrating GraphQL Inspector to detect breaking changes on pull requests using Buildkite, I wanted to allow a GraphQL breaking change to be merged if it was intentional. An easy way to do this is to add a label to the pull request named "GraphQL breaking change".

Hopefully, the following script can help you to achieve this easily using the GitHub API. It should also be fairly simple to make it work with Gitlab.

Step 1 - Make the CI fail if a breaking change is present

To simply detect a breaking change just add the following script as part of your CI.

# checkGraphqlBreakingChanges.sh

#!/usr/bin/env bash
set -e

yarn graphql-inspector diff 'git:origin/main:./schema.json' 'schema.json'

If a breaking change is present this script will fail.

Step 2 - Allow a breaking change to be merged if a GitHub label is present on the PR

Create a new pull request label via the GitHub UI named "GraphQL breaking change".

The script works directly with Buildkite but you will have to replace the BUILDKITE_PULL_REQUEST env variable with the one provided by your CI.

Your CI env needs to have access to a GITHUB_USER and GITHUB_USER_TOKEN allowing the script to query the GitHub API.

# checkGraphqlBreakingChanges.sh

#!/usr/bin/env bash
set -e

# Label allowed
ALLOW_LABEL="GraphQL breaking change"

# We only want to run this logic if we are on a pull request
if [ -z "$BUILDKITE_PULL_REQUEST" ]; then
    echo "Skipping, not a pull request..."
    exit 0
fi

# Get the labels array from the Github API for the pull request
GITHUB_PR_LABELS=$(curl -u $GITHUB_USER:$GITHUB_USER_TOKEN \
  -s "https://github.com/api/v3/repos/my-org/my-repo/pulls/$BUILDKITE_PULL_REQUEST" \
  | jq '.labels[].name')

# If label is set on the pr we stop the execution as breaking change is intentional
if [[ ${GITHUB_PR_LABELS[*]} =~ "$ALLOW_LABEL" ]]; then
    echo "Skipping, because label is set..."
    exit 0
fi

yarn graphql-inspector diff 'git:origin/main:./schema.json' 'schema.json'

Boost your create-react-app workflow with esbuild / swc

Léo Pradel — Wed, 14 Oct 2020 12:21:23 +0000

We can see a trend of replacing the current javascript tooling with faster tools written in go / rust. In this post, I decided to try esbuild and swc to see what performance improvement we can get in any application using create-react-app.

As your app is growing, the development environment and compilation are getting slower and slower, it can easily reach 10+ mins for the build time 🐢. To improve build time and ship code faster to production you might be interested in using these tools and get:

Faster loading time in development
Faster build time
Faster tests

While writing this post I created 2 projects create-react-app-swc and create-react-app-esbuild to help you integrate either swc or esbuild easily in your application.

While these tools are focused on the create-react-app tooling, you can take a look at the source code and integrate them into your own webpack configuration.

Tools

Esbuild

esbuild is a super-fast javascript/typescript bundler and minifier written in Go. esbuild also provides a javascript minifier to replace terser.

Swc

swc is a super-fast javascript/typescript compiler written in Rust. In the future you will be able to use swc to check your typescript files. swc is also creating its own webpack alternative called spack.

How is it working?

Internally create-react-app uses webpack to create a javascript bundle for our application. In your code, you use some ECMAScript features that are not yet available in all browsers (eg: async / await). Babel is used to compile the javascript / typescript files of your application in a backwards compatible version of javascript, meaning it can be used in older browser versions. We can speed up this process by internally replacing babel with esbuild / swc, the babel-loader is replaced by esbuild-loader / swc-loader and the code that needs to be processed is sent to the native (go or rust) binary instead of babel.

Benchmark

I added both approaches to one of my typescript application to see what are the results.

default create-react-app build time: 2m 16s
esbuild build time: 1m 00s
swc build time: 1m 12s

For a pretty small project, we can see that the build time is faster. For esbuild we can see that our build is more than 2x faster. esbuild is currently faster than swc as it also includes a minifier, so we can replace the default terser minifier with it.

If you are trying this on a bigger project I would love to know the results you get!

Future

The esbuild benchmark states that "esbuild is at least 10-100x faster than the other JavaScript bundlers", so why don't we get the same result?

In order to have the same results, these tools are not using webpack but rather their own implementation. In the future, I think we will see projects like create-react-app either drops webpack for another faster solution or see them moving the webpack loaders to these new tools written in go / rust.

But as these tools are quite new it will take some time to see them widely used. As of now replacing the webpack loaders seems like the best approach to get a nice performance improvement while still being able to use all the plugins that the webpack ecosystem provides.

📚 Ready to improve your app in 2 minutes?

Follow the installation guide to add craco-esbuild.
Follow the installation guide to add craco-swc.

Using yarn v2 berry with create-react-app

Léo Pradel — Tue, 23 Jun 2020 16:23:22 +0000

Today I decided to try out the new yarn berry version (v2) with create-react-app and couldn't find any material to get started, so I hope this guide will help you if you are planning to use the new yarn version with CRA :).
This shows how to get started with a new app but you can follow the same steps with an already existing app.

You will need to install yarn if it's not yet installed on your machine. npm install -g yarn

Creating the app

First, let's create a create-react-app application with typescript (typescript is optional).

npx create-react-app my-app --template typescript
cd my-app

Migrating to yarn berry

Yarn berry no longer uses the node_modules folder so we need to delete it. To read more about this, take a look at yarn documentation regarding Plug'n'Play

rm -rf node_modules

We need to tell yarn that we want to use berry for this project.

yarn set version berry

Now let's install our dependencies with the new yarn version.

yarn install

After this step, you will notice that a new .yarn folder and .yarnrc.yml file were created. To see more information on the role of every folder, take a look at this issue.

We don't want to commit the yarn cache files, let's add the following lines to our .gitignore file.

.yarn/*
!.yarn/releases
!.yarn/plugins
.pnp.*

That's it, yarn berry is now configured for our project. Run yarn start to start the app in development mode. Open http://localhost:3000 to view it in the browser.

You should see the following screenshot 🎉.

You might notice that VSCode (or other editors) does not resolve the third party dependencies typescript types (such as react). In order to setup your editor follow the yarn documentation.

Email and password authentication with accounts-js and Apollo GraphQL - Part 1 - setting up the GraphQL server

Léo Pradel — Mon, 17 Feb 2020 11:47:19 +0000

What is accounts-js?

accounts-js is a fullstack authentication and accounts-management for Javascript. We provide you a set of tools to authenticate and manage your users in your application. These tools work with REST, GraphQL and are database agnostic.

I am writing a few articles to demonstrate how you can use accounts-js in your app, hope you will like them :).
Part 2 will be a react application with all the functionalities you expect from a modern app (login, signup, reset password, protected routes etc..).

Today, we will implement the Authentication GraphQL API in NodeJS using accounts-js and Apollo. Note: You can also this tutorial and replace Apollo with graphql-js
At the end of this article our server will be able to sign up new users, allow the users to login and authenticate them to protect some restricted information.

At the end of this post, you can find a link to a repository containing the sources.

Requirements
Setup the node project
Setup accounts-js
Creating our first user
Protecting our query

Requirements

For this project, you will need to have nodejs and mongodb installed on your system.

Setup the node project

Let's start by creating our NodeJS project. Create a new folder named accounts-js-server, all the project files should be inside this folder.
Let's initialize our new project using npm (you can use yarn if you prefer):

npm init

Now, let's add the dependencies we need to setup our Apollo GraphQL server.

npm install apollo-server graphql

Create a new index.js file (to make this tutorial simpler all our code will be in a single file) and add this code to setup the Apollo server. If you want to read more about what this code is about you can take a look at the Apollo Server documentation.

// index.js

const { ApolloServer, gql } = require('apollo-server');

const typeDefs = gql`
  type Query {
    # This query will be protected so only authenticated users can access it
    sensitiveInformation: String
  }
`;

const resolvers = {
  Query: {
    sensitiveInformation: () => 'Sensitive info',
  },
};

const server = new ApolloServer({ typeDefs, resolvers });

// The `listen` method launches a web server.
server.listen().then(({ url }) => {
  console.log(`🚀  Server ready at ${url}`);
});

Now let's start the server to make sure everything is working as expected.

node index.js

In your console you should see:

🚀  Server ready at http://localhost:4000/

Our GraphQL server is now ready, it's time to add accounts-js!

Setup accounts-js

First, we will setup mongoose and connect to our database.

npm install @accounts/mongo mongoose

// index.js

const mongoose = require('mongoose');
const { Mongo } = require('@accounts/mongo');

// We connect mongoose to our local mongodb database
mongoose.connect('mongodb://localhost:27017/accounts-js-server', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
});

// We tell accounts-js to use the mongo connection
const accountsMongo = new Mongo(mongoose.connection);

Then, we add the accounts-js server dependencies.

npm install @accounts/server @accounts/password

@accounts/server: The accounts-js core dependency.
@accounts/password: The accounts-js password service, it expose a set of function to manage and authenticate users using email + password.

It's time to setup the accounts-js server configuration

// index.js

const { AccountsServer } = require('@accounts/server');
const { AccountsPassword } = require('@accounts/password');

const accountsPassword = new AccountsPassword({
  // You can customise the behavior of the password service by providing some options
});

const accountsServer = new AccountsServer(
  {
    // We link the mongo adapter we created in the previous step to the server
    db: accountsMongo,
    // Replace this value with a strong random secret
    tokenSecret: 'my-super-random-secret',
  },
  {
    // We pass a list of services to the server, in this example we just use the password service
    password: accountsPassword,
  }
);

Then, we add the accounts-js graphql dependencies.

npm install @accounts/graphql-api @graphql-toolkit/schema-merging @graphql-modules/core

@accounts/graphql-api: The transport layer exposing all the queries and mutations accounts-js provide.
@graphql-toolkit/schema-merging: Expose a set of tools that will help us to merge our schemas.
@graphql-modules/core: An internal dependency that accounts-js use to manage his graphql schema and resolvers.

Let's merge the accounts-js GraphQL schema and our schema, so the user can access it

// index.js

// Add makeExecutableSchema to the imported variables
const { ApolloServer, gql, makeExecutableSchema } = require('apollo-server');
const { mergeTypeDefs, mergeResolvers } = require('@graphql-toolkit/schema-merging');
const { AccountsModule } = require('@accounts/graphql-api');

// We generate the accounts-js GraphQL module
const accountsGraphQL = AccountsModule.forRoot({ accountsServer });

// A new schema is created combining our schema and the accounts-js schema
const schema = makeExecutableSchema({
  typeDefs: mergeTypeDefs([typeDefs, accountsGraphQL.typeDefs]),
  resolvers: mergeResolvers([accountsGraphQL.resolvers, resolvers]),
  schemaDirectives: {
    ...accountsGraphQL.schemaDirectives,
  },
});

// When we instantiate our Apollo server we use the schema and context properties
const server = new ApolloServer({
  schema,
  context: accountsGraphQL.context,
});

At the end, our file should look like this:

// index.js

const { ApolloServer, gql, makeExecutableSchema } = require('apollo-server');
const mongoose = require('mongoose');
const { Mongo } = require('@accounts/mongo');
const { mergeTypeDefs, mergeResolvers } = require('@graphql-toolkit/schema-merging');
const { AccountsServer } = require('@accounts/server');
const { AccountsPassword } = require('@accounts/password');
const { AccountsModule } = require('@accounts/graphql-api');

// We connect mongoose to our local mongodb database
mongoose.connect('mongodb://localhost:27017/accounts-js-server', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
});

const accountsMongo = new Mongo(mongoose.connection);

const typeDefs = gql`
  type Query {
    # This query will be protected so only authenticated users can access it
    sensitiveInformation: String
  }
`;

const resolvers = {
  Query: {
    sensitiveInformation: () => 'Sensitive info',
  },
};

const accountsPassword = new AccountsPassword({});

const accountsServer = new AccountsServer(
  {
    db: accountsMongo,
    // Replace this value with a strong secret
    tokenSecret: 'my-super-random-secret',
  },
  {
    password: accountsPassword,
  }
);

// We generate the accounts-js GraphQL module
const accountsGraphQL = AccountsModule.forRoot({ accountsServer });

// A new schema is created combining our schema and the accounts-js schema
const schema = makeExecutableSchema({
  typeDefs: mergeTypeDefs([typeDefs, accountsGraphQL.typeDefs]),
  resolvers: mergeResolvers([accountsGraphQL.resolvers, resolvers]),
  schemaDirectives: {
    ...accountsGraphQL.schemaDirectives,
  },
});

const server = new ApolloServer({ schema, context: accountsGraphQL.context });

// The `listen` method launches a web server.
server.listen().then(({ url }) => {
  console.log(`🚀  Server ready at ${url}`);
});

If we restart our server and visit http://localhost:4000/, we should see that the accounts-js queries and mutations are merged with our schema. Our authentication server is now ready 🚀.

Creating our first user

Inside the GraphQL Playground, let's execute the following mutation:

mutation {
  createUser(
    user: { email: "john.doe@john.com", password: "superSecurePassword" }
  )
}

Congrats, our first user has been created 👏!

If you take a look at the users collection inside mongodb you should see that your user was created and looks like this:

{
  "_id": ObjectId("5e3da6ba13ef1a137bbc8fe4"),
  "services": {
    "password": {
      "bcrypt": "$2a$10$WwhjvbDzQpS2LrdkcgQJwODn.EE95T0b9NmMUNcHKyrDOlXEeybSq"
    }
  },
  "createdAt": 1581098682713,
  "updatedAt": 1581098682713,
  "emails": [
    {
      "address": "john.doe@john.com",
      "verified": false
    }
  ]
}

What we can see is that a createdAt and updatedAt fields have been created. We also see that the password has been saved hashed in the database, we use bcrypt as a default but you can change it to argon2 via the options if you prefer.

Now let's try to login with this user:

mutation {
  authenticate(
    serviceName: "password"
    params: {
      user: { email: "john.doe@john.com" }
      password: "superSecurePassword"
    }
  ) {
    sessionId
    tokens {
      accessToken
      refreshToken
    }
  }
}

You should see in the playground that a new session has been created.
The session is represented by:

a sessionId (you can check the session in the database)
a short lived JWT accessToken used to authenticate the user
a long lived refreshToken that can be used to get a new accessToken once it's expired

Save the access token, we will need it to authenticate our requests in the next part.

Protecting our query

Our first user has been created and we are now able to login via the API. Next step is to protect our sensitiveInformation query so only the authenticated users can access it.

accounts-js provide an @auth directive that we can use to protect our private queries.

Let's add the directive to the query in our schema:

// index.js

const typeDefs = gql`
  type Query {
    # We add the @auth directive
    sensitiveInformation: String @auth
  }
`;

If you try this query, you should get an Unauthorized error 🛑.
We can't access this resource because we are not authenticated.
To authenticate our request with the server we need to add the access token saved previously as a header of the request. The header key should be authorization and the value should be prefixed with Bearer.
eg: { "authorization": "Bearer my-access-token" }

You made your first authenticated query, how cool is that?

Well, that's it, you are done, you now have a Graphql server that can register and authenticate new users. Pretty simple right?
Next step for you is to play with the different queries and mutations (verify the email, change the password etc..) :).

⌛ In part 2 we will create the react application that will communicate with our server (coming soon).

You can find the source here https://github.com/pradel/accounts-js-server-tutorial.

Forem: Léo Pradel

Create a typescript package with Parcel

Create a new typescript package

Configure Parcel

Configure typescript

Create the source code

Build the package

Conclusion

Dockerize a nitro application

Create a new simple nitro server

Dockerize the nitro app

Create the optimized Dockerfile

Build the Docker image

Run the Docker container

Conclusion

Simplifying Your Node.js setup with pnpm

Sending a message with the Twitter API in a Cloudflare worker

Detect GraphQL breaking changes on any CI with graphql-inspector

Step 1 - Make the CI fail if a breaking change is present

Step 2 - Allow a breaking change to be merged if a GitHub label is present on the PR

Boost your create-react-app workflow with esbuild / swc

Tools

Esbuild

Swc

How is it working?

Benchmark

Future

📚 Ready to improve your app in 2 minutes?

Using yarn v2 berry with create-react-app

Creating the app

Migrating to yarn berry

Email and password authentication with accounts-js and Apollo GraphQL - Part 1 - setting up the GraphQL server

What is accounts-js?

Table of contents

Requirements

Setup the node project

Setup accounts-js

Creating our first user

Protecting our query