The Path to Native TypeScript

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Imagine the convenience of executing TypeScript files directly with Node.js. Just a few years ago, this concept seemed like a distant dream. Today, it stands as an exciting experimental feature. This narrative dives into the journey of transforming this dream into a reality.

This talk has been presented at Node Congress 2025, check out the latest edition of this JavaScript Conference.

FAQ

Existing TypeScript code can be made compatible using a code mode called correct-yes-specifiers to transform unsupported imports into supported ones.

Marco Ippolito is a senior security engineer at Herodas and a member of the Node.js Technical Steering Committee.

TypeStripping is a method to integrate TypeScript into Node.js by only performing transpilation, removing everything from TypeScript that is not JavaScript, and avoiding type checking.

Challenges include differing stability guarantees, the lack of Node.js support for configuration files like TSConfig, the large size of TypeScript as an NPM package, and issues with CommonJS and ESM interoperability.

TypeStripping avoids the need for source maps by replacing removed TypeScript inline types with whitespace, preserving the original code location.

Limitations include the inability to support features requiring transformation like namespaces and enums, no support for custom paths requiring TSConfig, and the requirement to specify file extensions explicitly.

The experimental transform types flag allows the use of all TypeScript syntax, including namespaces and enums, by enabling source maps.

Node.js attempts to evaluate syntax as common JS, and ESM, and then strips types if necessary. It may use the input type flag to directly specify the syntax type, reducing overhead.

The erasable syntax-only flag in TypeScript ensures that all syntax is supported by Node.js, throwing errors for unsupported syntax during type-checking.

TypeScript was not integrated earlier due to challenges in reaching consensus in the open governance of Node.js, differences in stability guarantees between Node.js and TypeScript, and the lack of a champion to lead the integration efforts.

Marco Ippolito
Marco Ippolito
24 min
17 Apr, 2025

Comments

Sign in or register to post your comment.
  • Va Da
    Va Da
    P4
    TypeScript is the future, adoption looks great.
Video Summary and Transcription
Today's Talk discusses the integration of TypeScript in Node.js. The path to native TypeScript in Node.js is explored, including the history of user requests for native support. Implementing TypeScript in Node.js poses challenges due to differences in stability guarantees and tool compatibility. TypeStripping is a transpilation-focused implementation that removes non-JavaScript features, making it stable across TypeScript versions. The Amaro package, built on SWC, provides compatibility and speed for type stripping. Experimental Strip Types and Transform Types flags enable erasable TypeScript features. TypeScript has limitations such as namespace and enum support in JavaScript and code migration issues. TypeScript Import Types and Syntax Detection are ongoing developments. Ambiguity in syntax between JavaScript and TypeScript is addressed with an erasable syntax only flag. Future steps include bug fixing, performance improvements, and upcoming Node.js releases.
Available in Español: El Camino hacia TypeScript Nativo

1. Introduction to Native TypeScript in Node.js

Short description:

Today I will talk about the path to native TypeScript, so how Node.js and TypeScript have worked together to bring this new integration into Node.js. TypeScript has gone from being a niche technology to one of the most popular languages in the web development scene. We will also explore why Node.js has only now integrated TypeScript and the history of user requests for native support.

Welcome, everyone. I'm very happy to give this talk here at Node Congress. Today I will talk about the path to native TypeScript, so how Node.js and TypeScript have worked together to bring this new integration into Node.js.

Let me introduce myself. My name is Marco Ippolito. I'm a senior security engineer at Herodas and a member of the Node.js Technical Steering Committee.

So we will start with a little bit of history, so how and why we decided to support TypeScript and what changed in the past few years. So we will start with this chart. This is the state of JS 2016, so almost 10 years ago. And we can see that TypeScript was just at the beginning was not very popular. In fact, 34% of the respondents, they heard of TypeScript, but they were not interested into it. And just a small fraction was actually interested and has used it and would use it again. We can also see a few other names that have disappeared from the web development scene, like CoffeeScript, Elm and ClosureScript, but they were quite popular at the time. And we can see now more recent state of JS, which is the 2023. In this chart, we can see that almost all developers that responded, which are 17,000, they use TypeScript only 32%. And in like only 9% of respondents use JavaScript. So the majority of users use TypeScript in some like different percentages, but they all do. And this is crazy to think that 10 years ago, this was like very niche. And today, like everybody uses TypeScript. It's one of the most popular technologies. This is the Stack Overflow 2023 survey. And we can see that TypeScript is the fifth most popular programming language. So today we will see why Node.js has not integrated it years ago and this happened only now. So another very important data is the NPM downloads. TypeScript has around 12 million downloads per day. It is one of the most downloaded packages on NPM. So we will see today how TypeScript is supported in Node.js.

