There are two major categories that you'll encounter when you start to build Full Stack applications.

You have:
💽 Database Management 
👥 Authentication

Both of these contain their unique set of challenges and layer on top of each other as you build out your application.

You want to be able to Create, Read, Update, and Delete data from your database and also make sure that only the right users are performing these actions that you specify.

That is why this course is set up around these two categories.

You'll learn everything you need to about managing data using a service called Appwrite within your React application. Using Appwrite, you'll be able to create a database, upload files, and manage users. 

You'll start out by building out the database while purposefully ignoring authentication/authorization through out the application. 

The second part of the course will have you layer on auth so that you can enable users to log in and scope specific actions to roles that you'll create.

This course is focused on the full stack nature of web development so we will start with almost all of our UI built out for us. You can explore the course repository to get familiar with what components are available. 

Our goal is to create an application that allows us and others to create and manage event listings to help others discover events in their area. The first step in getting there is getting set up with a new application that we can start building upon.

In this first lesson, we’ll dig right in by creating a new React application on top of Vite. We’ll learn how we can use an existing template cloned to our local filesystem using degit, to ultimately give us the ability to more quickly start a new project with some templated groundwork that we can use between this and other new projects.

We’ll explore our new application including some of the basic UI and routing that will allow us to jump right into getting started wiring it up with Appwrite.

**What You’ll Learn**
- Create a new React app from a starter template
- Get familiar with how the app is organized including routing

