# Wasp 0.21 Full Documentation > This is the full documentation for the latest version of Wasp. > For other versions, see the links below. ## Full Documentation by Version - [0.20](https://wasp.sh/llms-full-0.20.txt) - [0.19](https://wasp.sh/llms-full-0.19.txt) - [0.18](https://wasp.sh/llms-full-0.18.txt) - [0.17](https://wasp.sh/llms-full-0.17.txt) - [0.16](https://wasp.sh/llms-full-0.16.txt) - [0.15](https://wasp.sh/llms-full-0.15.txt) - [0.14](https://wasp.sh/llms-full-0.14.txt) - [0.13](https://wasp.sh/llms-full-0.13.txt) - [0.12](https://wasp.sh/llms-full-0.12.txt) - [0.11.8](https://wasp.sh/llms-full-0.11.8.txt) --- # Getting Started ## Introduction :::note If you are looking for the installation instructions, check out the [Quick Start](./quick-start.md) section. ::: We will give a brief overview of what Wasp is, how it works on a high level and when to use it. ### Wasp is a tool to build modern web applications It is an opinionated way of building **full-stack web applications**. It takes care of all three major parts of a web application: **client** (front-end), **server** (back-end) and **database**. #### Works well with your existing stack Wasp is not trying to do everything at once but rather focuses on the complexity that arises from connecting all the parts of the stack (client, server, database, deployment). Wasp is using **React**, **Node.js** and **Prisma** under the hood and relies on them to define web components and server queries and actions. #### Wasp's secret sauce At the core is the Wasp compiler which takes the Wasp config and your Javascript code and outputs the client app, server app and deployment code. The cool thing about having a compiler that understands your code is that it can do a lot of things for you. Define your app in the Wasp config and get: - login and signup with Auth UI components, - full-stack type safety, - e-mail sending, - async processing jobs, - React Query powered data fetching, - security best practices, - and more. You don't need to write any code for these features, Wasp will take care of it for you đŸ¤¯ And what's even better, Wasp also maintains the code for you, so you don't have to worry about keeping up with the latest security best practices. As Wasp updates, so does your app. ### So what does the code look like? Let's say you want to build a web app that allows users to **create and share their favorite recipes**. Let's start with the `main.wasp` file: it is the central file of your app, where you describe the app from the high level. Let's give our app a title and let's immediately turn on the full-stack authentication via username and password: ```wasp title="main.wasp" app RecipeApp { title: "My Recipes", wasp: { version: "{latestWaspVersion}" }, auth: { methods: { usernameAndPassword: {} }, onAuthFailedRedirectTo: "/login", userEntity: User } } ``` Let's then add the data models for your recipes. Wasp understands and uses the models from the `schema.prisma` file. We will want to have Users and Users can own Recipes: ```prisma title="schema.prisma" ... // Data models are defined using Prisma Schema Language. model User { id Int @id @default(autoincrement()) recipes Recipe[] } model Recipe { id Int @id @default(autoincrement()) title String description String? userId Int user User @relation(fields: [userId], references: [id]) } ``` Next, let's define how to do something with these data models! We do that by defining Operations, in this case, a Query `getRecipes` and Action `addRecipe`, which are in their essence Node.js functions that execute on the server and can, thanks to Wasp, very easily be called from the client. First, we define these Operations in our `main.wasp` file, so Wasp knows about them and can "beef them up": ```wasp title="main.wasp" // Queries have automatic cache invalidation and are type-safe. query getRecipes { fn: import { getRecipes } from "@src/recipe/operations", entities: [Recipe], } // Actions are type-safe and can be used to perform side-effects. action addRecipe { fn: import { addRecipe } from "@src/recipe/operations", entities: [Recipe], } ``` ... and then implement them in our Javascript (or TypeScript) code (we show just the query here, using TypeScript): ```ts title="src/recipe/operations.ts" // Wasp generates the types for you. export const getRecipes: GetRecipes<{}, Recipe[]> = async (_args, context) => { return context.entities.Recipe.findMany( // Prisma query { where: { user: { id: context.user.id } } } ); }; export const addRecipe ... ``` Now we can very easily use these in our React components! For the end, let's create a home page of our app. First, we define it in `main.wasp`: ```wasp title="main.wasp" ... route HomeRoute { path: "/", to: HomePage } page HomePage { component: import { HomePage } from "@src/pages/HomePage", authRequired: true // Will send user to /login if not authenticated. } ``` and then implement it as a React component in JS/TS (that calls the Operations we previously defined): ```tsx title="src/pages/HomePage.tsx" export function HomePage({ user }: { user: User }) { // Due to full-stack type safety, `recipes` will be of type `Recipe[]` here. const { data: recipes, isLoading } = useQuery(getRecipes) // Calling our query here! if (isLoading) { return
Loading...
} return (

Recipes

    {recipes ? recipes.map((recipe) => (
  • {recipe.title}
    {recipe.description}
  • )) : 'No recipes defined yet!'}
) } ``` And voila! We are listing all the recipes in our app 🎉 This was just a quick example to give you a taste of what Wasp is. For step by step tour through the most important Wasp features, check out the [Todo app tutorial](../tutorial/01-create.md). :::note Above we skipped defining `/login` and `/signup` pages to keep the example a bit shorter, but those are very simple to do by using Wasp's Auth UI feature. ::: ### When to use Wasp Wasp addresses the same core problems that typical web app frameworks are addressing, and it in big part [looks, swims and quacks](https://en.wikipedia.org/wiki/Duck_test) like a web app framework. #### Best used for - building full-stack web apps (like e.g. Airbnb or Asana) - quickly starting a web app with industry best practices - to be used alongside modern web dev stack (React and Node.js are currently supported) #### Avoid using Wasp for - building static/presentational websites - to be used as a no-code solution - to be a solve-it-all tool in a single language ### Wasp is a DSL :::note You don't need to know what a DSL is to use Wasp, but if you are curious, you can read more about it below. ::: Wasp does not match typical expectations of a web app framework: it is not a set of libraries, it is instead a simple programming language that understands your code and can do a lot of things for you. Wasp is a programming language, but a specific kind: it is specialized for a single purpose: **building modern web applications**. We call such languages _DSL_s (Domain Specific Language). Other examples of _DSL_s that are often used today are e.g. _SQL_ for databases and _HTML_ for web page layouts. The main advantage and reason why _DSL_s exist is that they need to do only one task (e.g. database queries) so they can do it well and provide the best possible experience for the developer. The same idea stands behind Wasp - a language that will allow developers to **build modern web applications with 10x less code and less stack-specific knowledge**. ## Quick Start ### Installation Welcome, new Waspeteer 🐝! Let's create and run our first Wasp app in 3 short steps: 1. **To install Wasp on Linux / OSX / WSL (Windows), open your terminal and run:** ```shell npm i -g @wasp.sh/wasp-cli@latest ``` â„šī¸ Wasp requires Node.js and npm, which are usually installed together: check below for [more details](#requirements). 2. **Then, create a new app by running:** ```shell wasp new ``` 3. **Finally, run the app:** ```shell cd wasp start ``` That's it 🎉 You have successfully created and served a new full-stack web app at [http://localhost:3000](http://localhost:3000) and Wasp is serving both frontend and backend for you. :::note Something Unclear? Check [More Details](#more-details) section below if anything went wrong with the installation, or if you have additional questions. ::: :::tip Want an even faster start? Try out [Wasp AI](../wasp-ai/creating-new-app.md) 🤖 to generate a new Wasp app in minutes just from a title and short description! ::: :::tip Having trouble running Wasp? If you get stuck with a weird error while developing with Wasp, try running `wasp clean` - this is the Wasp equivalent of "turning it off and on again"! Do however let us know about the issue on our GitHub repo or Discord server. ::: #### What next? - [ ] 👉 **Check out the [Todo App tutorial](../tutorial/01-create.md), which will take you through all the core features of Wasp!** 👈 - [ ] [Setup your editor](./editor-setup.md) for working with Wasp. - [ ] Join us on [Discord](https://discord.gg/rzdnErX)! Any feedback or questions you have, we are there for you. - [ ] Follow Wasp development by subscribing to our newsletter: https://wasp.sh/#signup . We usually send 1 per month, and [Matija](https://github.com/matijaSos) does his best to unleash his creativity to make them engaging and fun to read :D! --- ### More details #### Requirements You must have Node.js (and NPM) installed on your machine and available in `PATH`. A version of Node.js must be >= 22.12. If you need it, we recommend using [nvm](https://github.com/nvm-sh/nvm) for managing your Node.js installation version(s).
A quick guide on installing/using nvm
Install nvm via your OS package manager (`apt`, `pacman`, `homebrew`, ...) or via the [nvm](https://github.com/nvm-sh/nvm#install--update-script) install script. Then, install a version of Node.js that you need: ```shell nvm install 22 ``` Finally, whenever you need to ensure a specific version of Node.js is used, run: ```shell nvm use 22 ``` to set the Node.js version for the current shell session. You can run ```shell node -v ``` to check the version of Node.js currently being used in this shell session. Check NVM repo for more details: https://github.com/nvm-sh/nvm.
#### Installation {#detailed-installation} Open your terminal and run: ```shell npm i -g @wasp.sh/wasp-cli@latest ``` :::note Looking for the old installer script? Check out the **[Legacy installer guide](../guides/legacy/installer.md)** for instructions on how to keep using it or how to migrate to npm-based installation. ::: With Wasp for Windows, we are almost there: Wasp is successfully compiling and running on Windows but there is a bug or two stopping it from fully working. Check it out [here](https://github.com/wasp-lang/wasp/issues/48) if you are interested in helping. In the meantime, the best way to start using Wasp on Windows is by using [WSL](https://learn.microsoft.com/en-us/windows/wsl/install). Once you set up Ubuntu on WSL, just follow Linux instructions for installing Wasp. You can refer to this [article](https://wasp.sh/blog/2023/11/21/guide-windows-development-wasp-wsl) if you prefer a step by step guide to using Wasp in WSL environment. If you need further help, reach out to us on [Discord](https://discord.gg/rzdnErX) - we have some community members using WSL that might be able to help you. :::caution If you are using WSL2, make sure that your Wasp project is not on the Windows file system, but instead on the Linux file system. Otherwise, Wasp won't be able to detect file changes, due to the [issue in WSL2](https://github.com/microsoft/WSL/issues/4739). ::: If the other methods are not working for you or your OS is not supported, you can try building Wasp from the source. To install from source, you need to clone the [wasp repo](https://github.com/wasp-lang/wasp), install [Cabal](https://cabal.readthedocs.io/en/stable/getting-started.html) on your machine and then run `cabal install` from the `waspc/` dir. If you have never built Wasp before, this might take some time due to `cabal` downloading dependencies for the first time. Check [waspc/](https://github.com/wasp-lang/wasp/tree/main/waspc) for more details on building Wasp from the source. ## Editor Setup :::note This page assumes you have already installed Wasp. If you do not have Wasp installed yet, check out the [Quick Start](./quick-start.md) guide. ::: Wasp comes with the Wasp language server, which gives supported editors powerful support and integration with the language. ### VSCode Currently, Wasp only supports integration with VSCode. Install the [Wasp language extension](https://marketplace.visualstudio.com/items?itemName=wasp-lang.wasp) to get syntax highlighting and integration with the Wasp language server. The extension enables: - syntax highlighting for `.wasp` files - the Prisma extension for `.prisma` files - scaffolding of new project files - code completion - diagnostics (errors and warnings) - go to definition and more! ------ # Tutorial ## 1. Creating a New Project :::info You'll need to have the latest version of Wasp installed locally to follow this tutorial. If you haven't installed it yet, check out the [QuickStart](../quick-start) guide! ::: In this section, we'll guide you through the process of creating a simple Todo app with Wasp. In the process, we'll take you through the most important and useful features of Wasp. How Todo App will work once it is done

If you get stuck at any point (or just want to chat), reach out to us on [Discord](https://discord.gg/rzdnErX) and we will help you! You can find the complete code of the app we're about to build [here](https://github.com/wasp-lang/wasp/tree/release/examples/tutorials/TodoApp). ### Creating a Project To setup a new Wasp project, run the following command in your terminal: ```sh wasp new TodoApp -t minimal ``` We are using the `minimal` template because we're going to implement the app from scratch, instead of the more full-featured default template. Enter the newly created directory and start the development server: ```sh cd TodoApp wasp start ``` `wasp start` will take a bit of time to start the server the first time you run it in a new project. You will see log messages from the client, server, and database setting themselves up. When everything is ready, a new tab should open in your browser at `http://localhost:3000` with a simple placeholder page: Screenshot of the Wasp minimal starter app