But let's talk a bit about the history. So as Node.js maintainer, I've always seen issues, discussions, PRs of users wanting native TypeScript support. As you can see, there are multiple issues and like there have been so many proposals on how to implement TypeScript in Node.js, but it never happened until recently.

2. Challenges in Implementing TypeScript in Node.js

Short description:

There are reasons why the implementation of TypeScript in Node.js is not straightforward. Getting consensus among the volunteers and open governance of Node.js is challenging. There are different stability guarantees between Node.js and TypeScript, and Node.js does not support TSConfig. Choosing a tool that works out of the box is difficult due to the large size of the TypeScript package and the past issues with CommonJS and ESM interoperability. Source maps are also necessary for effective debugging but add overhead.

And there are reasons why the implementation is not straightforward. One of the first challenges is that it's very hard to get consensus, Node.js being a project run by volunteers and open governance. It's very hard to make everyone agree on what it means to support TypeScript and how it should be done. There have been past attempts in 2023, there was a discussion at the Collaborator Summit in Bilbao, but the discussion, it eventually bled out. So it didn't happen.

There are different stability guarantees between Node.js and TypeScript. TypeScript does not follow SEMVer. So it means that every minor update has breaking changes while Node.js has strong security guarantees. So there is a new, like an LTS release of Node lasts for three years. So it's not possible to lock in a specific version of TypeScript for three years. And this big difference between the two, between Node and TypeScript makes it hard to integrate it. Node.js does not support a configuration file and therefore does not support TSConfig. Having Node supporting TSConfig, it would be weird. And it's something that would not get consensus because in the first place, Node does not have its own config file. So why would it support the config file of another project or dependency of Node.js, which is the reason why Node does not support TSConfig.

It's very hard to choose a tool that works out of the box. As we said, we cannot use TypeScript as an NPM package. We need to use something else. The reason why we cannot use TypeScript is because it's a very large NPM package. It's a 24 megabyte package. It's written in JavaScript and it would be very hard to integrate and not to mention the stability guarantees that we talked about before. So like there is not a single tool that fits the use case of Node and therefore it's very hard to choose. In the past, there were a lot of issues between CommonJS and ESM interoperability. So until those were fixed, it would have been a half-baked feature to integrate TypeScript. But now those are finally fixed. And so we had a chance to support TypeScript. Source maps. So whenever you transpile your code, you change the position of your code inside file by transforming TypeScript into JavaScript. So you would need source maps to be able to debug effectively and to reconstruct the location of everything in your source code. But source maps add a lot of overhead.

3. TypeStripping: Implementing TypeScript in Node.js

Short description:

Enabling TypeScript globally would cause breaking changes. The implementation, called TypeStripping, focuses on transpilation instead of type checking. TypeStripping removes non-JavaScript features and eliminates the need for TSConfig. Inline types are removed, source maps are not required, and TypeStripping remains stable across TypeScript versions.

And if you enable them, you enable them globally, meaning they would also be enabled for your JavaScript. This is quite a problem because it would be a breaking change. And finally, no champion. It means that nobody wanted to do this work of having, like implementing the feature and having everyone to agree. Well, I did champion this initiative, so I started working on this in July 2024 and the way that I choose to implement TypeScript is called TypeStripping.

The way I implemented TypeScript is to not do type checking, only transpilation. The reason why is that type checking is the most unstable part of TypeScript and there is no spec. So the only way to perform type checking is through the TypeScript NPM package. So we expect users to download this package independently so they can upgrade their versions independently. They can configure their TSConfig without the runtime providing default values. And the problem is also that type checking is not something that you want. It's not something that you do during your development cycle. You only do like during CI or whenever you finish developing your feature. So you already have your IDE that shows you whenever there are errors in types. So this was not something that we wanted to provide as a runtime.