**Resources**
- [Starter](https://github.com/colbyfayock/livebeat-starter)


Create a New React App with degit

Building projects on top of other services usually means interfacing with some kind of API. If you’re lucky, you’ll get an SDK, which makes it easier to interact with that API in a way that’s native to the environment you're working in.

Since we're building a web app, we can leverage the Appwrite Web SDK to simplify building a full stack application on top of the various Appwrite services.

We’ll walk through setting up a new Appwrite account, creating a project, and configuring our new project along with the SDK inside of our app.

**What You’ll Learn**
- Create a new Appwrite project
- Install the Appwrite Web SDK in a React project
- Configure the Web SDK using the Appwrite endpoint and a Project ID

**Resources**
- [Appwrite](https://appwrite.io/)
- [Getting Started for Web](https://appwrite.io/docs/getting-started-for-web)
- [Appwrite Web SDK](https://www.npmjs.com/package/appwrite)


Install & Configure the Appwrite Web SDK

Displaying a list of events in an app ultimately relies on a location to store the data that supports those events. It’s important that this mechanism is flexible and reliable so that we can store the different types of data we need, as well as having the ability to lock down that data in the future with custom permissions.

One of the many services Appwrite provides is being able to create and manage Databases, which allows us to easily interact with the data for our events. By building our database with Appwrite, we can easily connect to the other services Appwrite provides. But for now, this is a perfect location to store each of our events.

We’ll start off by creating a new Database and Collection where we can store our data in Documents. We’ll then walk through creating the basic fields we’ll need for our Documents, how to configure the data types for each field, and opening up permissions so we can start to interact with our Collection programmatically followed by creating our first Collection Document in the UI.

**What You’ll Learn**
- Create a new Database and Collection with the Appwrite UI
- Define a schema and fields with data types for the Collection Documents
- Configure permissions for new the Collection
- Add a new Document using the UI

**Resources**
- [Appwrite Databases](https://appwrite.io/docs/databases)


Create a new Database & Collection in Appwrite

In the last lesson, we set up our new database and now it’s time to read our Documents and list them out in our project. This is where we’ll start working with the Web SDK to programmatically request those event Documents and dynamically pull them into our application so that when someone adds a new one, our application will show it right away.

We’ll first start out by learning how to use the Databases service. Once that’s ready to go, we’ll use the List Documents endpoint configured to pull the data into our application from our previously created Database Collection. We’ll then define a new Type for our data to make sure we’re working with our event safely throughout the app.

**What You’ll Learn**
- Configure the Databases service
- List all Documents in a Database Collection
- Define Types for our event data
- Use environment variables to manage service IDs

**Resources**
- [List All Documents](https://appwrite.io/docs/client/databases?sdk=web-default#databasesListDocuments)


List All Documents from an Appwrite Database Collection

Showing a grid of events is a great way for someone to browse, but once one catches their attention, they want to dig in for more info, or maybe they want a way to share a direct link to that event. Either way, we want to be able to have a page that requests an individual event, not a whole list of them.

We have some flexibility in how we request our data with the Appwrite SDK, where we can use the Get Document endpoint to pass in a single ID and get all the data for that particular event. This will allow us to work together with our router to dynamically get that value based on navigation and look up that individual event.

We’ll make this work by first requesting a single document by passing in a static example ID. Later, we’ll use the router to get our individual event’s ID dynamically. In order to clean things up, we’ll see how we can start to refactor and abstract some of our data transformation logic as well as how we can use Appwrite’s included Types to make sure we’re fully type-safe when working with Documents.

**What You’ll Learn**
- Request a Document by ID from a Database Collection
- Import and use the Appwrite Document Type
- Abstract and share data transformation functions
- Type local state when using the useState hook
- Use a router to dynamically use a path ID variable for requesting a Document

**Resources**
- [Get a Document](https://appwrite.io/docs/client/databases?sdk=web-default#databasesGetDocument)
- [Routing in React.js with Wouter](https://www.youtube.com/watch?v=nvGhGSmEQZU)



Get a Single Document from a Database Collection with the Appwrite SDK

Part of the appeal of our events site is not only being able to show cool events, but allowing others to submit their own events. But so far we’ve only worked with data that already exists in our database, how do we create data?

The Appwrite SDK gives us the ability to easily create a new Document by passing in our data. Additionally, the SDK provides helpers that make dealing with things like unique Document IDs easy. But part of the trick with creating new data, is we need a mechanism to input data, which is where we’ll see how we can read a form in React with Typed out data, so that we can pass it along formatted to Appwrite.

We’ll first learn how to create a new Document using the Appwrite SDK. This includes the ID helpers for generating a unique ID, formatting dates to the required format, and using our existing Types for that creation process. When passing along our Types, we’ll omit the ID which we’ll only get once the data exists in the first place. We’ll then see how we can dynamically grab data from a form, rather than hardcoding the input data, and open up access so that we have permission to create our new Document in Appwrite.

**What You’ll Learn**
- Create a new Document in a Database Collection
- Use the Appwrite ID helper to generate a unique ID
- Format a date in the ISO format
- Use the TypeScript Omit utility to use all properties of a Type  except the ones omitted
- Configure Create access for Documents
- Read and set Types for data from a form

**Resources**
- [Create a Document](https://appwrite.io/docs/client/databases?sdk=web-default#databasesCreateDocument)
- [Permissions](https://appwrite.io/docs/permissions)
- [Date.toISOString](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString)
- [TypeScript Omit](https://www.typescriptlang.org/docs/handbook/utility-types.html#omittype-keys)


Create a new Document in an Appwrite Database Collection

Events are exciting in nature, but a wall of text in an app… isn’t the most exciting. We can liven this up by using images within our application, particularly allowing our event submitters to attach a photo that represents that particular event whether it's an actual photo or something that looks along the lines of what to expect.

But this isn’t as simple as storing a string of text in a Database. Images and files generally are complex and need more support to handle them, which is where the Appwrite Storage service comes in.

We’ll first learn how we can read a file from a form’s filepicker input and read the information about an image like the width and height, which will help us to display that image confidently later on. We’ll then see how we can spin up a new Storage Bucket, start to upload our files, store a reference to that image in the related event Document, and even display the images once permissions are configured.

**What you’ll Learn**
- Read a file from a form filepicker input
- Extract metadata like width and height from a selected image
- Create a new Appwrite Storage Bucket
- Configure permissions for a Bucket
- Upload an image file to a Bucket
- Store a file ID and metadata as a reference on a Database Collection Document
- Generate a preview URL for an image file

**Resources**
- [Create a File](https://appwrite.io/docs/client/storage?sdk=web-default#storageCreateFile)
- [Storage](https://appwrite.io/docs/storage)
- [Get File for Preview](https://appwrite.io/docs/client/storage?sdk=web-default#storageGetFilePreview)




Upload an Image File in React to an Appwrite Storage Bucket

We have a list of some pretty amazing events, but two of your event managers just submitted the same event twice! :gasp: Does that mean they have to manually edit the Document’s fields? Likely not… we don’t want people having to manually edit a database. Instead, we can give the option to delete events, so that whether it's a typo or an invalid event, we can quickly get rid of it.

As we can probably expect at this point, the Appwrite SDK not only gives us the flexibility to create, but also delete any Document or File we want. So that means, we can easily clean things up by passing in the ID of the Document or File we want and it's gone! The tricky part though, is how do we make sure we always delete the File associated with the Document so we don’t end up with a bunch of extra unnecessary files getting stored.

In this lesson, we’ll first learn how we can use the Delete Document endpoint to delete any of our Database Collection entries. As we know, there’s a field within that Document that references a file, so we’ll see how we can first use that reference ID to delete the associated File, then continue on with the Document deletion process. And to do all of that, we’ll make sure we have the right permissions configured to avoid making unauthenticated requests!

**What You’ll Learn**
- Delete a Document from a Database Collection by ID
- Delete a File referenced in a Document by ID
- Configure Delete permissions for Documents and Files

**Resources**
- [Delete a Document](https://appwrite.io/docs/client/databases?sdk=web-default#databasesDeleteDocument)
- [Delete a File](https://appwrite.io/docs/client/storage?sdk=web-default#storageDeleteFile)


Delete an Appwrite Document from a Database Collection in React

Up until this point, we’ve given our users free range to do whatever they want in their app. To be clear, we’ve done this intentionally, because we wanted to make things work, but now's the time to lock things down so only logged in users can perform actions in our app. But first, we need some kind of authentication method.

We’ve been able to see how the Appwrite SDK makes working with these different services easy, but authentication takes this to another level. Authentication can be tricky. When we log a user in, they expect to be able to refresh the page and stay logged in, but to do this, we need to store something like an access token somewhere and there are a lot of security implications around how you do this! But Appwrite handles all of this for us, securely storing a cookie, so that any requests we make with our active session will pass that along and handle it for us.

But for now, we just want to log them in, so we can easily get this process started by kicking off a new Magic Link session, verifying it, and getting our active session ready to go for interacting with it.

We’ll start off by kicking an email to our user by creating a Magic Link session. Through this, we’ll want to also pass in the URL of the location we want our actual Magic Link to take them to when returning to the application, which in our instance, is a session page that will include URL parameters to read. Once they’re there, we’ll use URLSearchParams to read the param values and pass them to the verification endpoint to confirm the session, along with some UI updates to give feedback for their actions.

**What You’ll Learn**
- Register a new user or log in an existing user by creating a new Magic Link session
- Verify a new session created from a Magic Link
- Read an email from a form input
- Get parameters from a URL with URLSearchParams
- Show a message or redirecting after successfully submitting a form

**Resources**
- [Create a Magic Link session](https://appwrite.io/docs/client/account?sdk=web-default#accountCreateMagicURLSession)
- [Verify a Magic Link session](https://appwrite.io/docs/client/account?sdk=web-default#accountUpdateMagicURLSession)
- [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams)


Create & Verify New Authenticated Users in React with a Magic Link Session from Appwrite

We’re able to log people in, but how does the application know this? Appwrite can see this if we try to make a request based on the securely stored session cookie, but we need to first know if they’re logged in before trying to submit a request for a particular task, otherwise we’re making a lot of assumptions within our UI.

To work through this, we’ll first get our current Session using the Get Session endpoint, which will not only allow us to pass in a Session’s ID to get the details of that Session, but also pass in the key of “current” which will give us well… the current Session. If they’re logged out, we won’t do anything, but if they’re logged in, we’ll then store that Session in state, which will be our indicator for whether or not we should show Log In or Log Out in our navigation.

What You’ll Learn
- Get the details of the user’s current session (if logged in)
- Dynamically show login and logout links based on authentication state

Resources
- [Or Get the Current Session](https://appwrite.io/docs/client/account?sdk=web-default#accountGetSession)


Get the Current Session from Appwrite of an Authenticated User in React

When logging into any application, the expectation is you can log out. Maybe it’s because you want to prevent someone else using the device from messing with your account, but whatever it is, we ultimately want to destroy the current session both by locally signing out and also letting Appwrite know that the session is no longer active.

The Appwrite SDK has an easy method to handle this where we don’t technically need to even pass in the current session ID, we can just simply tell it we want to delete the current session for the device like we did in the last lesson, and that’s it!

So we’ll see how we can use the Delete Session endpoint to do just that, passing in the “current” key like before to specify we just want to clear the device’s active session, and then clearing local state to re-render the UI and avoid any stale session information from sticking around.

**What You’ll Learn**
- Delete the current session
- Clear local state after deleting a session

**Resources**
- [Delete at Session](https://appwrite.io/docs/client/account?sdk=web-default#accountDeleteSession)



Delete the Current Session in Appwrite to Log Out an Authenticated User

Our authentication system is pretty solid and works well, but if we try to start using it anywhere other than the one spot we’ve used it so far, we’re going to be copying and pasting the same request over and over within the application. On top of that just being a pain to manage, we’ll also be making duplicate, unnecessary requests that just waste time and bandwidth.

React gives us a few options for how we can mitigate this. Particularly, we’ll be looking at the Context API, which will allow us to easily access state in components that are defined in the same tree as whatever component we wrap with that Context, such as the root of the app, meaning all components will be able to access that Context.

In this lesson, we’ll walk through all the bits of how to make this work, which includes creating a new hook where we define that Context and the Provider which will wrap our application. We’ll then define and set up Types for the state that we’ll pass through our context, migrate our auth-related requests to this new hook, and dynamically update our UI to make use of our new hook including our login flow, hiding the Add Event for guests, and even redirect user’s away from pages that require authentication. 

**What You’ll Learn**
- Create a new React hook
- Set up a new instance of Context using createContext
- Define Types for application Context
- Create a Provider that allows us to access our Context globally
- Manage global state with useState and pass it through app with Context
- Request, store, and manage a user’s Session globally
- Dynamically show and hide UI based on global auth state

**Resources**
- [React Context](https://react.dev/learn/passing-data-deeply-with-context)



Share Authentication & Appwrite Session State Globally with React Context

One potential hiccup with our application is the fact that literally anyone can do literally anything in our application. This is… a major security hole! This was expected though, as we wanted to make this thing first work. But now’s the time we lock things down!

Appwrite gives us the ability to set granular permissions where we’re able to define exactly who we want to access and what. In our case, we want anyone to see the events, but we don’t want everyone to create events, only people who are logged in (you can customize this). And we don’t want just anyone logged in (or out) to delete events, we only want Admins or specific users to be able to delete any of the events.

Here we’ll work through configuring our granular permission where we’ll start off with locking down adding events including Documents and Files to only logged in users. Once that’s accomplished, we’ll create a new Team for Admins, which will allow us to designate specific users that we want to be able to give additional access to where in this case, we’ll provide the ability for Admins to delete events.

**What You’ll Learn**
- Define specific permissions to allow only logged in users to Create Documents and Files
- Create a new Team to designate Admins
- Add additional permissions for Admins to delete Documents and Files

**Resources**
- [Permissions](https://appwrite.io/docs/permissions)


Configure Granular Permissions for Restricting Read, Write, and Delete Access in Appwrite

After the previous lesson, our application is now locked down, only allowing users with specific permissions to perform specific actions. Particularly here, we’re interested in our Admins ability to delete events. But we’re left with a problem. Our app currently doesn’t know if someone is an Admin or not, so we just show a Delete button to anyone and let it fail if they’re not. Bummer.

The good news is we can use the Appwrite Get Teams endpoint where we can first look at all the Teams our user is currently included in and try to see if Admin is in that list. This will allow us to tack on some additional information to our global state, which we can take advantage of to dynamically show the Admin-only bits in our app.

In this lesson, we’ll look up all of the Teams for our current user. We’ll look through that list and see if we find a Team object where the ID matches the ID of our Admin team which we can handily find in the Appwrite console. And once we confirm whether or not they’re an Admin, we’ll leave the Delete button hidden, or show it, depending on their access level.

**What You’ll Learn**
- Get a list of the Teams a user is associated with
- Determine if a user is in a Team by its ID
- Dynamically show and hide UI based on access privileges

**Resources**
- [List a user’s Teams](https://appwrite.io/docs/client/teams?sdk=web-default#teamsList)


Get a User’s Team Access & Grant Admin Privileges in Appwrite and React

The “happy path” of our application is pretty buttoned up. If all goes well, they’ll have a good time browsing and potentially create new events, but what happens when all goes wrong? We’re not doing any error handling or catching any exceptions, so they might be stuck with some ugly error or worse, the application might silently fai leaving them totally and utterly confused.

Appwrite exposes their AppwriteException error instance which provides all the information we need for the variety of errors that we may hit when working with Appwrite’s services including a user not being logged in, not having access, or if we accidentally defined the wrong ID somewhere. We can use this information to not necessarily dynamically show the exact details of what failed (though we can), but help explain from an application user’s perspective what went wrong and how they can fix it.

In our Error Handling lesson, we’ll improve our UX by first seeing how we can catch errors that occur when interacting with the Appwrite SDK. We’ll then determine if it is indeed an instance of AppwriteException or a generic error which will allow us to use that information to show specific messages to our users depending on the context of their interaction. We’ll also see some different examples of patterns we can take for how we use that information to show UI, so we have a more manageable way of handling errors throughout our app.

What You’ll Learn
Inspect and use AppwriteExceptions to determine what error occurred
Dynamically display UI based on errors received


Full Stack with React and Appwrite

Instructor

Course Content