Wasp has generated for you the full front-end and back-end code of the app! Next, we'll take a closer look at how the project is structured. ### A note on supported languages Wasp supports both JavaScript and TypeScript out of the box, but you are free to choose between or mix JavaScript and TypeScript as you see fit. We'll provide you with both JavaScript and TypeScript code in this tutorial. Code blocks will have a toggle to switch between vanilla JavaScript and TypeScript. Try it out: :::note Welcome to JavaScript! You are now reading the JavaScript version of the docs. The site will remember your preference as you switch pages. You'll have a chance to change the language on every code snippet - both the snippets and the text will update accordingly. ::: :::note Welcome to TypeScript! You are now reading the TypeScript version of the docs. The site will remember your preference as you switch pages. You'll have a chance to change the language on every code snippet - both the snippets and the text will update accordingly. ::: ## 2. Project Structure By default, Wasp will create a TypeScript project. We recommend using TypeScript in new projects, and you can always mix-and-match TypeScript and JavaScript files. To use JavaScript in the main page, you must manually rename the file `src/MainPage.tsx` to `src/MainPage.jsx`. Restart `wasp start` after you do this. No updates to the `main.wasp` file are necessary - it stays the same regardless of the language you use. After creating a new Wasp project and renaming the `src/MainPage.tsx` file, your project should look like this: ```python . ├── .gitignore ├── main.wasp # Your Wasp code goes here. ├── schema.prisma # Your database models go here. ├── package.json # Your dependencies and project info go here. ├── public # Your static files (e.g., images, favicon) go here. │   └── favicon.ico ├── src # Your source code (JS/React/Node.js) goes here. │   ├── Main.css # highlight-next-line │   ├── MainPage.jsx │   ├── assets │   │   └── logo.svg │   └── vite-env.d.ts ├── tsconfig.json └── vite.config.ts ``` After creating a new Wasp project, your project should look like this: ```python . ├── .gitignore ├── main.wasp # Your Wasp code goes here. ├── schema.prisma # Your database models go here. ├── package.json # Your dependencies and project info go here. ├── public # Your static files (e.g., images, favicon) go here. │   └── favicon.ico ├── src # Your source code (TS/React/Node.js) goes here. │   ├── Main.css │   ├── MainPage.tsx │   ├── assets │   │   └── logo.svg │   └── vite-env.d.ts ├── tsconfig.json └── vite.config.ts ``` By _your code_, we mean the _"the code you write"_, as opposed to the code generated by Wasp. Wasp allows you to organize and structure your code however you think is best - there's no need to separate client files and server files into different directories. We'd normally recommend organizing code by features (i.e., vertically). However, since this tutorial contains only a handful of files, there's no need for fancy organization. We'll keep it simple by placing everything in the root `src` directory. Many other files (e.g., `tsconfig.json`, `vite-env.d.ts`, `.wasproot`, etc.) help Wasp and the IDE improve your development experience with autocompletion, IntelliSense, and error reporting. The `vite.config.ts` file is used to configure [Vite](https://vitejs.dev/guide/), Wasp's build tool of choice. We won't be configuring Vite in this tutorial, so you can safely ignore the file. Still, if you ever end up wanting more control over Vite, you'll find everything you need to know in [custom Vite config docs](../project/custom-vite-config.md). The `schema.prisma` file is where you define your database schema using [Prisma](https://www.prisma.io/). We'll cover this a bit later in the tutorial. The most important file in the project is `main.wasp`. Wasp uses the configuration within it to perform its magic. Based on what you write, it generates a bunch of code for your database, server-client communication, React routing, and more. Let's take a closer look at `main.wasp` ### `main.wasp` `main.wasp` is your app's definition file. It defines the app's central components and helps Wasp to do a lot of the legwork for you. :::tip Wasp TS config \[Early-preview feature\] If you wish, you can alternatively define your [Wasp config in TS](../general/wasp-ts-config.md) (`main.wasp.ts`) instead of `main.wasp`. ::: The file is a list of _declarations_. Each declaration defines a part of your app. The default `main.wasp` file generated with `wasp new` on the previous page looks like this: ```wasp title="main.wasp" app TodoApp { wasp: { version: "{latestWaspVersion}" // Pins the version of Wasp to use. }, title: "TodoApp", // Used as the browser tab title. Note that all strings in Wasp are double quoted! head: [ "", ] } route RootRoute { path: "/", to: MainPage } page MainPage { // We specify that the React implementation of the page is exported from // `src/MainPage.jsx`. This statement uses standard JS import syntax. // Use `@src` to reference files inside the `src` folder. component: import { MainPage } from "@src/MainPage" } ``` ```wasp title="main.wasp" app TodoApp { wasp: { version: "{latestWaspVersion}" // Pins the version of Wasp to use. }, title: "TodoApp", // Used as the browser tab title. Note that all strings in Wasp are double quoted! head: [ "", ] } route RootRoute { path: "/", to: MainPage } page MainPage { // We specify that the React implementation of the page is exported from // `src/MainPage.tsx`. This statement uses standard JS import syntax. // Use `@src` to reference files inside the `src` folder. component: import { MainPage } from "@src/MainPage" } ``` This file uses three declaration types: - **app**: Top-level configuration information about your app. - **route**: Describes which path each page should be accessible from. - **page**: Defines a web page and the React component that gets rendered when the page is loaded. In the next section, we'll explore how **route** and **page** work together to build your web app. ## 3. Pages & Routes In the default `main.wasp` file created by `wasp new`, there is a **page** and a **route** declaration: ```wasp title="main.wasp" route RootRoute { path: "/", to: MainPage } page MainPage { // We specify that the React implementation of the page is exported from // `src/MainPage.jsx`. This statement uses standard JS import syntax. // Use `@src` to reference files inside the `src` folder. component: import { MainPage } from "@src/MainPage" } ``` ```wasp title="main.wasp" route RootRoute { path: "/", to: MainPage } page MainPage { // We specify that the React implementation of the page is exported from // `src/MainPage.tsx`. This statement uses standard JS import syntax. // Use `@src` to reference files inside the `src` folder. component: import { MainPage } from "@src/MainPage" } ``` Together, these declarations tell Wasp that when a user navigates to `/`, it should render the named export from `src/MainPage.{jsx,tsx}`. ### The MainPage Component Let's take a look at the React component referenced by the page declaration: ```tsx title="src/MainPage.tsx" auto-js export function MainPage() { // ... }; ``` This is a regular functional React component. It also imports some CSS and a logo from the `assets` folder. That is all the code you need! Wasp takes care of everything else necessary to define, build, and run the web app. ### Adding a Second Page To add more pages, you can create another set of **page** and **route** declarations. You can even add parameters to the URL path, using the same syntax as [React Router](https://reactrouter.com/7.12.0/start/declarative/routing#dynamic-segments). Let's test this out by adding a new page: ```wasp title="main.wasp" route HelloRoute { path: "/hello/:name", to: HelloPage } page HelloPage { component: import { HelloPage } from "@src/HelloPage" } ``` When a user visits `/hello/their-name`, Wasp renders the component exported from `src/HelloPage.{jsx,tsx}` and you can use the `useParams` hook from `react-router` to access the `name` parameter: ```tsx title="src/HelloPage.tsx" auto-js export const HelloPage = () => { const { name } = useParams<"name">(); return
Here's {name}!
; }; ``` Now you can visit `/hello/johnny` and see "Here's johnny!" :::tip Type-safe links Since you are using Typescript, you can benefit from using Wasp's type-safe `Link` component and the `routes` object. Check out the [type-safe links docs](../advanced/links) for more details. ::: ### Cleaning Up Now that you've seen how Wasp deals with Routes and Pages, it's finally time to build the Todo app. Start by cleaning up the starter project and removing unnecessary code and files. First, remove most of the code from the `MainPage` component: ```tsx title="src/MainPage.tsx" auto-js export const MainPage = () => { return
Hello world!
; }; ``` At this point, the main page should look like this: Todo App - Hello World You can now delete redundant files: `src/Main.css`, `src/assets/logo.svg`, and `src/HelloPage.{jsx,tsx}` (we won't need this page for the rest of the tutorial). Since `src/HelloPage.{jsx,tsx}` no longer exists, remove its `route` and `page` declarations from the `main.wasp` file. Your Wasp file should now look like this: ```wasp title="main.wasp" app TodoApp { wasp: { version: "{latestWaspVersion}" }, title: "TodoApp", head: [ "", ] } route RootRoute { path: "/", to: MainPage } page MainPage { component: import { MainPage } from "@src/MainPage" } ```
Excellent work! You now have a basic understanding of Wasp and are ready to start building your TodoApp. We'll implement the app's core features in the following sections. ## 4. Database Entities Entities are one of the most important concepts in Wasp and are how you define what gets stored in the database. Wasp uses Prisma to talk to the database, and you define Entities by defining Prisma models in the `schema.prisma` file. Since our Todo app is all about tasks, we'll define a Task entity by adding a Task model in the `schema.prisma` file: ```prisma title="schema.prisma" // ... model Task { id Int @id @default(autoincrement()) description String isDone Boolean @default(false) } ``` :::note Read more about how Wasp Entities work in the [Entities](../data-model/entities.md) section or how Wasp uses the `schema.prisma` file in the [Prisma Schema File](../data-model/prisma-file.md) section. ::: To update the database schema to include this entity, stop the `wasp start` process, if it's running, and run: ```sh wasp db migrate-dev ``` You'll need to do this any time you change an entity's definition. It instructs Prisma to create a new database migration and apply it to the database. To take a look at the database and the new `Task` entity, run: ```sh wasp db studio ``` This will open a new page in your browser to view and edit the data in your database. Todo App - Db studio showing Task schema Click on the `Task` entity and check out its fields! We don't have any data in our database yet, but we are about to change that. ## 5. Querying the Database We want to know which tasks we need to do, so let's list them! The primary way of working with Entities in Wasp is with [Queries and Actions](../data-model/operations/overview), collectively known as **_Operations_**. Queries are used to read an entity, while Actions are used to create, modify, and delete entities. Since we want to list the tasks, we'll want to use a Query. To list the tasks, you must: 1. Create a Query that fetches the tasks from the database. 2. Update the `MainPage.{jsx,tsx}` to use that Query and display the results. ### Defining the Query We'll create a new Query called `getTasks`. We'll need to declare the Query in the Wasp file and write its implementation in JSTS. #### Declaring a Query We need to add a **query** declaration to `main.wasp` so that Wasp knows it exists: ```wasp title="main.wasp" // ... query getTasks { // Specifies where the implementation for the query function is. // The path `@src/queries` resolves to `src/queries.js`. // No need to specify an extension. fn: import { getTasks } from "@src/queries", // Tell Wasp that this query reads from the `Task` entity. Wasp will // automatically update the results of this query when tasks are modified. entities: [Task] } ``` ```wasp title="main.wasp" // ... query getTasks { // Specifies where the implementation for the query function is. // The path `@src/queries` resolves to `src/queries.ts`. // No need to specify an extension. fn: import { getTasks } from "@src/queries", // Tell Wasp that this query reads from the `Task` entity. Wasp will // automatically update the results of this query when tasks are modified. entities: [Task] } ``` :::note To generate the types used in the next section, make sure that `wasp start` is still running. ::: #### Implementing a Query Next, create a new file called `src/queries.js` and define the JavaScript function we've just imported in our `query` declaration: Next, create a new file called `src/queries.ts` and define the TypeScript function we've just imported in our `query` declaration: ```ts title="src/queries.ts" auto-js export const getTasks: GetTasks = async (args, context) => { return context.entities.Task.findMany({ orderBy: { id: "asc" }, }); }; ``` Wasp automatically generates the types `GetTasks` and `Task` based on the contents of `main.wasp`: - `Task` is a type corresponding to the `Task` entity you defined in `schema.prisma`. - `GetTasks` is a generic type Wasp automatically generated based on the `getTasks` Query you defined in `main.wasp`. You can use these types to specify the Query's input and output types. This Query doesn't expect any arguments (its input type is `void`), but it does return an array of tasks (its output type is `Task[]`). Annotating the Queries is optional, but highly recommended because doing so enables **full-stack type safety**. We'll see what this means in the next step. Query function parameters: - `args: object` The arguments the caller passes to the Query. - `context` An object with extra information injected by Wasp. Its type depends on the Query declaration. Since the Query declaration in `main.wasp` says that the `getTasks` Query uses `Task` entity, Wasp injected a [Prisma client](https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/crud) for the `Task` entity as `context.entities.Task` - we used it above to fetch all the tasks from the database. :::info Queries and Actions are NodeJS functions executed on the server. ::: ### Invoking the Query On the Frontend While we implement Queries on the server, Wasp generates client-side functions that automatically take care of serialization, network calls, and cache invalidation, allowing you to call the server code like it's a regular function. This makes it easy for us to use the `getTasks` Query we just created in our React component: ```tsx title="src/MainPage.tsx" auto-js // highlight-next-line export const MainPage = () => { // highlight-start const { data: tasks, isLoading, error } = useQuery(getTasks); return (
{tasks && } {isLoading && "Loading..."} {error && "Error: " + error}
); // highlight-end }; // highlight-start const TaskView = ({ task }: { task: Task }) => { return (
{task.description}
); }; const TasksList = ({ tasks }: { tasks: Task[] }) => { if (!tasks?.length) return
No tasks
; return (
{tasks.map((task, idx) => ( ))}
); }; // highlight-end ```
Most of this code is regular React, the only exception being the twothree special `wasp` imports: - `getTasks` - The client-side Query function Wasp generated based on the `getTasks` declaration in `main.wasp`. - `useQuery` - Wasp's [useQuery](../data-model/operations/queries#the-usequery-hook-1) React hook, which is based on [react-query](https://github.com/tannerlinsley/react-query)'s hook with the same name. - `getTasks` - The client-side Query function Wasp generated based on the `getTasks` declaration in `main.wasp`. - `useQuery` - Wasp's [useQuery](../data-model/operations/queries#the-usequery-hook-1) React hook, which is based on [react-query](https://github.com/tannerlinsley/react-query)'s hook with the same name. - `Task` - The type for the Task entity defined in `schema.prisma`. Notice how you don't need to annotate the type of the Query's return value: Wasp uses the types you defined while implementing the Query for the generated client-side function. This is **full-stack type safety**: the types on the client always match the types on the server. We could have called the Query directly using `getTasks()`, but the `useQuery` hook makes it reactive: React will re-render the component every time the Query changes. Remember that Wasp automatically refreshes Queries whenever the data is modified. With these changes, you should be seeing the text "No tasks" on the screen: Todo App - No Tasks We'll create a form to add tasks in the next step đŸĒ„ ## 6. Modifying Data In the previous section, you learned about using Queries to fetch data. Let's now learn about Actions so you can add and update tasks in the database. In this section, you will create: 1. A Wasp Action that creates a new task. 2. A React form that calls that Action when the user creates a task. ### Creating a New Action Creating an Action is very similar to creating a Query. #### Declaring an Action We must first declare the Action in `main.wasp`: ```wasp title="main.wasp" // ... action createTask { fn: import { createTask } from "@src/actions", entities: [Task] } ``` #### Implementing an Action Let's now define a JavaScriptTypeScript function for our `createTask` Action: ```ts title="src/actions.ts" auto-js type CreateTaskPayload = Pick; export const createTask: CreateTask = async ( args, context, ) => { return context.entities.Task.create({ data: { description: args.description }, }); }; ``` Once again, we've annotated the Action with the `CreateTask` and `Task` types generated by Wasp. Just like with queries, defining the types on the implementation makes them available on the frontend, giving us **full-stack type safety**. :::tip We put the function in a new file `src/actions.{js,ts}`, but we could have put it anywhere we wanted! There are no limitations here, as long as the declaration in the Wasp file imports it correctly and the file is located within `src` directory. ::: ### Invoking the Action on the Client Start by defining a form for creating new tasks. ```tsx title="src/MainPage.tsx" auto-js // highlight-next-line createTask, getTasks, useQuery, } from "wasp/client/operations"; // ... MainPage, TaskView, TaskList ... // highlight-start const NewTaskForm = () => { const handleSubmit = async (event: FormEvent) => { event.preventDefault(); try { const target = event.target as HTMLFormElement; const description = target.description.value; target.reset(); await createTask({ description }); } catch (err: any) { window.alert("Error: " + err.message); } }; return (
); }; // highlight-end ```
Unlike Queries, you can call Actions directly (without wrapping them in a hook) because they don't need reactivity. The rest is just regular React code. Finally, because we've previously annotated the Action's server implementation with the correct type, Wasp knows that the `createTask` Action expects a value of type `{ description: string }` (try changing the argument and reading the error message). Wasp also knows that a call to the `createTask` Action returns a `Task` but are not using it in this example. All that's left now is adding this form to the page component: ```tsx title="src/MainPage.tsx" auto-js const MainPage = () => { const { data: tasks, isLoading, error } = useQuery(getTasks); return (
// highlight-next-line {tasks && } {isLoading && "Loading..."} {error && "Error: " + error}
); }; // ... TaskList, TaskView, NewTaskForm ... ```
Great work! You now have a form for creating new tasks. Try creating a "Build a Todo App in Wasp" task and see it appear in the list below. The task is created on the server and saved in the database. Try refreshing the page or opening it in another browser. You'll see the tasks are still there! Todo App - creating new task