Also, since we don't want to support a TSConfig, this technique of TypeStripping does not involve TSConfig. TypeStripping, what it does is basically removes everything from TypeScript that is not JavaScript. And if the result is valid JavaScript, it will run it. It doesn't need a TSConfig because all the TypeScript features are removed. And this is exactly what it does. It removes inline types. Not everything is an inline type, so we will see that a bit later, how it works and what are the problems that arise from TypeStripping. But imagine that you define a variable that is a string. That little part string can be removed safely because it does not affect the runtime. It does not require source maps. We use a little magic trick to avoid changing the location inside the file during transpilation. So this solution does not require source maps, which means that the position in the file is one-to-one to where you write, it will be executed. And TypeStripping is stable across TypeScript versions because type checking is highly unstable, but the transpilation is quite stable. Doesn't change much. TypeScript has not added new keywords in a while, so it's pretty safe.

4. TypeStripping: How It Works and the Amaro Package

Short description:

TypeStripping erases non-JavaScript code, preserving the original location by replacing removed syntax with whitespace. SWC, a battle-tested NPM package, provides the necessary compatibility and speed for type stripping. The customized versions of SWC were shipped quickly by the incredible maintainers. SWC is wrapped into the Amaro package, allowing independent upgrades and compatibility with different TypeScript versions. A PR to support experimental strip types was opened in July last year.

We talked with TypeScript team and they assured us of this stability. So how does TypeStripping work? We can imagine as this is some TypeScript code, we can just take a rubber and erase everything. So interfaces are not part of JavaScript. We can erase them. This is an inline type. We can erase it because it's not part of JavaScript. So the end result looks like this. This is valid JavaScript. So this is something that node can execute.

The problem is that this requires source maps because we have changed the position inside the file. But if we replace the syntax that we have removed with whitespace, is it possible to preserve the original location? So whenever we remove inline types, we replace them with blank space and therefore we don't need source maps. So to achieve this, we used a variant of SWC. SWC was in TypeScript. It's an NPM package that releases a WASM web assembly. So Node.js builds for many different platforms and having WASMs allows us to support all the different platforms that otherwise a Rust project would not support because Rust builds on different platforms than Node.js.

We needed something compatible with everything. It's battle tested because it's used by a lot of popular projects in the ecosystem, RSpark, Deno and so many projects use SWC. It supports type stripping. So it allows us to do what we talked about before. It's very fast and the maintainers are incredible. They helped us a lot. They were able to ship these customized versions of SWC in days since we started to work on TypeScript and this helped us a lot. So a big shout out to SWC maintainers. We decided to wrap SWC into a package called Amaro. So this allows users to upgrade their TypeScript and Spiler versions independently. So you can use Amaro as an external loader and this allows you not to be stuck on a TypeScript version. But if TypeScript releases new features, Amaro will be updated. You can use Amaro independently from the version used inside Node. So this is the reason why we wrapped into a package. So in July last year, I opened this PR to support experimental strip types.

5. Experimental Strip Types and Transform Types

Short description:

Node 22.6 introduced the Experimental Strip Types flag, supporting erasable TypeScript features. However, namespaces and enums that affect the runtime cannot be erased. To consume all TypeScript syntax, the Experimental Transform Types flag can be used with source maps enabled.

This PR landed in 20 days, which is very fast considering Node.js time, which was great. So in Node 22.6, we shipped this new experimental flag called Experimental Strip Types. It has some limitations. So we can only support features that can be erased. Not all TypeScript features can be erased. Some of them, for example, namespaces and enums require to be transformed in JavaScript because they do affect the runtime. For example, this is a namespace and it exports a function, enums export some values. These are not just types. These are values and they cannot be erased. So if your namespace exports only types from Node 23.8, they can be supported. But if they export values that affect the runtimes, they cannot be supported. They will throw an error during translation. But to overcome this obstacle, we created a new flag called Experimental Transform Types. This allows you to consume all the TypeScript syntax. So this requires source maps to be enabled, but you can use enums, you can use namespace, you can use all the TypeScript syntax that you want at the cost of having source maps enabled.

6. TypeScript Limitations and Code Migration

Short description:

Namespace and enum in JavaScript and code generation from TypeScript. Custom paths not supported. Limitations: features requiring transformation are not down-leveled, explicit file extension required for imports. TypeScript 5.7 introduced path rewriting for relative paths. Existing code can be migrated using correct-yes-specifiers.

For example, this is what namespace and enum looks like in JavaScript. So there is a code generation from TypeScript to JavaScript. And by default, we want to avoid this kind of code generations. Also, custom paths are not supported. Because it requires TS config, but you can use Node.js subpath imports that are supported and do exactly the same thing. So you can use them to alias a specific path inside your project.

So the first limitation, as I said, features that require transformation. We do not perform down leveling, which means that if it's a syntax that is going to be supported by the JavaScript engine, for example, decorators or explicit resource management, the TypeScript compiler will not perform transpilation of those because they will be supported eventually in a new Node.js version. So the using keyword, it will not be transpiled, it will not be down leveled into JavaScript that is compatible. So it will be left there. And if the JavaScript engine supports it, it will be possible to run it. Otherwise, it will throw a syntax error. Same for decorators. They will come soon into the language. So there was no reason to polyfill the behavior of decorators.

Another limitation is you have to be explicit when you import a file. If it's a TypeScript file, you need to use the .ts extension. Otherwise, you need to use the .js extension. In the past in TypeScript, we always have to use the .javascript extension when importing a file because that file would be transpiled into JavaScript. But at runtime, that file is a TypeScript file. So we need to be explicit. In the past, you were already able to use the .ts extension into TypeScript, but you could not transpile it. You could only use it in combination with the noemit flag. This behavior has changed since TypeScript 5.7. A new feature called path rewriting for relative paths was developed by the TypeScript team specifically to support Node.js experimental strip types. So with this new flag, during transpilation, it will rewrite the extensions to match the destination. So whenever you transpile a .ts file, it will become a .js file, and that will match. But what about existing source code? So it is possible with a code mode to migrate existing code base to support this behavior that Node.js enforces. You can use this code mode called correct-yes-specifiers by Jacob, one of the Node.js collaborators. It will transform all the syntax, all the imports that are not supported into imports that are supported.

7. TypeScript Import Types and Syntax Detection

Short description:

Work in progress. Type keyword required for type imports. Running TypeScript files in Node modules is not possible to avoid compatibility issues. Experimental strip types enabled by default in Node 23.6. TypeScript syntax detection in Eval to handle different modules.

This is a work in progress, so you can read more about this on NPM.

Another important limitation is that the type keyword is required for type imports. So whenever you are importing a type, you need to specify that that is a type. For example, in the first case, we import type 1 and 2. We use the type keyword. If we don't use it, Node.js will think that that is a value and not a type, so it will not erase it. While if it's a type, it can be safely erased, and it will cause a runtime error.

Also, an important limitation is that it's not possible to run TypeScript files in Node modules. This is to avoid disrupting the ecosystem because by publishing TypeScript, it would create a lot of incompatibilities. So if you ever try to run a TypeScript file inside the Node modules, we draw an error called unsupported Node modules TypeScript. The reason why this was specifically enforced by the TypeScript team is because it would cause a lot of compatibility versions, and your IDE would perform type checkings on Node modules, and we know how big Node modules are, so we don't want to do this. In Node 23.6, we enabled experimental strip types by default. So you can run Node file.ts by default without passing any flag.

Also, we have worked on TypeScript syntax detection in Eval. This is a very interesting topic. So this is, for example, we can see import util from util, and cost foo is a string value a word. This is a TypeScript ESM string. So Node.js tries to evaluate if the syntax is a common JS module, which it's not. It will try again as an ES module, but it's not because it's TypeScript. So that will fail. If it fails, it will try to strip the types, so it will try to transpile, like remove the string from this, the dot string type from this string. So foo now, this is plain JavaScript, and this is ESM plain JavaScript. So if this fails, it means that you have a syntax error, or the syntax is unsupported. So it will throw the error from the step two, plus the TypeScript compiler message. This is to avoid breaking changes in the error that is thrown. And it will try again to execute the string as a common JS, but we know it's ESM, so it will fail. And it will finally try again as a ESM module, which is correct. So you can see the syntax detection is very complicated. But you can skip all of this overhead by specifying which kind of syntax it is. So you can use the flag dash dash input type to say that this is a module TypeScript, or common JS TypeScript, and Node will know exactly what to do.

8. Ambiguity in Syntax and Future Steps

Short description:

Ambiguity in syntax: JavaScript vs TypeScript. TypeScript introduces erasable syntax only flag to ensure compatibility with Node.js. Future steps include bug fixing, performance improvements, and upcoming Node.js releases. Join us on the Node.js TypeScript repo for more information.

There is some syntax that is ambiguous. For example, fetch object. This looks like TypeScript, but this is valid JavaScript. If you try to execute it in Node, it will return false. And if you try in the browser, it would also return false. This is because the angular is detected as lesser. So it's a valid JavaScript syntax. And there is ambiguity because if you try to execute this in the TS playground, this will be executed as a fetch. So it will actually perform an HTTP call. If you try to execute it in Node with the input type as common JS TypeScript, it will also perform a fetch. So as you can see, the same syntax, if it's JavaScript or TypeScript, it changes the behavior. So this is a big problem.

TypeScript, in the latest release, announced a new flag called erasable syntax only. This will match the behavior of Node.js, so all the syntax that is not supported by Node.js will throw an error in TypeScript when you type check. This is very good because now you can type check and make sure that the syntax you're writing can be executed by Node. This is the TypeScript config that we suggest to our users. So all the flags that we talked about before.

And so what are the next steps? I will keep bug fixing it, I will work on making it faster and I'm working on flagging it in Node 22, and hopefully make it stable in Node 24 that's coming in very soon. So if you give it a try, you can join us on the Node.js TypeScript repo. We have meetings, you can check the Node.js calendar and that's it. Thank you for listening.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React's Most Useful Types
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
Top Content
Watch video: React's Most Useful Types
Today's Talk focuses on React's best types and JSX. It covers the types of JSX and React components, including React.fc and React.reactnode. The discussion also explores JSX intrinsic elements and react.component props, highlighting their differences and use cases. The Talk concludes with insights on using React.componentType and passing components, as well as utilizing the react.element ref type for external libraries like React-Select.
TypeScript and React: Secrets of a Happy Marriage
React Advanced 2022React Advanced 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
Making Magic: Building a TypeScript-First Framework
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
Top Content
Daniel Rowe discusses building a TypeScript-first framework at TypeScript Congress and shares his involvement in various projects. Nuxt is a progressive framework built on Vue.js, aiming to reduce friction and distraction for developers. It leverages TypeScript for inference and aims to be the source of truth for projects. Nuxt provides type safety and extensibility through integration with TypeScript. Migrating to TypeScript offers long-term maintenance benefits and can uncover hidden bugs. Nuxt focuses on improving existing tools and finds inspiration in frameworks like TRPC.
ESM Loaders: Enhancing Module Loading in Node.js
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Top Content
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
Towards a Standard Library for JavaScript Runtimes
Node Congress 2022Node Congress 2022
34 min
Towards a Standard Library for JavaScript Runtimes
Top Content
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.

Workshops on related topic

React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Mastering advanced concepts in TypeScript
React Summit US 2023React Summit US 2023
132 min
Mastering advanced concepts in TypeScript
Top Content
Featured WorkshopFree
Jiri Lojda
Jiri Lojda
TypeScript is not just types and interfaces. Join this workshop to master more advanced features of TypeScript that will make your code bullet-proof. We will cover conditional types and infer notation, template strings and how to map over union types and object/array properties. Each topic will be demonstrated on a sample application that was written with basic types or no types at all and we will together improve the code so you get more familiar with each feature and can bring this new knowledge directly into your projects.
You will learn:- - What are conditional types and infer notation- What are template strings- How to map over union types and object/array properties.
Deep TypeScript Tips & Tricks
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Top Content
Featured Workshop
Josh Goldberg
Josh Goldberg
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
Best Practices and Advanced TypeScript Tips for React Developers
React Advanced 2022React Advanced 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Node.js Masterclass
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Top Content
Workshop
Matteo Collina
Matteo Collina
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.