:::note Automatic Query Invalidation When you create a new task, the list of tasks is automatically updated to display the new task, even though you haven't written any code that does that! Wasp handles these automatic updates under the hood. When you declared the `getTasks` and `createTask` operations, you specified that they both use the `Task` entity. So when `createTask` is called, Wasp knows that the data `getTasks` fetches may have changed and automatically updates it in the background. This means that **out of the box, Wasp keeps all your queries in sync with any changes made through Actions**. This behavior is convenient as a default but can cause poor performance in large apps. While there is no mechanism for overriding this behavior yet, it is something that we plan to include in Wasp in the future. This feature is tracked [here](https://github.com/wasp-lang/wasp/issues/63). ::: ### A Second Action Our Todo app isn't finished if you can't mark a task as done. We'll create a new Action to update a task's status and call it from React whenever a task's checkbox is toggled. Since we've already created one task together, try to create this one yourself. It should be an Action named `updateTask` that receives the task's `id` and its `isDone` status. You can see our implementation below. Declaring the Action in `main.wasp`: ```wasp title="main.wasp" // ... action updateTask { fn: import { updateTask } from "@src/actions", entities: [Task] } ``` Implementing the Action on the server: ```ts title="src/actions.ts" auto-js // ... type UpdateTaskPayload = Pick; export const updateTask: UpdateTask = async ( { id, isDone }, context, ) => { return context.entities.Task.update({ where: { id }, data: { isDone: isDone, }, }); }; ``` You can now call `updateTask` from the React component: ```tsx title="src/MainPage.tsx" auto-js // highlight-next-line updateTask, createTask, getTasks, useQuery, } from "wasp/client/operations"; // ... MainPage ... const TaskView = ({ task }: { task: Task }) => { // highlight-start const handleIsDoneChange = async (event: ChangeEvent) => { try { await updateTask({ id: task.id, isDone: event.target.checked, }); } catch (error: any) { window.alert("Error while updating task: " + error.message); } }; // highlight-end return (
{task.description}
); }; // ... TaskList, NewTaskForm ... ```
Awesome! You can now mark this task as done. It's time to make one final addition to your app: supporting multiple users. ## 7. Adding Authentication Most modern apps need a way to create and authenticate users. Wasp makes this as easy as possible with its first-class auth support. To add users to your app, you must: - [ ] Create a `User` Entity. - [ ] Tell Wasp to use the _Username and Password_ authentication. - [ ] Add login and signup pages. - [ ] Update the main page to require authentication. - [ ] Add a relation between `User` and `Task` entities. - [ ] Modify your Queries and Actions so users can only see and modify their tasks. - [ ] Add a logout button. ### Creating a User Entity Since Wasp manages authentication, it will create [the auth related entities](../auth/entities) for you in the background. Nothing to do here! You must only add the `User` Entity to keep track of who owns which tasks: ```prisma title="schema.prisma" // ... model User { id Int @id @default(autoincrement()) } ``` ### Adding Auth to the Project Next, tell Wasp to use full-stack [authentication](../auth/overview): ```wasp title="main.wasp" app TodoApp { wasp: { version: "{latestWaspVersion}" }, title: "TodoApp", head: [ "", ], // highlight-start auth: { // Tells Wasp which entity to use for storing users. userEntity: User, methods: { // Enable username and password auth. usernameAndPassword: {} }, // We'll see how this is used in a bit. onAuthFailedRedirectTo: "/login" } // highlight-end } // ... ``` Don't forget to update the database schema by running: ```sh wasp db migrate-dev ``` By doing this, Wasp will create: - [Auth UI](../auth/ui) with login and signup forms. - A `logout()` action. - A React hook `useAuth()`. - `context.user` for use in Queries and Actions. :::info Wasp also supports authentication using [Google](../auth/social-auth/google), [GitHub](../auth/social-auth/github), and [email](../auth/email), with more on the way! ::: ### Adding Login and Signup Pages Wasp creates the login and signup forms for us, but we still need to define the pages to display those forms on. We'll start by declaring the pages in the Wasp file: ```wasp title="main.wasp" // ... route SignupRoute { path: "/signup", to: SignupPage } page SignupPage { component: import { SignupPage } from "@src/SignupPage" } route LoginRoute { path: "/login", to: LoginPage } page LoginPage { component: import { LoginPage } from "@src/LoginPage" } ``` Great, Wasp now knows these pages exist! Here's the React code for the pages you've just imported: ```tsx title="src/LoginPage.tsx" auto-js export const LoginPage = () => { return (

I don't have an account yet (go to signup).
); }; ```
The signup page is very similar to the login page: ```tsx title="src/SignupPage.tsx" auto-js export const SignupPage = () => { return (

I already have an account (go to login).
); }; ```
:::tip Type-safe links Since you are using Typescript, you can benefit from using Wasp's type-safe `Link` component and the `routes` object. Check out the [type-safe links docs](../advanced/links) for more details. ::: ### Update the Main Page to Require Auth We don't want users who are not logged in to access the main page, because they won't be able to create any tasks. So let's make the page private by requiring the user to be logged in: ```wasp title="main.wasp" // ... page MainPage { // highlight-next-line authRequired: true, component: import { MainPage } from "@src/MainPage" } ``` Now that auth is required for this page, unauthenticated users will be redirected to `/login`, as we specified with `app.auth.onAuthFailedRedirectTo`. Additionally, when `authRequired` is `true`, the page's React component will be provided a `user` object as prop. ```tsx title="src/MainPage.tsx" auto-js // highlight-next-line export const MainPage = ({ user }: { user: AuthUser }) => { // Do something with the user // ... }; ``` Ok, time to test this out. Navigate to the main page (`/`) of the app. You'll get redirected to `/login`, where you'll be asked to authenticate. Since we just added users, you don't have an account yet. Go to the signup page and create one. You'll be sent back to the main page where you will now be able to see the TODO list! Let's check out what the database looks like. Start the Prisma Studio: ```shell wasp db studio ``` Database demonstration - password hashing You'll notice that we now have a `User` entity in the database alongside the `Task` entity. However, you will notice that if you try logging in as different users and creating some tasks, all users share the same tasks. That's because you haven't yet updated the queries and actions to have per-user tasks. Let's do that next. You might notice some extra Prisma models like `Auth`, `AuthIdentity` and `Session` that Wasp created for you. You don't need to care about these right now, but if you are curious, you can read more about them [here](../auth/entities). ### Defining a User-Task Relation First, let's define a one-to-many relation between users and tasks (check the [Prisma docs on relations](https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-schema/relations)): ```prisma title="schema.prisma" // ... model User { id Int @id @default(autoincrement()) // highlight-next-line tasks Task[] } model Task { id Int @id @default(autoincrement()) description String isDone Boolean @default(false) // highlight-next-line user User? @relation(fields: [userId], references: [id]) // highlight-next-line userId Int? } ``` As always, you must migrate the database after changing the Entities: ```sh wasp db migrate-dev ``` :::note We made `user` and `userId` in `Task` optional (via `?`) because that allows us to keep the existing tasks, which don't have a user assigned, in the database. This isn't recommended because it allows an unwanted state in the database (what is the purpose of the task not belonging to anybody?) and normally we would not make these fields optional. Instead, we would do a data migration to take care of those tasks, even if it means just deleting them all. However, for this tutorial, for the sake of simplicity, we will stick with this. ::: ### Updating Operations to Check Authentication Next, let's update the queries and actions to forbid access to non-authenticated users and to operate only on the currently logged-in user's tasks: ```ts title="src/queries.ts" auto-js // highlight-next-line export const getTasks: GetTasks = async (args, context) => { // highlight-start if (!context.user) { throw new HttpError(401); } // highlight-end return context.entities.Task.findMany({ // highlight-next-line where: { user: { id: context.user.id } }, orderBy: { id: "asc" }, }); }; ``` ```ts title="src/actions.ts" auto-js // highlight-next-line type CreateTaskPayload = Pick; export const createTask: CreateTask = async ( args, context, ) => { // highlight-start if (!context.user) { throw new HttpError(401); } // highlight-end return context.entities.Task.create({ data: { description: args.description, // highlight-next-line user: { connect: { id: context.user.id } }, }, }); }; type UpdateTaskPayload = Pick; export const updateTask: UpdateTask< UpdateTaskPayload, { count: number } > = async (args, context) => { // highlight-start if (!context.user) { throw new HttpError(401); } // highlight-end return context.entities.Task.updateMany({ where: { id: args.id, user: { id: context.user.id } }, data: { isDone: args.isDone }, }); }; ``` :::note Due to how Prisma works, we had to convert `update` to `updateMany` in `updateTask` action to be able to specify the user id in `where`. ::: With these changes, each user should have a list of tasks that only they can see and edit. Try playing around, adding a few users and some tasks for each of them. Then open the DB studio: ```sh wasp db studio ``` Database demonstration You will see that each user has their tasks, just as we specified in our code! ### Logout Button Last, but not least, let's add the logout functionality: ```tsx title="src/MainPage.tsx" auto-js with-hole // ... // highlight-next-line //... const MainPage = () => { // ... return (
{$HOLE$} // highlight-next-line
); }; ```
This is it, we have a working authentication system, and our Todo app is multi-user! ### What's Next? We did it 🎉 You've followed along with this tutorial to create a basic Todo app with Wasp. You can find the complete code for the JS version of the tutorial [here](https://github.com/wasp-lang/wasp/tree/release/examples/tutorials/TodoApp). You can find the complete code for the TS version of the tutorial [here](https://github.com/wasp-lang/wasp/tree/release/examples/tutorials/TodoAppTs). You should be ready to learn about more complicated features and go more in-depth with the features already covered. Scroll through the sidebar on the left side of the page to see every feature Wasp has to offer. Or, let your imagination run wild and start building your app! ✨ Looking for inspiration? - Get a jump start on your next project with [Starter Templates](../project/starter-templates). - Check out our [official examples](https://github.com/wasp-lang/wasp/tree/release/examples). - Make a real-time app with [Web Sockets](../advanced/web-sockets). :::note If you notice that some of the features you'd like to have are missing, or have any other kind of feedback, please write to us on [Discord](https://discord.gg/rzdnErX) or create an issue on [Github](https://github.com/wasp-lang/wasp), so we can learn which features to add/improve next 🙏 If you would like to contribute or help to build a feature, let us know! You can find more details on contributing [here](contributing.md). ::: Oh, and do [**subscribe to our newsletter**](/#signup)! We usually send one per month, and Matija does his best to unleash his creativity to make them engaging and fun to read :D! ------ # Data Model ## Entities Entities are the foundation of your app's data model. In short, an Entity defines a model in your database. Wasp uses the excellent [Prisma ORM](https://www.prisma.io/) to implement all database functionality and occasionally enhances it with a thin abstraction layer. This means that you use the `schema.prisma` file to define your database models and relationships. Wasp understands the Prisma schema file and picks up all the models you define there. You can read more about this in the [Prisma Schema File](./prisma-file.md) section of the docs. In your project, you'll find a `schema.prisma` file in the root directory: ``` . ├── main.wasp ... ├── schema.prisma ├── src ├── tsconfig.json └── vite.config.ts ``` Prisma uses the _Prisma Schema Language_, a simple definition language explicitly created for defining models. The language is declarative and very intuitive. We'll also go through an example later in the text, so there's no need to go and thoroughly learn it right away. Still, if you're curious, look no further than Prisma's official documentation: - [Basic intro and examples](https://www.prisma.io/docs/orm/prisma-schema/overview) - [A more exhaustive language specification](https://www.prisma.io/docs/orm/reference/prisma-schema-reference) ### Defining an Entity A Prisma `model` declaration in the `schema.prisma` file represents a Wasp Entity.
Entity vs Model You might wonder why we distinguish between a **Wasp Entity** and a **Prisma model** if they're essentially the same thing right now. While defining a Prisma model is currently the only way to create an Entity in Wasp, the Entity concept is a higher-level abstraction. We plan to expand on Entities in the future, both in terms of how you can define them and what you can do with them. So, think of an Entity as a Wasp concept and a model as a Prisma concept. For now, all Prisma models are Entities and vice versa, but this relationship might evolve as Wasp grows.
Here's how you could define an Entity that represents a Task: ```prisma title="schema.prisma" model Task { id String @id @default(uuid()) description String isDone Boolean @default(false) } ``` ```prisma title="schema.prisma" model Task { id String @id @default(uuid()) description String isDone Boolean @default(false) } ``` The above Prisma `model` definition tells Wasp to create a table for storing Tasks where each task has three fields (i.e., the `tasks` table has three columns): - `id` - A string value serving as a primary key. The database automatically generates it by generating a random unique ID. - `description` - A string value for storing the task's description. - `isDone` - A boolean value indicating the task's completion status. If you don't set it when creating a new task, the database sets it to `false` by default. Wasp also exposes a type for working with the created Entity. You can import and use it like this: ```ts import { Task } from 'wasp/entities' const task: Task = { ... } // You can also define functions for working with entities function getInfoMessage(task: Task): string { const isDoneText = task.isDone ? "is done" : "is not done" return `Task '${task.description}' is ${isDoneText}.` } ``` Using the `Task` type in `getInfoMessageInfo`'s definition connects the argument's type with the `Task` entity. This coupling removes duplication and ensures the function keeps the correct signature even if you change the entity. Of course, the function might throw type errors depending on how you change it, but that's precisely what you want! Entity types are available everywhere, including the client code: ```ts import { Task } from "wasp/entities" export function ExamplePage() { const task: Task = { id: 123, description: "Some random task", isDone: false, } return
{task.description}
} ``` The mentioned type safety mechanisms also apply here: changing the task entity in our `schema.prisma` file changes the imported type, which might throw a type error and warn us that our task definition is outdated. You'll learn even more about Entity types when you start using [them with operations](#using-entities-in-operations).
#### Working with Entities Let's see how you can define and work with Wasp Entities: 1. Create/update some Entities in the `schema.prisma` file. 2. Run `wasp db migrate-dev`. This command syncs the database model with the Entity definitions the `schema.prisma` file. It does this by creating migration scripts. 3. Migration scripts are automatically placed in the `migrations/` folder. Make sure to commit this folder into version control. 4. Use Wasp's JavasScript API to work with the database when implementing Operations (we'll cover this in detail when we talk about [operations](../data-model/operations/overview)). ##### Using Entities in Operations Most of the time, you will be working with Entities within the context of [Operations (Queries & Actions)](../data-model/operations/overview). We'll see how that's done on the next page. ##### Using Entities directly If you need more control, you can directly interact with Entities by importing and using the [Prisma Client](https://www.prisma.io/docs/concepts/components/prisma-client/crud). We recommend sticking with conventional Wasp-provided mechanisms, only resorting to directly using the Prisma client only if you need a feature Wasp doesn't provide. You can only use the Prisma Client in your Wasp server code. You can import it like this: ```js import { prisma } from 'wasp/server' prisma.task.create({ description: "Read the Entities doc", isDone: true // almost :) }) ``` ```ts import { prisma } from 'wasp/server' prisma.task.create({ description: "Read the Entities doc", isDone: true // almost :) }) ``` :::note Available Prisma features in the client While the Prisma Client is not available in your client code, you can still import Prisma there, for accessing type definitions (notably, `enum`s). You can see more information in the overview of [supported Prisma Schema features](./prisma-file.md#the-enum-blocks). ::: #### Next steps Now that we've seen how to define Entities that represent Wasp's core data model, we'll see how to make the most of them in other parts of Wasp. Keep reading to learn all about Wasp Operations! ## Operations Overview While Entities enable you to define your app's data model and relationships, Operations are all about working with this data. There are two kinds of Operations: [Queries](../../data-model/operations/queries.md) and [Actions](../../data-model/operations/actions.md). As their names suggest, Queries are meant for reading data, and Actions are meant for changing it (either by updating existing entries or creating new ones). Keep reading to find out all there is to know about Operations in Wasp. ## Queries We'll explain what Queries are and how to use them. If you're looking for a detailed API specification, skip ahead to the [API Reference](#api-reference). You can use Queries to fetch data from the server. They shouldn't modify the server's state. Fetching all comments on a blog post, a list of users that liked a video, information about a single product based on its ID... All of these are perfect use cases for a Query. :::tip Queries are fairly similar to Actions in terms of their API. Therefore, if you're already familiar with Actions, you might find reading the entire guide repetitive. We instead recommend skipping ahead and only reading [the differences between Queries and Actions](../../data-model/operations/actions#differences-between-queries-and-actions), and consulting the [API Reference](#api-reference) as needed. ::: ### Working with Queries You declare queries in the `.wasp` file and implement them using NodeJS. Wasp not only runs these queries within the server's context but also creates code that enables you to call them from any part of your codebase, whether it's on the client or server side. This means you don't have to build an HTTP API for your query, manage server-side request handling, or even deal with client-side response handling and caching. Instead, just concentrate on implementing the business logic inside your query, and let Wasp handle the rest! To create a Query, you must: 1. Declare the Query in Wasp using the `query` declaration. 2. Define the Query's NodeJS implementation. After completing these two steps, you'll be able to use the Query from any point in your code. #### Declaring Queries To create a Query in Wasp, we begin with a `query` declaration. Let's declare two Queries - one to fetch all tasks, and another to fetch tasks based on a filter, such as whether a task is done: ```wasp title="main.wasp" // ... query getAllTasks { fn: import { getAllTasks } from "@src/queries" } query getFilteredTasks { fn: import { getFilteredTasks } from "@src/queries" } ``` ```wasp title="main.wasp" // ... query getAllTasks { fn: import { getAllTasks } from "@src/queries" } query getFilteredTasks { fn: import { getFilteredTasks } from "@src/queries" } ``` If you want to know about all supported options for the `query` declaration, take a look at the [API Reference](#api-reference). The names of Wasp Queries and their implementations don't need to match, but we'll keep them the same to avoid confusion. :::info You might have noticed that we told Wasp to import Query implementations that don't yet exist. Don't worry about that for now. We'll write the implementations imported from `queries.{js,ts}` in the next section. It's a good idea to start with the high-level concept (the Query declaration in the Wasp file) and only then deal with the implementation details (the Query's implementation in JavaScript). ::: After declaring a Wasp Query, two important things happen: - Wasp **generates a server-side NodeJS function** that shares its name with the Query. - Wasp **generates a client-side JavaScript function** that shares its name with the Query (e.g., `getFilteredTasks`). This function takes a single optional argument - an object containing any serializable data you wish to use inside the Query. Wasp will send this object over the network and pass it into the Query's implementation as its first positional argument (more on this when we look at the implementations). Such an abstraction works thanks to an HTTP API route handler Wasp generates on the server, which calls the Query's NodeJS implementation under the hood. Generating these two functions ensures a similar calling interface across the entire app (both client and server). #### Implementing Queries in Node Now that we've declared the Query, what remains is to implement it. We've instructed Wasp to look for the Queries' implementations in the file `src/queries.{js,ts}`, so that's where we should export them from. Here's how you might implement the previously declared Queries `getAllTasks` and `getFilteredTasks`: ```js title="src/queries.js" // our "database" const tasks = [ { id: 1, description: 'Buy some eggs', isDone: true }, { id: 2, description: 'Make an omelette', isDone: false }, { id: 3, description: 'Eat breakfast', isDone: false }, ] // You don't need to use the arguments if you don't need them export const getAllTasks = () => { return tasks } // The 'args' object is something sent by the caller (most often from the client) export const getFilteredTasks = (args) => { const { isDone } = args return tasks.filter((task) => task.isDone === isDone) } ``` ```ts title="src/queries.ts" import { type GetAllTasks, type GetFilteredTasks } from 'wasp/server/operations' type Task = { id: number description: string isDone: boolean } // our "database" const tasks: Task[] = [ { id: 1, description: 'Buy some eggs', isDone: true }, { id: 2, description: 'Make an omelette', isDone: false }, { id: 3, description: 'Eat breakfast', isDone: false }, ] // You don't need to use the arguments if you don't need them export const getAllTasks: GetAllTasks = () => { return tasks } // The 'args' object is something sent by the caller (most often from the client) export const getFilteredTasks: GetFilteredTasks< Pick, Task[] > = (args) => { const { isDone } = args return tasks.filter((task) => task.isDone === isDone) } ``` #### Type support for Queries Wasp automatically generates the types `GetAllTasks` and `GetFilteredTasks` based on your Wasp file's declarations: - `GetAllTasks` is a generic type automatically generated by Wasp, based on the Query declaration for `getAllTasks`. - `GetFilteredTasks` is also a generic type automatically generated by Wasp, based on the Query declaration for `getFilteredTasks`. Use these types to type the Query's implementation. It's optional but very helpful since doing so properly types the Query's context. In this case, TypeScript will know the `context.entities` object must include the `Task` entity. TypeScript also knows whether the `context` object includes user information (it depends on whether your Query uses auth). The generated types are generic and accept two optional type arguments: `Input` and `Output`. 1. `Input` - The argument (the payload) received by the Query function. 2. `Output` - The Query function's return type. Use these type arguments to type the Query's inputs and outputs.
Explanation for the example above The above code says that the Query `getAllTasks` doesn't expect any arguments (its input type is `void`), but it does return a list of tasks (its output type is `Task[]`). On the other hand, the Query `getFilteredTasks` expects an object of type `{ isDone: boolean }`. This type is derived from the `Task` entity type. If you don't care about typing the Query's inputs and outputs, you can omit both type arguments. TypeScript will then infer the most general types (`never` for the input and `unknown` for the output). Specifying `Input` or `Output` is completely optional, but we highly recommended it. Doing so gives you: - Type support for the arguments and the return value inside the implementation. - **Full-stack type safety**. We'll explore what this means when we discuss calling the Query from the client.
Read more about type support for implementing Queries in the [API Reference](#implementing-queries). :::tip Inferring the return type If don't want to explicitly type the Query's return value, the `satisfies` keyword tells TypeScript to infer it automatically: ```typescript const getFoo = (async (_args, context) => { const foos = await context.entities.Foo.findMany() return { foos, message: 'Here are some foos!', queriedAt: new Date(), } }) satisfies GetFoo ``` From the snippet above, TypeScript knows: 1. The correct type for `context`. 2. The Query's return type is `{ foos: Foo[], message: string, queriedAt: Date }`. If you don't need the context, you can skip specifying the Query's type (and arguments): ```typescript const getFoo = () => {{ name: 'Foo', date: new Date() }} ``` :::
For a detailed explanation of the Query definition API (more precisely, its arguments and return values), check the [API Reference](#api-reference). #### Using Queries ##### Using Queries on the client To call a Query on the client, you can import it from `wasp/client/operations` and call it directly. The usage doesn't change depending on whether the Query is authenticated or not. Wasp authenticates the logged-in user in the background. ```js import { getAllTasks, getFilteredTasks } from 'wasp/client/operations' // ... const allTasks = await getAllTasks() const doneTasks = await getFilteredTasks({ isDone: true }) ``` ```ts import { getAllTasks, getFilteredTasks } from 'wasp/client/operations' // TypeScript automatically infers the return values and type-checks // the payloads. const allTasks = await getAllTasks() const doneTasks = await getFilteredTasks({ isDone: true }) ``` Wasp supports **automatic full-stack type safety**. You only need to specify the Query's type in its server-side definition, and the client code will automatically know its API payload types. ##### Using Queries on the server Calling a Query on the server is similar to calling it on the client. Here's what you have to do differently: - Import Queries from `wasp/server/operations` instead of `wasp/client/operations`. - Make sure you pass in a `context` object with the `user` field to authenticated Queries. - Note that you don't have to pass other parts of the `context` object, like Entities, those will get injected automatically. ```js import { getAllTasks, getFilteredTasks } from 'wasp/server/operations' const user = // Get an AuthUser object, e.g., from context.user in an operation. // ... const allTasks = await getAllTasks({ user }) const doneTasks = await getFilteredTasks({ isDone: true }, { user }) ``` ```ts import { getAllTasks, getFilteredTasks } from 'wasp/server/operations' const user = // Get an AuthUser object, e.g., from context.user in an operation. // TypeScript automatically infers the return values and type-checks // the payloads. const allTasks = await getAllTasks({ user }) const doneTasks = await getFilteredTasks({ isDone: true }, { user }) ``` ##### The `useQuery` hook When using Queries on the client, you can make them reactive with the `useQuery` hook. This hook comes bundled with Wasp and is a thin wrapper around the `useQuery` hook from [_react-query_](https://github.com/tannerlinsley/react-query). The only difference is that you don't need to supply the key - Wasp handles this for you automatically. Here's an example of calling the Queries using the `useQuery` hook: ```jsx title="src/MainPage.jsx" import React from 'react' import { useQuery, getAllTasks, getFilteredTasks } from 'wasp/client/operations' const MainPage = () => { const { data: allTasks, error: error1 } = useQuery(getAllTasks) const { data: doneTasks, error: error2 } = useQuery(getFilteredTasks, { isDone: true, }) if (error1 !== null || error2 !== null) { return
There was an error
} return (

All Tasks

{allTasks && allTasks.length > 0 ? allTasks.map((task) => ) : 'No tasks'}

Finished Tasks

{doneTasks && doneTasks.length > 0 ? doneTasks.map((task) => ) : 'No finished tasks'}
) } const Task = ({ description, isDone }: Task) => { return (

Description: {description}

Is done: {isDone ? 'Yes' : 'No'}

) } export default MainPage ```
```tsx title="src/MainPage.tsx" import React from 'react' import { type Task } from 'wasp/entities' import { useQuery, getAllTasks, getFilteredTasks } from 'wasp/client/operations' const MainPage = () => { // TypeScript automatically infers return values and type-checks payload types. const { data: allTasks, error: error1 } = useQuery(getAllTasks) const { data: doneTasks, error: error2 } = useQuery(getFilteredTasks, { isDone: true, }) if (error1 !== null || error2 !== null) { return
There was an error
} return (

All Tasks

{allTasks && allTasks.length > 0 ? allTasks.map((task) => ) : 'No tasks'}

Finished Tasks

{doneTasks && doneTasks.length > 0 ? doneTasks.map((task) => ) : 'No finished tasks'}
) } const Task = ({ description, isDone }: Task) => { return (

Description: {description}

Is done: {isDone ? 'Yes' : 'No'}

) } export default MainPage ``` Notice how you don't need to annotate the Query's return value type. Wasp automatically infers the from the Query's backend implementation. This is **full-stack type safety**: the types on the client always match the types on the server.
For a detailed specification of the `useQuery` hook, check the [API Reference](#api-reference). #### Error Handling For security reasons, all exceptions thrown in the Query's NodeJS implementation are sent to the client as responses with the HTTP status code `500`, with all other details removed. Hiding error details by default helps against accidentally leaking possibly sensitive information over the network. If you do want to pass additional error information to the client, you can construct and throw an appropriate `HttpError` in your implementation: ```js title="src/queries.js" import { HttpError } from 'wasp/server' export const getAllTasks = async (args, context) => { throw new HttpError( 403, // status code "You can't do this!", // message { foo: 'bar' } // data ) } ``` ```ts title="src/queries.ts" import { type GetAllTasks } from 'wasp/server/operations' import { HttpError } from 'wasp/server' export const getAllTasks: GetAllTasks = async (args, context) => { throw new HttpError( 403, // status code "You can't do this!", // message { foo: 'bar' } // data ) } ``` If the status code is `4xx`, the client will receive a response object with the corresponding `message` and `data` fields, and it will rethrow the error (including these fields). To prevent information leakage, the server won't forward these fields for any other HTTP status codes. #### Using Entities in Queries In most cases, resources used in Queries will be [Entities](../../data-model/entities.md). To use an Entity in your Query, add it to the `query` declaration in Wasp: ```wasp {4,9} title="main.wasp" query getAllTasks { fn: import { getAllTasks } from "@src/queries", entities: [Task] } query getFilteredTasks { fn: import { getFilteredTasks } from "@src/queries", entities: [Task] } ``` ```wasp {4,9} title="main.wasp" query getAllTasks { fn: import { getAllTasks } from "@src/queries", entities: [Task] } query getFilteredTasks { fn: import { getFilteredTasks } from "@src/queries", entities: [Task] } ``` Wasp will inject the specified Entity into the Query's `context` argument, giving you access to the Entity's Prisma API: ```js title="src/queries.js" export const getAllTasks = async (args, context) => { return context.entities.Task.findMany({}) } export const getFilteredTasks = async (args, context) => { return context.entities.Task.findMany({ where: { isDone: args.isDone }, }) } ``` ```ts title="src/queries.ts" import { type Task } from 'wasp/entities' import { type GetAllTasks, type GetFilteredTasks } from 'wasp/server/operations' export const getAllTasks: GetAllTasks = async (args, context) => { return context.entities.Task.findMany({}) } export const getFilteredTasks: GetFilteredTasks< Pick, Task[] > = async (args, context) => { return context.entities.Task.findMany({ where: { isDone: args.isDone }, }) } ``` Again, annotating the Queries is optional, but greatly improves **full-stack type safety**. The object `context.entities.Task` exposes `prisma.task` from [Prisma's CRUD API](https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/crud). ### API Reference #### Declaring Queries The `query` declaration supports the following fields: - `fn: ExtImport` Required! The import statement of the Query's NodeJs implementation. - `entities: [Entity]` A list of entities you wish to use inside your Query. For instructions on using Entities in Queries, take a look at [the guide](#using-entities-in-queries). ##### Example Declaring the Query: ```wasp query getFoo { fn: import { getFoo } from "@src/queries" entities: [Foo] } ``` Enables you to import and use it anywhere in your code (on the server or the client): ```js // Use it on the client import { getFoo } from 'wasp/client/operations' // Use it on the server import { getFoo } from 'wasp/server/operations' ``` On the client, the Query expects Declaring the Query: ```wasp query getFoo { fn: import { getFoo } from "@src/queries" entities: [Foo] } ``` Enables you to import and use it anywhere in your code (on the server or the client): ```ts // Use it on the client import { getFoo } from 'wasp/client/operations' // Use it on the server import { getFoo } from 'wasp/server/operations' ``` And also creates a type you can import on the server: ```ts import { type GetFoo } from 'wasp/server/operations' ``` #### Implementing Queries The Query's implementation is a NodeJS function that takes two arguments (it can be an `async` function if you need to use the `await` keyword). Since both arguments are positional, you can name the parameters however you want, but we'll stick with `args` and `context`: 1. `args` (type depends on the Query) An object containing the data **passed in when calling the query** (e.g., filtering conditions). Check [the usage examples](#using-queries) to see how to pass this object to the Query. 2. `context` (type depends on the Query) An additional context object **passed into the Query by Wasp**. This object contains user session information, as well as information about entities. Check the [section about using entities in Queries](#using-entities-in-queries) to see how to use the entities field on the `context` object, or the [auth section](../../auth/overview#using-the-contextuser-object) to see how to use the `user` object. After you [declare the query](#declaring-queries), Wasp generates a generic type you can use when defining its implementation. For the Query declared as `getSomething`, the generated type is called `GetSomething`: ```ts import { type GetSomething } from 'wasp/server/operations' ``` It expects two (optional) type arguments: 1. `Input` The type of the `args` object (the Query's input payload). The default value is `never`. 2. `Output` The type of the Query's return value (the Query's output payload). The default value is `unknown`. The defaults were chosen to make the type signature as permissive as possible. If don't want your Query to take/return anything, use `void` as a type argument. ##### Example The following Query: ```wasp query getFoo { fn: import { getFoo } from "@src/queries" entities: [Foo] } ``` Expects to find a named export `getFoo` from the file `src/queries.js` ```js title="queries.js" export const getFoo = (args, context) => { // implementation } ``` The following Query: ```wasp query getFoo { fn: import { getFoo } from "@src/queries" entities: [Foo] } ``` Expects to find a named export `getFoo` from the file `src/queries.js` You can use the generated type `GetFoo` and specify the Query's inputs and outputs using its type arguments. ```ts title="queries.ts" import { type GetFoo } from 'wasp/server/operations' type Foo = // ... export const getFoo: GetFoo<{ id: number }, Foo> = (args, context) => { // implementation }; ``` In this case, the Query expects to receive an object with an `id` field of type `number` (this is the type of `args`), and return a value of type `Foo` (this must match the type of the Query's return value). #### The `useQuery` Hook Wasp's `useQuery` hook is a thin wrapper around the `useQuery` hook from [_react-query_](https://github.com/tannerlinsley/react-query). One key difference is that Wasp doesn't expect you to supply the cache key - it takes care of it under the hood. Wasp's `useQuery` hook accepts three arguments: - `queryFn` Required! The client-side query function generated by Wasp based on a `query` declaration in your `.wasp` file. - `queryFnArgs` The arguments object (payload) you wish to pass into the Query. The Query's NodeJS implementation will receive this object as its first positional argument. - `options` A _react-query_ `options` object. Use this to change [the default behavior](https://react-query.tanstack.com/guides/important-defaults) for this particular Query. If you want to change the global defaults, you can do so in the [client setup function](../../project/client-config.md#overriding-default-behaviour-for-queries). For an example of usage, check [this section](#the-usequery-hook). ## Actions We'll explain what Actions are and how to use them. If you're looking for a detailed API specification, skip ahead to the [API Reference](#api-reference). Actions are quite similar to [Queries](../../data-model/operations/queries.md), but with a key distinction: Actions are designed to modify and add data, while Queries are solely for reading data. Examples of Actions include adding a comment to a blog post, liking a video, or updating a product's price. Actions and Queries work together to keep data caches up-to-date. :::tip Actions are almost identical to Queries in terms of their API. Therefore, if you're already familiar with Queries, you might find reading the entire guide repetitive. We instead recommend skipping ahead and only reading [the differences between Queries and Actions](#differences-between-queries-and-actions), and consulting the [API Reference](#api-reference) as needed. ::: ### Working with Actions Actions are declared in Wasp and implemented in NodeJS. Wasp runs Actions within the server's context, but it also generates code that allows you to call them from anywhere in your code (either client or server) using the same interface. This means you don't have to worry about building an HTTP API for the Action, managing server-side request handling, or even dealing with client-side response handling and caching. Instead, just focus on developing the business logic inside your Action, and let Wasp handle the rest! To create an Action, you need to: 1. Declare the Action in Wasp using the `action` declaration. 2. Implement the Action's NodeJS functionality. Once these two steps are completed, you can use the Action from anywhere in your code. #### Declaring Actions To create an Action in Wasp, we begin with an `action` declaration. Let's declare two Actions - one for creating a task, and another for marking tasks as done: ```wasp title="main.wasp" // ... action createTask { fn: import { createTask } from "@src/actions" } action markTaskAsDone { fn: import { markTaskAsDone } from "@src/actions" } ``` ```wasp title="main.wasp" // ... action createTask { fn: import { createTask } from "@src/actions" } action markTaskAsDone { fn: import { markTaskAsDone } from "@src/actions" } ``` If you want to know about all supported options for the `action` declaration, take a look at the [API Reference](#api-reference). The names of Wasp Actions and their implementations don't necessarily have to match. However, to avoid confusion, we'll keep them the same. :::info You might have noticed that we told Wasp to import Action implementations that don't yet exist. Don't worry about that for now. We'll write the implementations imported from `actions.{js,ts}` in the next section. It's a good idea to start with the high-level concept (the Action declaration in the Wasp file) and only then deal with the implementation details (the Action's implementation in JavaScript). ::: After declaring a Wasp Action, two important things happen: - Wasp **generates a server-side NodeJS function** that shares its name with the Action. - Wasp **generates a client-side JavaScript function** that shares its name with the Action (e.g., `markTaskAsDone`). This function takes a single optional argument - an object containing any serializable data you wish to use inside the Action. Wasp will send this object over the network and pass it into the Action's implementation as its first positional argument (more on this when we look at the implementations). Such an abstraction works thanks to an HTTP API route handler Wasp generates on the server, which calls the Action's NodeJS implementation under the hood. Generating these two functions ensures a similar calling interface across the entire app (both client and server). #### Implementing Actions in Node Now that we've declared the Action, what remains is to implement it. We've instructed Wasp to look for the Actions' implementations in the file `src/actions.{js,ts}`, so that's where we should export them from. Here's how you might implement the previously declared Actions `createTask` and `markTaskAsDone`: ```js title="src/actions.js" // our "database" let nextId = 4 const tasks = [ { id: 1, description: 'Buy some eggs', isDone: true }, { id: 2, description: 'Make an omelette', isDone: false }, { id: 3, description: 'Eat breakfast', isDone: false }, ] // You don't need to use the arguments if you don't need them export const createTask = (args) => { const newTask = { id: nextId, isDone: false, description: args.description, } nextId += 1 tasks.push(newTask) return newTask } // The 'args' object is something sent by the caller (most often from the client) export const markTaskAsDone = (args) => { const task = tasks.find((task) => task.id === args.id) if (!task) { // We'll show how to properly handle such errors later return } task.isDone = true } ``` ```ts title="src/actions.ts" import { type CreateTask, type MarkTaskAsDone } from 'wasp/server/operations' type Task = { id: number description: string isDone: boolean } // our "database" let nextId = 4 const tasks = [ { id: 1, description: 'Buy some eggs', isDone: true }, { id: 2, description: 'Make an omelette', isDone: false }, { id: 3, description: 'Eat breakfast', isDone: false }, ] // You don't need to use the arguments if you don't need them export const createTask: CreateTask, Task> = ( args ) => { const newTask = { id: nextId, isDone: false, description: args.description, } nextId += 1 tasks.push(newTask) return newTask } // The 'args' object is something sent by the caller (most often from the client) export const markTaskAsDone: MarkTaskAsDone, void> = ( args ) => { const task = tasks.find((task) => task.id === args.id) if (!task) { // We'll show how to properly handle such errors later return } task.isDone = true } ``` #### Type support for Actions Wasp automatically generates the types `CreateTask` and `MarkTaskAsDone` based on the declarations in your Wasp file: - `CreateTask` is a generic type that Wasp automatically generated based on the Action declaration for `createTask`. - `MarkTaskAsDone` is a generic type that Wasp automatically generated based on the Action declaration for `markTaskAsDone`. Use these types to type the Action's implementation. It's optional but very helpful since doing so properly types the Action's context. In this case, TypeScript will know the `context.entities` object must include the `Task` entity. TypeScript also knows whether the `context` object includes user information (it depends on whether your Action uses auth). The generated types are generic and accept two optional type arguments: `Input` and `Output`. 1. `Input` - The argument (the payload) received by the Action function. 2. `Output` - The Action function's return type. Use these type arguments to type the Action's inputs and outputs.
Explanation for the example above The above code says that the Action `createTask` expects an object with the new task's description (its input type is `Pick`) and returns the new task (its output type is `Task`). On the other hand, the Action `markTaskAsDone` expects an object of type `Pick`. This type is derived from the `Task` entity type. If you don't care about typing the Action's inputs and outputs, you can omit both type arguments. TypeScript will then infer the most general types (`never` for the input and `unknown` for the output). Specifying `Input` or `Output` is completely optional, but we highly recommended it. Doing so gives you: - Type support for the arguments and the return value inside the implementation. - **Full-stack type safety**. We'll explore what this means when we discuss calling the Action from the client.
Read more about type support for implementing Actions in the [API Reference](#implementing-actions). :::tip Inferring the return type If don't want to explicitly type the Action's return value, the `satisfies` keyword tells TypeScript to infer it automatically: ```typescript const createFoo = (async (_args, context) => { const foo = await context.entities.Foo.create() return { newFoo: foo, message: "Here's your foo!", returnedAt: new Date(), } }) satisfies GetFoo ``` From the snippet above, TypeScript knows: 1. The correct type for `context`. 2. The Action's return type is `{ newFoo: Foo, message: string, returnedAt: Date }`. If you don't need the context, you can skip specifying the Action's type (and arguments): ```typescript const createFoo = () => {{ name: 'Foo', date: new Date() }} ``` :::
For a detailed explanation of the Action definition API (more precisely, its arguments and return values), check the [API Reference](#api-reference). #### Using Actions ##### Using Actions on the client To call an Action on the client, you can import it from `wasp/client/operations` and call it directly. The usage doesn't depend on whether the Action is authenticated or not. Wasp authenticates the logged-in user in the background. ```js import { createTask, markTaskAsDone } from 'wasp/client/operations' // ... const newTask = await createTask({ description: 'Learn TypeScript' }) await markTaskAsDone({ id: 1 }) ``` ```ts import { createTask, markTaskAsDone } from 'wasp/client/operations' // TypeScript automatically infers the return values and type-checks // the payloads. const newTask = await createTask({ description: 'Keep learning TypeScript' }) await markTaskAsDone({ id: 1 }) ``` Wasp supports **automatic full-stack type safety**. You only need to specify the Action's type in its server-side definition, and the client code will automatically know its API payload types. When using Actions on the client, you'll most likely want to use them inside a component: ```jsx title="src/pages/Task.jsx" import React from 'react' // highlight-next-line import { useQuery, getTask, markTaskAsDone } from 'wasp/client/operations' export const TaskPage = ({ id }) => { const { data: task } = useQuery(getTask, { id }) if (!task) { return

"Loading"

} const { description, isDone } = task return (

Description: {description}

Is done: {isDone ? 'Yes' : 'No'}

{isDone || ( // highlight-next-line )}
) } ```
```tsx title="src/pages/Task.tsx" import React from 'react' // highlight-next-line import { useQuery, getTask, markTaskAsDone } from 'wasp/client/operations' export const TaskPage = ({ id }: { id: number }) => { const { data: task } = useQuery(getTask, { id }) if (!task) { return

"Loading"

} const { description, isDone } = task return (

Description: {description}

Is done: {isDone ? 'Yes' : 'No'}

{isDone || ( // highlight-next-line )}
) } ```
Since Actions don't require reactivity, they are safe to use inside components without a hook. Still, Wasp provides comes with the `useAction` hook you can use to enhance actions. Read all about it in the [API Reference](#api-reference). ##### Using Actions on the server Calling an Action on the server is similar to calling it on the client. Here's what you have to do differently: - Import Actions from `wasp/server/operations` instead of `wasp/client/operations`. - Make sure you pass in a context object with the user to authenticated Actions. ```js import { createTask, markTaskAsDone } from 'wasp/server/operations' const user = // Get an AuthUser object, e.g., from context.user const newTask = await createTask( { description: 'Learn TypeScript' }, { user }, ) await markTaskAsDone({ id: 1 }, { user }) ``` ```ts import { createTask, markTaskAsDone } from 'wasp/server/operations' const user = // Get an AuthUser object, e.g., from context.user // TypeScript automatically infers the return values and type-checks // the payloads. const newTask = await createTask( { description: 'Keep learning TypeScript' }, { user }, ) await markTaskAsDone({ id: 1 }, { user }) ``` #### Error Handling For security reasons, all exceptions thrown in the Action's NodeJS implementation are sent to the client as responses with the HTTP status code `500`, with all other details removed. Hiding error details by default helps against accidentally leaking possibly sensitive information over the network. If you do want to pass additional error information to the client, you can construct and throw an appropriate `HttpError` in your implementation: ```js title="src/actions.js" import { HttpError } from 'wasp/server' export const createTask = async (args, context) => { throw new HttpError( 403, // status code "You can't do this!", // message { foo: 'bar' } // data ) } ``` ```ts title="src/actions.ts" import { type CreateTask } from 'wasp/server/operations' import { HttpError } from 'wasp/server' export const createTask: CreateTask = async (args, context) => { throw new HttpError( 403, // status code "You can't do this!", // message { foo: 'bar' } // data ) } ``` #### Using Entities in Actions In most cases, resources used in Actions will be [Entities](../../data-model/entities.md). To use an Entity in your Action, add it to the `action` declaration in Wasp: ```wasp {4,9} title="main.wasp" action createTask { fn: import { createTask } from "@src/actions", entities: [Task] } action markTaskAsDone { fn: import { markTaskAsDone } from "@src/actions", entities: [Task] } ``` ```wasp {4,9} title="main.wasp" action createTask { fn: import { createTask } from "@src/actions", entities: [Task] } action markTaskAsDone { fn: import { markTaskAsDone } from "@src/actions", entities: [Task] } ``` Wasp will inject the specified Entity into the Action's `context` argument, giving you access to the Entity's Prisma API. Wasp invalidates frontend Query caches by looking at the Entities used by each Action/Query. Read more about Wasp's smart cache invalidation [here](#cache-invalidation). ```js title="src/actions.js" // The 'args' object is the payload sent by the caller (most often from the client) export const createTask = async (args, context) => { const newTask = await context.entities.Task.create({ data: { description: args.description, isDone: false, }, }) return newTask } export const markTaskAsDone = async (args, context) => { await context.entities.Task.update({ where: { id: args.id }, data: { isDone: true }, }) } ``` ```ts title="src/actions.ts" import { type CreateTask, type MarkTaskAsDone } from 'wasp/server/operations' import { type Task } from 'wasp/entities' // The 'args' object is the payload sent by the caller (most often from the client) export const createTask: CreateTask, Task> = async ( args, context ) => { const newTask = await context.entities.Task.create({ data: { description: args.description, isDone: false, }, }) return newTask } export const markTaskAsDone: MarkTaskAsDone, void> = async ( args, context ) => { await context.entities.Task.update({ where: { id: args.id }, data: { isDone: true }, }) } ``` Again, annotating the Actions is optional, but greatly improves **full-stack type safety**. The object `context.entities.Task` exposes `prisma.task` from [Prisma's CRUD API](https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/crud). ### Cache Invalidation One of the trickiest parts of managing a web app's state is making sure the data returned by the Queries is up to date. Since Wasp uses _react-query_ for Query management, we must make sure to invalidate Queries (more specifically, their cached results managed by _react-query_) whenever they become stale. It's possible to invalidate the caches manually through several mechanisms _react-query_ provides (e.g., refetch, direct invalidation). However, since manual cache invalidation quickly becomes complex and error-prone, Wasp offers a faster and a more effective solution to get you started: **automatic Entity-based Query cache invalidation**. Because Actions can (and most often do) modify the state while Queries read it, Wasp invalidates a Query's cache whenever an Action that uses the same Entity is executed. For example, if the Action `createTask` and Query `getTasks` both use the Entity `Task`, executing `createTask` may cause the cached result of `getTasks` to become outdated. In response, Wasp will invalidate it, causing `getTasks` to refetch data from the server and update it. In practice, this means that Wasp keeps the Queries "fresh" without requiring you to think about cache invalidation. On the other hand, this kind of automatic cache invalidation can become wasteful (some updates might not be necessary) and will only work for Entities. If that's an issue, you can use the mechanisms provided by _react-query_ for now, and expect more direct support in Wasp for handling those use cases in a nice, elegant way. If you wish to optimistically set cache values after performing an Action, you can do so using [optimistic updates](https://stackoverflow.com/a/33009713). Configure them using Wasp's [useAction hook](#the-useaction-hook-and-optimistic-updates). This is currently the only manual cache invalidation mechanism Wasps supports natively. For everything else, you can always rely on _react-query_. ### Differences Between Queries and Actions Actions and Queries are two closely related concepts in Wasp. They might seem to perform similar tasks, but Wasp treats them differently, and each concept represents a different thing. Here are the key differences between Queries and Actions: 1. Actions can (and often should) modify the server's state, while Queries are only permitted to read it. Wasp relies on you adhering to this convention when performing cache invalidations, so it's crucial to follow it. 2. Actions don't need to be reactive, so you can call them directly. However, Wasp does provide a [`useAction` React hook](#the-useaction-hook-and-optimistic-updates) for adding extra behavior to the Action (like optimistic updates). 3. `action` declarations in Wasp are mostly identical to `query` declarations. The only difference lies in the declaration's name. ### API Reference #### Declaring Actions in Wasp The `action` declaration supports the following fields: - `fn: ExtImport` Required! The import statement of the Action's NodeJs implementation. - `entities: [Entity]` A list of entities you wish to use inside your Action. For instructions on using Entities in Actions, take a look at [the guide](#using-entities-in-actions). ##### Example Declaring the Action: ```wasp query createFoo { fn: import { createFoo } from "@src/actions" entities: [Foo] } ``` Enables you to import and use it anywhere in your code (on the server or the client): ```js // Use it on the client import { createFoo } from 'wasp/client/operations' // Use it on the server import { createFoo } from 'wasp/server/operations' ``` Declaring the Action: ```wasp query createFoo { fn: import { createFoo } from "@src/actions" entities: [Foo] } ``` Enables you to import and use it anywhere in your code (on the server or the client): ```ts // Use it on the client import { createFoo } from 'wasp/client/operations' // Use it on the server import { createFoo } from 'wasp/server/operations' ``` As well as the following type import on the server: ```ts import { type CreateFoo } from 'wasp/server/operations' ``` #### Implementing Actions The Action's implementation is a NodeJS function that takes two arguments (it can be an `async` function if you need to use the `await` keyword). Since both arguments are positional, you can name the parameters however you want, but we'll stick with `args` and `context`: 1. `args` (type depends on the Action) An object containing the data **passed in when calling the Action** (e.g., filtering conditions). Check [the usage examples](#using-actions) to see how to pass this object to the Action. 2. `context` (type depends on the Action) An additional context object **passed into the Action by Wasp**. This object contains user session information, as well as information about entities. Check the [section about using entities in Actions](#using-entities-in-actions) to see how to use the entities field on the `context` object, or the [auth section](../../auth/overview#using-the-contextuser-object) to see how to use the `user` object. After you [declare the Action](#declaring-actions), Wasp generates a generic type you can use when defining its implementation. For the Action declared as `createSomething`, the generated type is called `CreateSomething`: ```ts import { type CreateSomething } from 'wasp/server/operations' ``` It expects two (optional) type arguments: 1. `Input` The type of the `args` object (the Action's input payload). The default value is `never`. 2. `Output` The type of the Action's return value (the Action's output payload). The default value is `unknown`. The defaults were chosen to make the type signature as permissive as possible. If don't want your Action to take/return anything, use `void` as a type argument. ##### Example The following Action: ```wasp action createFoo { fn: import { createFoo } from "@src/actions" entities: [Foo] } ``` Expects to find a named export `createfoo` from the file `src/actions.js` ```js title="actions.js" export const createFoo = (args, context) => { // implementation } ``` The following Action: ```wasp action createFoo { fn: import { createFoo } from "@src/actions" entities: [Foo] } ``` Expects to find a named export `createfoo` from the file `src/actions.js` You can use the generated type `CreateFoo` and specify the Action's inputs and outputs using its type arguments. ```ts title="actions.ts" import { type CreateFoo } from 'wasp/server/operations' type Foo = // ... export const createFoo: CreateFoo<{ bar: string }, Foo> = (args, context) => { // implementation }; ``` In this case, the Action expects to receive an object with a `bar` field of type `string` (this is the type of `args`), and return a value of type `Foo` (this must match the type of the Action's return value). #### The `useAction` Hook and Optimistic Updates Make sure you understand how [Queries](../../data-model/operations/queries.md) and [Cache Invalidation](#cache-invalidation) work before reading this chapter. When using Actions in components, you can enhance them with the help of the `useAction` hook. This hook comes bundled with Wasp, and is used for decorating Wasp Actions. In other words, the hook returns a function whose API matches the original Action while also doing something extra under the hood (depending on how you configure it). The `useAction` hook accepts two arguments: - `actionFn` Required! The Wasp Action (the client-side Action function generated by Wasp based on a Action declaration) you wish to enhance. - `actionOptions` An object configuring the extra features you want to add to the given Action. While this argument is technically optional, there is no point in using the `useAction` hook without providing it (it would be the same as using the Action directly). The Action options object supports the following fields: - `optimisticUpdates` An array of objects where each object defines an [optimistic update](https://stackoverflow.com/a/33009713) to perform on the Query cache. To define an optimistic update, you must specify the following properties: - `getQuerySpecifier` Required! A function returning the Query specifier (a value used to address the Query you want to update). A Query specifier is an array specifying the query function and arguments. For example, to optimistically update the Query used with `useQuery(fetchFilteredTasks, {isDone: true }]`, your `getQuerySpecifier` function would have to return the array `[fetchFilteredTasks, { isDone: true}]`. Wasp will forward the argument you pass into the decorated Action to this function (you can use the properties of the added/changed item to address the Query). - `updateQuery` Required! The function used to perform the optimistic update. It should return the desired state of the cache. Wasp will call it with the following arguments: - `item` - The argument you pass into the decorated Action. - `oldData` - The currently cached value for the Query identified by the specifier. :::caution The `updateQuery` function must be a pure function. It must return the desired cache value identified by the `getQuerySpecifier` function and _must not_ perform any side effects. Also, make sure you only update the Query caches affected by your Action causing the optimistic update (Wasp cannot yet verify this). Finally, your implementation of the `updateQuery` function should work correctly regardless of the state of `oldData` (e.g., don't rely on array positioning). If you need to do something else during your optimistic update, you can directly use _react-query_'s lower-level API (read more about it [here](#advanced-usage)). ::: Here's an example showing how to configure the Action `markTaskAsDone` that toggles a task's `isDone` status to perform an optimistic update: ```jsx title="src/pages/Task.jsx" import React from 'react' import { useQuery, useAction, getTask, markTaskAsDone, } from 'wasp/client/operations' const TaskPage = ({ id }) => { const { data: task } = useQuery(getTask, { id }) // highlight-start const markTaskAsDoneOptimistically = useAction(markTaskAsDone, { optimisticUpdates: [ { getQuerySpecifier: ({ id }) => [getTask, { id }], updateQuery: (_payload, oldData) => ({ ...oldData, isDone: true }), }, ], }) // highlight-end if (!task) { return

"Loading"

} const { description, isDone } = task return (

Description: {description}

Is done: {isDone ? 'Yes' : 'No'}

{isDone || ( )}
) } export default TaskPage ```
```tsx title="src/pages/Task.tsx" import React from 'react' import { useQuery, useAction, type OptimisticUpdateDefinition, getTask, markTaskAsDone, } from 'wasp/client/operations' type TaskPayload = Pick; const TaskPage = ({ id }: { id: number }) => { const { data: task } = useQuery(getTask, { id }); // Typescript automatically type-checks the payload type. // highlight-start const markTaskAsDoneOptimistically = useAction(markTaskAsDone, { optimisticUpdates: [ { getQuerySpecifier: ({ id }) => [getTask, { id }], updateQuery: (_payload, oldData) => ({ ...oldData, isDone: true }), } as OptimisticUpdateDefinition, ], }); // highlight-end if (!task) { return

"Loading"

; } const { description, isDone } = task; return (

Description: {description}

Is done: {isDone ? "Yes" : "No"}

{isDone || ( )}
); }; export default TaskPage; ```
##### Advanced usage The `useAction` hook currently only supports specifying optimistic updates. You can expect more features in future versions of Wasp. Wasp's optimistic update API is deliberately small and focuses exclusively on updating Query caches (as that's the most common use case). You might need an API that offers more options or a higher level of control. If that's the case, instead of using Wasp's `useAction` hook, you can use _react-query_'s `useMutation` hook and directly work with [their low-level API](https://tanstack.com/query/v4/docs/framework/react/guides/optimistic-updates). If you decide to use _react-query_'s API directly, you will need access to Query cache key. Wasp internally uses this key but abstracts it from the programmer. Still, you can easily obtain it by accessing the `queryCacheKey` property on any Query: ```js import { getTasks } from 'wasp/client/operations' const queryKey = getTasks.queryCacheKey ``` ```ts import { getTasks } from 'wasp/client/operations' const queryKey = getTasks.queryCacheKey ``` ## Automatic CRUD If you have a lot of experience writing full-stack apps, you probably ended up doing some of the same things many times: listing data, adding data, editing it, and deleting it. Wasp makes handling these boring bits easy by offering a higher-level concept called Automatic CRUD. With a single declaration, you can tell Wasp to automatically generate server-side logic (i.e., Queries and Actions) for creating, reading, updating and deleting [Entities](../data-model/entities). As you update definitions for your Entities, Wasp automatically regenerates the backend logic. :::caution Early preview This feature is currently in early preview and we are actively working on it. Read more about [our plans](#future-of-crud-operations-in-wasp) for CRUD operations. ::: ### Overview Imagine we have a `Task` entity and we want to enable CRUD operations for it: ```prisma title="schema.prisma" model Task { id Int @id @default(autoincrement()) description String isDone Boolean } ``` We can then define a new `crud` called `Tasks`. We specify to use the `Task` entity and we enable the `getAll`, `get`, `create` and `update` operations (let's say we don't need the `delete` operation). ```wasp title="main.wasp" crud Tasks { entity: Task, operations: { getAll: { isPublic: true, // by default only logged in users can perform operations }, get: {}, create: { overrideFn: import { createTask } from "@src/tasks", }, update: {}, }, } ``` 1. It uses default implementation for `getAll`, `get`, and `update`, 2. ... while specifying a custom implementation for `create`. 3. `getAll` will be public (no auth needed), while the rest of the operations will be private. Here's what it looks like when visualized: We can now use the CRUD queries and actions we just specified in our client code. Keep reading for an example of Automatic CRUD in action, or skip ahead for the [API Reference](#api-reference). ### Example: A Simple TODO App Let's create a full-app example that uses automatic CRUD. We'll stick to using the `Task` entity from the previous example, but we'll add a `User` entity and enable [username and password](../auth/username-and-pass) based auth. #### Creating the App We can start by running `wasp new tasksCrudApp` and then adding the following to the `main.wasp` file: ```wasp title="main.wasp" app tasksCrudApp { wasp: { version: "{latestWaspVersion}" }, title: "Tasks Crud App", // We enabled auth and set the auth method to username and password auth: { userEntity: User, methods: { usernameAndPassword: {}, }, onAuthFailedRedirectTo: "/login", }, } // Tasks app routes route RootRoute { path: "/", to: MainPage } page MainPage { component: import { MainPage } from "@src/MainPage", authRequired: true, } route LoginRoute { path: "/login", to: LoginPage } page LoginPage { component: import { LoginPage } from "@src/LoginPage", } route SignupRoute { path: "/signup", to: SignupPage } page SignupPage { component: import { SignupPage } from "@src/SignupPage", } ``` And let's define our entities in the `schema.prisma` file: ```prisma title="schema.prisma" model User { id Int @id @default(autoincrement()) tasks Task[] } // We defined a Task entity on which we'll enable CRUD later on model Task { id Int @id @default(autoincrement()) description String isDone Boolean userId Int user User @relation(fields: [userId], references: [id]) } ``` We can then run `wasp db migrate-dev` to create the database and run the migrations. #### Adding CRUD to the `Task` Entity ✨ Let's add the following `crud` declaration to our `main.wasp` file: ```wasp title="main.wasp" // ... crud Tasks { entity: Task, operations: { getAll: {}, create: { overrideFn: import { createTask } from "@src/tasks", }, }, } ``` You'll notice that we enabled only `getAll` and `create` operations. This means that only these operations will be available. We also overrode the `create` operation with a custom implementation. This means that the `create` operation will not be generated, but instead, the `createTask` function from `@src/tasks.{js,ts}` will be used. #### Our Custom `create` Operation We need a custom `create` operation because we want to make sure that the task is connected to the user creating it. Automatic CRUD doesn't yet support this by default. Read more about the default implementations [here](#declaring-a-crud-with-default-options). Here's the `src/tasks.{js,ts}` file: ```js title="src/tasks.js" import { HttpError } from 'wasp/server' export const createTask = async (args, context) => { if (!context.user) { throw new HttpError(401, 'User not authenticated.') } const { description, isDone } = args const { Task } = context.entities return await Task.create({ data: { description, isDone, // highlight-start // Connect the task to the user that is creating it user: { connect: { id: context.user.id, }, }, // highlight-end }, }) } ``` ```ts title="src/tasks.ts" import { type Tasks } from 'wasp/server/crud' import { type Task } from 'wasp/entities' import { HttpError } from 'wasp/server' type CreateTaskInput = { description: string; isDone: boolean } export const createTask: Tasks.CreateAction = async ( args, context ) => { if (!context.user) { throw new HttpError(401, 'User not authenticated.') } const { description, isDone } = args const { Task } = context.entities return await Task.create({ data: { description, isDone, // highlight-start // Connect the task to the user that is creating it user: { connect: { id: context.user.id, }, }, // highlight-end }, }) } ``` Wasp automatically generates the `Tasks.CreateAction` type based on the CRUD declaration in your Wasp file. Use it to type the CRUD action's implementation. The `Tasks.CreateAction` type works exactly like the types Wasp generates for [Queries](../data-model/operations/queries#type-support-for-queries) and [Actions](../data-model/operations/actions#type-support-for-actions). In other words, annotating the action with `Tasks.CreateAction` tells TypeScript about the type of the Action's `context` object, while the two type arguments allow you to specify the Action's inputs and outputs. Read more about type support for CRUD overrides in the [API reference](#defining-the-overrides). #### Using the Generated CRUD Operations on the Client And let's use the generated operations in our client code: ```jsx title="src/MainPage.jsx" // highlight-next-line import { Tasks } from 'wasp/client/crud' import { useState } from 'react' export const MainPage = () => { // highlight-next-line const { data: tasks, isLoading, error } = Tasks.getAll.useQuery() // highlight-next-line const createTask = Tasks.create.useAction() const [taskDescription, setTaskDescription] = useState('') function handleCreateTask() { createTask({ description: taskDescription, isDone: false }) setTaskDescription('') } if (isLoading) return
Loading...
if (error) return
Error: {error.message}
return (
setTaskDescription(e.target.value)} />
    {tasks.map((task) => (
  • {task.description}
  • ))}
) } ```
```tsx title="src/MainPage.tsx" // highlight-next-line import { Tasks } from 'wasp/client/crud' import { useState } from 'react' export const MainPage = () => { // highlight-next-line // Thanks to full-stack type safety, all payload types are inferred // highlight-next-line // automatically // highlight-next-line const { data: tasks, isLoading, error } = Tasks.getAll.useQuery() // highlight-next-line const createTask = Tasks.create.useAction() const [taskDescription, setTaskDescription] = useState('') function handleCreateTask() { createTask({ description: taskDescription, isDone: false }) setTaskDescription('') } if (isLoading) return
Loading...
if (error) return
Error: {error.message}
return (
setTaskDescription(e.target.value)} />
    {tasks.map((task) => (
  • {task.description}
  • ))}
) } ```
And here are the login and signup pages, where we are using Wasp's [Auth UI](../auth/ui) components: ```jsx title="src/LoginPage.jsx" import { LoginForm } from 'wasp/client/auth' import { Link } from 'react-router' export function LoginPage() { return (
Create an account
) } ```
```tsx title="src/LoginPage.tsx" import { LoginForm } from 'wasp/client/auth' import { Link } from 'react-router' export function LoginPage() { return (
Create an account
) } ```
```jsx title="src/SignupPage.jsx" import { SignupForm } from 'wasp/client/auth' export function SignupPage() { return (
) } ```
```tsx title="src/SignupPage.tsx" import { SignupForm } from 'wasp/client/auth' export function SignupPage() { return (
) } ```
That's it. You can now run `wasp start` and see the app in action. âšĄī¸ You should see a login page and a signup page. After you log in, you should see a page with a list of tasks and a form to create new tasks. ### Future of CRUD Operations in Wasp CRUD operations currently have a limited set of knowledge about the business logic they are implementing. - For example, they don't know that a task should be connected to the user that is creating it. This is why we had to override the `create` operation in the example above. - Another thing: they are not aware of the authorization rules. For example, they don't know that a user should not be able to create a task for another user. In the future, we will be adding role-based authorization to Wasp, and we plan to make CRUD operations aware of the authorization rules. - Another issue is input validation and sanitization. For example, we might want to make sure that the task description is not empty. CRUD operations are a mechanism for getting a backend up and running quickly, but it depends on the information it can get from the Wasp app. The more information that it can pick up from your app, the more powerful it will be out of the box. We plan on supporting CRUD operations and growing them to become the easiest way to create your backend. Follow along on [this GitHub issue](https://github.com/wasp-lang/wasp/issues/1253) to see how we are doing. ### API Reference CRUD declaration works on top of an existing entity declaration. We'll fully explore the API using two examples: 1. A basic CRUD declaration that relies on default options. 2. A more involved CRUD declaration that uses extra options and overrides. #### Declaring a CRUD With Default Options If we create CRUD operations for an entity named `Task`, like this: ```wasp title="main.wasp" crud Tasks { // crud name here is "Tasks" entity: Task, operations: { get: {}, getAll: {}, create: {}, update: {}, delete: {}, }, } ``` Wasp will give you the following default implementations: **get** - returns one entity based on the `id` field ```js // ... // Wasp uses the field marked with `@id` in Prisma schema as the id field. return Task.findUnique({ where: { id: args.id } }) ``` **getAll** - returns all entities ```js // ... // If the operation is not public, Wasp checks if an authenticated user // is making the request. return Task.findMany() ``` **create** - creates a new entity ```js // ... return Task.create({ data: args.data }) ``` **update** - updates an existing entity ```js // ... // Wasp uses the field marked with `@id` in Prisma schema as the id field. return Task.update({ where: { id: args.id }, data: args.data }) ``` **delete** - deletes an existing entity ```js // ... // Wasp uses the field marked with `@id` in Prisma schema as the id field. return Task.delete({ where: { id: args.id } }) ``` ```wasp title="main.wasp" crud Tasks { // crud name here is "Tasks" entity: Task, operations: { get: {}, getAll: {}, create: {}, update: {}, delete: {}, }, } ``` Wasp will give you the following default implementations: **get** - returns one entity based on the `id` field ```ts // ... // Wasp uses the field marked with `@id` in Prisma schema as the id field. return Task.findUnique({ where: { id: args.id } }) ``` **getAll** - returns all entities ```ts // ... // If the operation is not public, Wasp checks if an authenticated user // is making the request. return Task.findMany() ``` **create** - creates a new entity ```ts // ... return Task.create({ data: args.data }) ``` **update** - updates an existing entity ```ts // ... // Wasp uses the field marked with `@id` in Prisma schema as the id field. return Task.update({ where: { id: args.id }, data: args.data }) ``` **delete** - deletes an existing entity ```ts // ... // Wasp uses the field marked with `@id` in Prisma schema as the id field. return Task.delete({ where: { id: args.id } }) ``` :::info Current Limitations In the default `create` and `update` implementations, we are saving all of the data that the client sends to the server. This is not always desirable, i.e. in the case when the client should not be able to modify all of the data in the entity. [In the future](#future-of-crud-operations-in-wasp), we are planning to add validation of action input, where only the data that the user is allowed to change will be saved. For now, the solution is to provide an override function. You can override the default implementation by using the `overrideFn` option and implementing the validation logic yourself. ::: #### Declaring a CRUD With All Available Options Here's an example of a more complex CRUD declaration: ```wasp title="main.wasp" crud Tasks { // crud name here is "Tasks" entity: Task, operations: { getAll: { isPublic: true, // optional, defaults to false }, get: {}, create: { overrideFn: import { createTask } from "@src/tasks", // optional }, update: {}, }, } ``` ```wasp title="main.wasp" crud Tasks { // crud name here is "Tasks" entity: Task, operations: { getAll: { isPublic: true, // optional, defaults to false }, get: {}, create: { overrideFn: import { createTask } from "@src/tasks", // optional }, update: {}, }, } ``` The CRUD declaration features the following fields: - `entity: Entity` Required! The entity to which the CRUD operations will be applied. - `operations: { [operationName]: CrudOperationOptions }` Required! The operations to be generated. The key is the name of the operation, and the value is the operation configuration. - The possible values for `operationName` are: - `getAll` - `get` - `create` - `update` - `delete` - `CrudOperationOptions` can have the following fields: - `isPublic: bool` - Whether the operation is public or not. If it is public, no auth is required to access it. If it is not public, it will be available only to authenticated users. Defaults to `false`. - `overrideFn: ExtImport` - The import statement of the optional override implementation in Node.js. ##### Defining the overrides Like with actions and queries, you can define the implementation in a Javascript/Typescript file. The overrides are functions that take the following arguments: - `args` The arguments of the operation i.e. the data sent from the client. - `context` Context contains the `user` making the request and the `entities` object with the entity that's being operated on. You can also import types for each of the functions you want to override by importing the `{crud name}` from `wasp/server/crud`. The available types are: - `{crud name}.GetAllQuery` - `{crud name}.GetQuery` - `{crud name}.CreateAction` - `{crud name}.UpdateAction` - `{crud name}.DeleteAction` If you have a CRUD named `Tasks`, you would import the types like this: ```ts import { type Tasks } from 'wasp/server/crud' // Each of the types is a generic type, so you can use it like this: export const getAllOverride: Tasks.GetAllQuery = async ( args, context ) => { // ... } ``` For a usage example, check the [example guide](../data-model/crud#adding-crud-to-the-task-entity-). ##### Using the CRUD operations in client code On the client, you import the CRUD operations from `wasp/client/crud` by import the `{crud name}` object. For example, if you have a CRUD called `Tasks`, you would import the operations like this: ```jsx title="SomePage.jsx" import { Tasks } from 'wasp/client/crud' ``` ```tsx title="SomePage.tsx" import { Tasks } from 'wasp/client/crud' ``` You can then access the operations like this: ```jsx title="SomePage.jsx" const { data } = Tasks.getAll.useQuery() const { data } = Tasks.get.useQuery({ id: 1 }) const createAction = Tasks.create.useAction() const updateAction = Tasks.update.useAction() const deleteAction = Tasks.delete.useAction() ``` ```tsx title="SomePage.tsx" const { data } = Tasks.getAll.useQuery() const { data } = Tasks.get.useQuery({ id: 1 }) const createAction = Tasks.create.useAction() const updateAction = Tasks.update.useAction() const deleteAction = Tasks.delete.useAction() ``` All CRUD operations are implemented with [Queries and Actions](../data-model/operations/overview) under the hood, which means they come with all the features you'd expect (e.g., automatic SuperJSON serialization, full-stack type safety when using TypeScript) --- Join our **community** on [Discord](https://discord.com/invite/rzdnErX), where we chat about full-stack web stuff. Join us to see what we are up to, share your opinions or get help with CRUD operations. ## Databases [Entities](../data-model/entities.md), [Operations](../data-model/operations/overview) and [Automatic CRUD](../data-model/crud.md) together make a high-level interface for working with your app's data. Still, all that data has to live somewhere, so let's see how Wasp deals with databases. ### Supported Database Backends Wasp supports multiple database backends. We'll list and explain each one. #### SQLite The default database Wasp uses is [SQLite](https://www.sqlite.org/index.html). When you create a new Wasp project, the `schema.prisma` file will have SQLite as the default database provider: ```prisma title="schema.prisma" datasource db { provider = "sqlite" url = env("DATABASE_URL") } // ... ``` Read more about how Wasp uses the Prisma schema file in the [Prisma schema file](./prisma-file.md) section. When you use the SQLite database, Wasp sets the `DATABASE_URL` environment variable for you. SQLite is a great way to get started with a new project because it doesn't require any configuration, but Wasp can only use it in development. Once you want to deploy your Wasp app to production, you'll need to switch to PostgreSQL and stick with it. Fortunately, migrating from SQLite to PostgreSQL is pretty simple, and we have [a guide](#migrating-from-sqlite-to-postgresql) to help you. #### PostgreSQL [PostgreSQL](https://www.postgresql.org/) is the most advanced open-source database and one of the most popular databases overall. It's been in active development for 20+ years. Therefore, if you're looking for a battle-tested database, look no further. To use PostgreSQL with Wasp, set the provider to `"postgresql"` in the `schema.prisma` file: ```prisma title="schema.prisma" datasource db { provider = "postgresql" url = env("DATABASE_URL") } // ... ``` Read more about how Wasp uses the Prisma schema file in the [Prisma schema file](./prisma-file.md) section. You'll have to ensure a database instance is running during development to use PostgreSQL. Wasp needs access to your database for commands such as `wasp start` or `wasp db migrate-dev`. We cover all supported ways of connecting to a database in [the next section](#connecting-to-a-database). ### Connecting to a Database #### SQLite If you are using SQLite, you don't need to do anything special to connect to the database. Wasp will take care of it for you. #### PostgreSQL If you are using PostgreSQL, Wasp supports two ways of connecting to a database: 1. For managed experience, let Wasp spin up a ready-to-go development database for you. 2. For more control, you can specify a database URL and connect to an existing database that you provisioned yourself. ##### Using the Dev Database provided by Wasp The command `wasp start db` will start a default PostgreSQL dev database for you. Your Wasp app will automatically connect to it, just keep `wasp start db` running in the background. Also, make sure that: - You have [Docker installed](https://www.docker.com/get-started/) and it's available in your `PATH`. - The port `5432` isn't taken. :::tip In case you might want to connect to the dev database through the external tool like `psql` or [pgAdmin](https://www.pgadmin.org/), the credentials are printed in the console when you run `wasp db start`, at the very beginning. ::: ###### Customising the dev database {#custom-database} The Wasp development database uses the [PostgreSQL 18 Docker image](https://hub.docker.com/_/postgres/tags?name=18) by default, and will set up its data volumes according to their guidance. If you need to customise the development database, you can use the following options: - `--db-image`: Specify a custom Docker image Useful for PostgreSQL extensions or specific versions (for example, PostGIS, pgvector, etc.). - `--db-volume-mount-path`: Specify the volume mount path inside the container You only need to set this option if your custom `--db-image` is based on **PostgreSQL 17 or older** (check the `postgres:15` example below). If the volume mount path is incorrect, the data won't be persisted in your development database. Here are some examples of customising the development database: ```bash ## Use default PostgreSQL image: wasp start db ## Same as: wasp start db --db-image postgres:18 ## Use PostgreSQL with PostGIS extension for geographic data: wasp start db --db-image postgis/postgis:18-3.6 ## Use PostgreSQL with pgvector extension for AI embeddings: wasp start db --db-image pgvector/pgvector:pg18 ## Use PostgreSQL version 15 (requires different volume path): wasp start db --db-image postgres:15 --db-volume-mount-path /var/lib/postgresql/data ``` :::note The custom Docker image you specify must use the `POSTGRES_DB`, `POSTGRES_USER`, and `POSTGRES_PASSWORD` environment variables when configuring the database. Wasp will use those values when connecting to the database. We recommend basing your image on the official [PostgreSQL Docker image](https://hub.docker.com/_/postgres), as it automatically uses these environment variables to set up the database name, user, and password. ::: ##### Connecting to an existing database If you want to spin up your own dev database (or connect to an external one), you can tell Wasp about it using the `DATABASE_URL` environment variable. Wasp will use the value of `DATABASE_URL` as a connection string. The easiest way to set the necessary `DATABASE_URL` environment variable is by adding it to the [.env.server](../project/env-vars) file in the root dir of your Wasp project (if that file doesn't yet exist, create it): ```env title=".env.server" DATABASE_URL=postgresql://user:password@localhost:5432/mydb ``` Alternatively, you can set it inline when running `wasp` (this applies to all environment variables): ```bash DATABASE_URL= wasp ... ``` This trick is useful for running a certain `wasp` command on a specific database. For example, you could do: ```bash DATABASE_URL= wasp db seed myProductionSeed ``` This command seeds the data for a fresh staging or production database. Read more about [seeding the database](#seeding-the-database). ### Migrating from SQLite to PostgreSQL To run your Wasp app in production, you'll need to switch from SQLite to PostgreSQL. 1. Set the provider to `"postgresql"` in the `schema.prisma` file: ```prisma title="schema.prisma" datasource db { // highlight-next-line provider = "postgresql" url = env("DATABASE_URL") } // ... ``` 2. Delete all the old migrations, since they are SQLite migrations and can't be used with PostgreSQL, as well as the SQLite database by running [`wasp clean`](../general/cli#project-commands): ```bash rm -r migrations/ wasp clean ``` 3. Ensure your new database is running (check the [section on connecting to a database](#connecting-to-a-database) to see how). Leave it running, since we need it for the next step. 4. In a different terminal, run `wasp db migrate-dev` to apply the changes and create a new initial migration. 5. That is it, you are all done! ### Seeding the Database **Database seeding** is a term used for populating the database with some initial data. Seeding is most commonly used for: 1. Getting the development database into a state convenient for working and testing. 2. Initializing any database (`dev`, `staging`, or `prod`) with essential data it requires to operate. For example, populating the Currency table with default currencies, or the Country table with all available countries. #### Writing a Seed Function You can define as many **seed functions** as you want in an array under the `app.db.seeds` field: ```wasp title="main.wasp" app MyApp { // ... db: { seeds: [ import { devSeedSimple } from "@src/dbSeeds.js", import { prodSeed } from "@src/dbSeeds.js" ] } } ``` ```wasp title="main.wasp" app MyApp { // ... db: { seeds: [ import { devSeedSimple } from "@src/dbSeeds.js", import { prodSeed } from "@src/dbSeeds.js" ] } } ``` Each seed function must be an async function that takes one argument, `prisma`, which is a [Prisma Client](https://www.prisma.io/docs/concepts/components/prisma-client/crud) instance used to interact with the database. This is the same Prisma Client instance that Wasp uses internally. Since a seed function falls under server-side code, it can import other server-side functions. This is convenient because you might want to seed the database using Actions. Here's an example of a seed function that imports an Action: ```js import { createTask } from './actions.js' import { sanitizeAndSerializeProviderData } from 'wasp/server/auth' export const devSeedSimple = async (prisma) => { const user = await createUser(prisma, { username: 'RiuTheDog', password: 'bark1234', }) await createTask( { description: 'Chase the cat' }, { user, entities: { Task: prisma.task } } ) } async function createUser(prisma, data) { const newUser = await prisma.user.create({ data: { auth: { create: { identities: { create: { providerName: 'username', providerUserId: data.username, providerData: await sanitizeAndSerializeProviderData({ hashedPassword: data.password }), }, }, }, }, }, }) return newUser } ``` ```ts import { createTask } from './actions.js' import type { DbSeedFn } from 'wasp/server' import { sanitizeAndSerializeProviderData } from 'wasp/server/auth' import type { AuthUser } from 'wasp/auth' import type { PrismaClient } from 'wasp/server' export const devSeedSimple: DbSeedFn = async (prisma) => { const user = await createUser(prisma, { username: 'RiuTheDog', password: 'bark1234', }) await createTask( { description: 'Chase the cat', isDone: false }, { user, entities: { Task: prisma.task } } ) }; async function createUser( prisma: PrismaClient, data: { username: string, password: string } ): Promise { const newUser = await prisma.user.create({ data: { auth: { create: { identities: { create: { providerName: 'username', providerUserId: data.username, providerData: await sanitizeAndSerializeProviderData<'username'>({ hashedPassword: data.password }), }, }, }, }, }, }) return newUser } ``` Wasp exports a type called `DbSeedFn` which you can use to easily type your seeding function. Wasp defines `DbSeedFn` like this: ```typescript type DbSeedFn = (prisma: PrismaClient) => Promise ``` Annotating the function `devSeedSimple` with this type tells TypeScript: - The seeding function's argument (`prisma`) is of type `PrismaClient`. - The seeding function's return value is `Promise`. #### Running seed functions Run the command `wasp db seed` and Wasp will ask you which seed function you'd like to run (if you've defined more than one). Alternatively, run the command `wasp db seed ` to choose a specific seed function right away, for example: ``` wasp db seed devSeedSimple ``` Check the [API Reference](#cli-commands-for-seeding-the-database) for more details on these commands. :::tip You'll often want to call `wasp db seed` right after you run `wasp db reset`, as it makes sense to fill the database with initial data after clearing it. ::: ### Customising the Prisma Client Wasp interacts with the database using the [Prisma Client](https://www.prisma.io/docs/orm/prisma-client). To customize the client, define a function in the `app.db.prismaSetupFn` field that returns a Prisma Client instance. This allows you to configure features like [logging](https://www.prisma.io/docs/orm/prisma-client/observability-and-logging/logging) or [client extensions](https://www.prisma.io/docs/orm/prisma-client/client-extensions): ```wasp title=main.wasp app MyApp { title: "My app", // ... db: { prismaSetupFn: import { setUpPrisma } from "@src/prisma" } } ``` ```js title="src/prisma.js" import { PrismaClient } from '@prisma/client' export const setUpPrisma = () => { const prisma = new PrismaClient({ log: ['query'], }).$extends({ query: { task: { async findMany({ args, query }) { args.where = { ...args.where, description: { not: { contains: 'hidden by setUpPrisma' } }, } return query(args) }, }, }, }) return prisma } ``` ```wasp title=main.wasp app MyApp { title: "My app", // ... db: { prismaSetupFn: import { setUpPrisma } from "@src/prisma" } } ``` ```ts title="src/prisma.ts" import { PrismaClient } from '@prisma/client' export const setUpPrisma = () => { const prisma = new PrismaClient({ log: ['query'], }).$extends({ query: { task: { async findMany({ args, query }) { args.where = { ...args.where, description: { not: { contains: 'hidden by setUpPrisma' } }, } return query(args) }, }, }, }) return prisma } ``` ### API Reference ```wasp title="main.wasp" app MyApp { title: "My app", // ... db: { seeds: [ import devSeed from "@src/dbSeeds" ], prismaSetupFn: import { setUpPrisma } from "@src/prisma" } } ``` ```wasp title="main.wasp" app MyApp { title: "My app", // ... db: { seeds: [ import devSeed from "@src/dbSeeds" ], prismaSetupFn: import { setUpPrisma } from "@src/prisma" } } ``` `app.db` is a dictionary with the following fields (all fields are optional): - `seeds: [ExtImport]` Defines the seed functions you can use with the `wasp db seed` command to seed your database with initial data. Read the [Seeding section](#seeding-the-database) for more details. - `prismaSetupFn: ExtImport` Defines a function that sets up the Prisma Client instance. Wasp expects it to return a Prisma Client instance. You can use this function to set up [logging](https://www.prisma.io/docs/orm/prisma-client/observability-and-logging/logging) or [client extensions](https://www.prisma.io/docs/orm/prisma-client/client-extensions): ```ts title="src/prisma.ts" import { PrismaClient } from '@prisma/client' export const setUpPrisma = () => { const prisma = new PrismaClient({ log: ['query', 'info', 'warn', 'error'], }) return prisma } ``` #### CLI Commands for Seeding the Database Use one of the following commands to run the seed functions: - `wasp db seed` If you've only defined a single seed function, this command runs it. If you've defined multiple seed functions, it asks you to choose one interactively. - `wasp db seed ` This command runs the seed function with the specified name. The name is the identifier used in its `import` expression in the `app.db.seeds` list. For example, to run the seed function `devSeedSimple` which was defined like this: ```wasp title="main.wasp" app MyApp { // ... db: { seeds: [ // ... import { devSeedSimple } from "@src/dbSeeds.js", ] } } ``` ```wasp title="main.wasp" app MyApp { // ... db: { seeds: [ // ... import { devSeedSimple } from "@src/dbSeeds.js", ] } } ``` Use the following command: ``` wasp db seed devSeedSimple ``` ## Prisma Schema File Wasp uses [Prisma](https://www.prisma.io/) to interact with the database. Prisma is a "Next-generation Node.js and TypeScript ORM" that provides a type-safe API for working with your database. With Prisma, you define your application's data model in a `schema.prisma` file. Read more about how Wasp Entities relate to Prisma models on the [Entities](./entities.md) page. In Wasp, the `schema.prisma` file is located in your project's root directory: ```c . ├── main.wasp ... // highlight-next-line ├── schema.prisma ├── src ├── tsconfig.json └── vite.config.ts ``` Wasp uses the `schema.prisma` file to understand your app's data model and generate the necessary code to interact with the database. ### Wasp file and Prisma schema file Let's see how Wasp and Prisma files work together to define your application. Here's an example `schema.prisma` file where we defined some database options and two models (User and Task) with a one-to-many relationship: ```prisma title="schema.prisma" datasource db { provider = "postgresql" url = env("DATABASE_URL") } generator client { provider = "prisma-client-js" } model User { id Int @id @default(autoincrement()) tasks Task[] } model Task { id Int @id @default(autoincrement()) description String isDone Boolean @default(false) user User @relation(fields: [userId], references: [id]) userId Int } ``` Wasp reads this `schema.prisma` file and extracts the info about your database models and database config. The `datasource` block defines which database you want to use (PostgreSQL in this case) and some other options. The `generator` block defines how to generate the Prisma Client code that you can use in your application to interact with the database. Finally, Prisma models become Wasp Entities which can be then used in the `main.wasp` file: ```wasp title="main.wasp" app myApp { wasp: { version: "{latestWaspVersion}" }, title: "My App", } ... // Using Wasp Entities in the Wasp file query getTasks { fn: import { getTasks } from "@src/queries", // highlight-next-line entities: [Task] } job myJob { executor: PgBoss, perform: { fn: import { foo } from "@src/workers/bar" }, // highlight-next-line entities: [Task], } api fooBar { fn: import { fooBar } from "@src/apis", // highlight-next-line entities: [Task], httpRoute: (GET, "/foo/bar/:email") } ``` In the implementation of the `getTasks` query, `Task` is a Wasp Entity that corresponds to the `Task` model defined in the `schema.prisma` file. The same goes for the `myJob` job and `fooBar` API, where `Task` is used as an Entity. To learn more about the relationship between Wasp Entities and Prisma models, check out the [Entities](./entities.md) page. ### Wasp-specific Prisma configuration Wasp mostly lets you use the Prisma schema file as you would in any other JS/TS project. However, there are some Wasp-specific rules you need to follow. #### The `datasource` block ```prisma title="schema.prisma" datasource db { provider = "postgresql" url = env("DATABASE_URL") } ``` Wasp takes the `datasource` you write and use it as-is. There are some rules you need to follow: - You can only use `"postgresql"` or `"sqlite"` as the `provider` because Wasp only supports PostgreSQL and SQLite databases for now. - You must set the `url` field to `env("DATABASE_URL")` so that Wasp can work properly with your database. #### The `generator` blocks ```prisma title="schema.prisma" generator client { provider = "prisma-client-js" } ``` Wasp requires that there is a `generator` block with `provider = "prisma-client-js"` in the `schema.prisma` file. You can add additional generators if you need them in your project. #### The `model` blocks ```prisma title="schema.prisma" model User { id Int @id @default(autoincrement()) tasks Task[] } model Task { id Int @id @default(autoincrement()) description String isDone Boolean @default(false) user User @relation(fields: [userId], references: [id]) userId Int } ``` You can define your models in any way you like, if it's valid Prisma schema code, it will work with Wasp. #### The `enum` blocks As our applications grow in complexity, we might want to use [Prisma `enum`s](https://www.prisma.io/docs/orm/prisma-schema/data-model/models#defining-enums) to closely define our app's domain. For example, if we had a `Task` model with a boolean `isDone`, and we wanted to start to track whether it is in progress, we could migrate the field to a more expressive type: ```prisma title="schema.prisma" enum TaskStatus { NotStarted Doing Done } model Task { ... state TaskStatus @default(NotStarted) } ``` Make sure to check [Prisma's enum compatibility with your database](https://www.prisma.io/docs/orm/reference/database-features#misc). If it works with Prisma, it will work with Wasp. ##### How to use `enum`s in your code If you need to access your `enum` cases and their values from your server, you can import them directly from `@prisma/client`: ```js title="src/queries.js" import { TaskState } from "@prisma/client"; import { Task } from "wasp/entities"; export const getOpenTasks = async (args, context) => { return context.entities.Task.findMany({ orderBy: { id: "asc" }, where: { NOT: { state: TaskState.Done } }, }); }; ``` ```ts title="src/queries.ts" import { TaskState } from "@prisma/client"; import { Task } from "wasp/entities"; import { type GetTasks } from "wasp/server/operations"; export const getOpenTasks: GetTasks = async (args, context) => { return context.entities.Task.findMany({ orderBy: { id: "asc" }, where: { NOT: { state: TaskState.Done } }, }); }; ``` You can also access them from your client code: ```js title="src/views/TaskList.jsx" import { TaskState } from "@prisma/client"; const TaskRow = ({ task }) => { return (
{task.description}
); }; ```
```ts title="src/views/TaskList.tsx" import { TaskState } from "@prisma/client"; import { Task } from "wasp/entities"; const TaskRow = ({ task }: { task: Task }) => { return (
{task.description}
); }; ```
:::note Triple slash comments Wasp only supports `///` in the _leading_ position: ```prisma title="schema.prisma" model User { // highlight-next-line /// The unique identifier for the user. id Int @id @default(autoincrement()) } ``` However, Wasp does not support `///` comments in the _trailing_ position: ```prisma title="schema.prisma" model User { // highlight-next-line id Int @id @default(autoincrement()) /// This is not supported } ``` We are aware of this issue and are tracking it at [#3041](https://github.com/wasp-lang/wasp/issues/3041), let us know if this is something you need. ::: ### Prisma preview features Prisma is still in active development and some of its features are not yet stable. To enable various preview features in Prisma, you need to add the `previewFeatures` field to the `generator` block in the `schema.prisma` file. For example, one useful Prisma preview feature is PostgreSQL extensions support, which allows you to use PostgreSQL extensions like `pg_vector` or `pg_trgm` in your database schema: ```prisma title="schema.prisma" datasource db { provider = "postgresql" url = env("DATABASE_URL") extensions = [pgvector(map: "vector")] } generator client { provider = "prisma-client-js" previewFeatures = ["postgresqlExtensions"] } // ... ``` Read more about preview features in the Prisma docs [here](https://www.prisma.io/docs/orm/reference/preview-features/client-preview-features) or about using PostgreSQL extensions [here](https://www.prisma.io/docs/orm/prisma-schema/postgresql-extensions). ------ # Authentication ## Authentication Overview Auth is an essential piece of any serious application. That's why Wasp provides authentication and authorization support out of the box. Here's a 1-minute tour of how full-stack auth works in Wasp: