Forem: Jake Barnby

Simplify Your Data Management With Relationships

Jake Barnby — Wed, 12 Apr 2023 10:50:58 +0000

Managing collections of data is an essential task for any application, but it can quickly become complex when you need to keep track of the relationships between different collections. For instance, if you have two collections of data, such as movies and reviews, you may need to retrieve all the reviews associated with a particular movie. However, writing complex code to retrieve this data and merge it together manually can be time-consuming and prone to errors.

That's where one of Appwrite’s newest features comes in. Database relationships help you manage the links between your collections of data more easily. With this feature, you can create links between different collections by simply adding a new attribute to them. You can choose from four types of relationships: one-to-one, one-to-many, many-to-one, and many-to-many.

Relationship Types

One to One

A one-to-one relationship means that each record in one collection is associated with only one record in another collection. For example, if you have a collection of users and a collection of profiles, each user can have only one profile, and each profile can belong to only one user.

One to Many

A one-to-many relationship is when each record in one collection can be associated with multiple records in another collection. For instance, if you have a collection of artists and a collection of albums, each artist can have many albums released, but each album can only be released by one artist.

Many To One

In contrast, many-to-one relationships are when multiple records in one collection can be associated with a single record in another collection. Inversely to the previous example, if you have a collection of albums and a collection of artists, many albums can be released by a single artist. While this may seem the same as a one-to-many relationship, it differs once you take the direction into account. A many-to-one relationship that is one-way can be used to represent a relationship that is only seen on the many side.

Many to Many

Finally, many-to-many relationships describe a scenario where multiple records in one collection can be associated with multiple records in another collection. For example, if you have a collection of books and a collection of authors, each book can have multiple authors, and each author can write multiple books.

By understanding the differences between these relationship types, you can choose the best one that suits your application's needs and create a more efficient database management system.

Relationship Directions

Appwrite relationships offer a high degree of flexibility and customization, allowing developers to create various scenarios with the available options. In addition to choosing from the four relationship types, developers can also decide whether the relationship should be one-way or two-way.

One Way

One-way relationships are a type of relationship where only the collection where the relationship attribute was created will see the relationship. For example, suppose a developer creates a one-way relationship between a movies collection and a reviews collection. In that case, the movies collection will have an attribute containing the related reviews, but the reviews collection will not have an attribute containing the related movie. This type of relationship is useful in scenarios where the parent collection holds all the necessary information, and the child collection only needs to access the parent's data.

The movie response:

{
    "$id": "642b9afc785532a807d8",
    "$databaseId": "marvel",
    "$collectionId": "movies",
    "$createdAt": "2023-04-04T03:35:24.493+00:00",
    "$updatedAt": "2023-04-04T03:35:24.493+00:00",
    "$permissions": [

    ],
    "title": "Spiderman",
    "reviews": [
        {
            "$id": "642b9d627d866e646602",
            "$databaseId": "marvel",
            "$collectionId" :"reviews",
            "$createdAt": "2023-04-04T03:45:38.514+00:00",
            "$updatedAt": "2023-04-04T03:45:38.514+00:00",
            "$permissions": [

            ],
            "content": "Great movie"
        }
    ]
}

The review response, notably with no review attribute:

{
     "$id": "642b9d627d866e646602",
     "$databaseId": "marvel",
     "$collectionId": "reviews"
     "$createdAt": "2023-04-04T03:45:38.514+00:00",
     "$updatedAt": "2023-04-04T03:45:38.514+00:00",
     "$permissions": [],
     "content": "Great movie"
}

Two Way

On the other hand, a two-way relationship is a type of relationship where both collections will see the relationship. In the same example, if a two-way relationship is created between the movies and reviews collections, both collections will have attributes containing the related data. This type of relationship is beneficial in scenarios where both the parent and child collections need to access each other's data.

The movie response:

{
     "$id": "642b9afc785532a807d8",
     "$databaseId": "marvel",
     "$collectionId": "movies",
     "$createdAt": "2023-04-04T03:35:24.493+00:00",
     "$updatedAt": "2023-04-04T03:35:24.493+00:00",
     "$permissions": [],
     "title": "Spiderman",
     "reviews": [
          {
               "$id": "642b9d627d866e646602",
               "$databaseId": "marvel",
               "$collectionId": "reviews",
               "$createdAt": "2023-04-04T03:45:38.514+00:00",
               "$updatedAt": "2023-04-04T03:45:38.514+00:00",
               "$permissions": [],
               "content": "Great movie"
          }
     ]
}

The review response, now with the movie attribute:

{
     "$id": "642b9d627d866e646602",
     "$databaseId": "marvel",
     "$collectionId": "reviews",
     "$createdAt": "2023-04-04T03:45:38.514+00:00",
     "$updatedAt": "2023-04-04T03:45:38.514+00:00",
     "$permissions": [],
     "content": "Great movie",
     "movie": {
          "$id": "642b9afc785532a807d8",
          "$databaseId": "marvel",
          "$collectionId": "movies",
          "$createdAt": "2023-04-04T03:35:24.493+00:00",
          "$updatedAt": "2023-04-04T03:35:24.493+00:00",
          "$permissions": [],
          "title": "Spiderman"
     }
}

One-way and two-way relationships offer different advantages and disadvantages, depending on the specific requirements of the application. In some cases, one-way relationships can provide better performance by reducing the amount of data that needs to be stored and accessed. However, two-way relationships can provide more flexibility by allowing both collections to access each other's data.

On Delete Behavior

Managing related data can still be challenging, especially when deleting data. To address this, Appwrite relationships offer three deletion strategies: restrict, cascade, and set null.

Restrict

If you select the restrict option, you won't be able to delete a parent document if it has any related child documents. This option is helpful if you want to ensure that data integrity is maintained and that you don't accidentally delete data that is still relevant.

Cascade

If you choose cascade, deleting a parent document will also delete all related child documents. This option can be helpful if you want to remove all data associated with a particular parent record, such as when you want to delete a user and all their associated data.

Set Null

Finally, the set null option means that deleting a parent document will remove the relationship to the parent document for all of its related children. This can be useful if you want to retain the child's records but simply remove the relationship.

Each of these options has its own use cases, and the choice ultimately depends on your specific application requirements. By providing these different options, Appwrite allows you to manage related data in a flexible and intuitive way, making it easier for you to build complex applications without worrying about data management.

Other Benefits

In addition to simplifying your collection management, database relationships also provide several other benefits. First, they can help to ensure data consistency and integrity by enforcing referential constraints between related collections. This means that you can prevent orphaned documents or other data inconsistencies that might arise if you were to manage the relationships between collections manually. Additionally, using relationships can also improve the performance of your requests and reduce the amount of code you need to write, since you can retrieve related data in a single request rather than having to fetch it separately.

Overall, database relationships are a powerful tool that simplifies your collection management and saves you time and effort. By easily linking your collections and retrieving related data, you can focus on developing your application's core features. Check out the docs for more information as well as the release announcement for details on other awesome new features in the latest version of Appwrite. We encourage you to give it a try today and see how it can benefit your development process!

🚀 Appwrite GitHub
📜 Appwrite Docs
💬 Discord Community

GraphQL vs. REST

Jake Barnby — Thu, 05 Jan 2023 17:22:17 +0000

GraphQL and REST are two different approaches to implementing web APIs that allow clients to access data from a server.

While both approaches have their own advantages and disadvantages, they are often used to solve similar problems and can sometimes be used interchangeably. Today we’ll cover some of the differences between the two.

Requests

One of the key differences between GraphQL and REST is the way that data is accessed. In REST, data is typically organized into a set of resources, each with its own unique URL.

For example, if an API exposes information about users and their addresses, there might be separate URLs for accessing user data and address data, such as:

Get user profile by ID: https://example.com/users/{id}
Get user address by ID: https://example.com/addresses/{id}

To retrieve data, a client would make a request to one of these URLs using an HTTP method such as GET, POST, PUT, or DELETE.

In contrast, GraphQL uses a single endpoint for all data requests. To retrieve data, a client sends a GraphQL query to this endpoint, specifying the data they want to retrieve. The server then responds with the requested data in a JSON object.

Here is an example of a GraphQL query that could be used to retrieve information about a user with a given ID:

query {
    usersGet(id: "abc123") {
        name
        email
        addresses {
            city
            country
        }
    }
}

In this example, the query keyword indicates that we are making a query to the server, meaning no data will be modified, and the user and address fields specify the data we want to retrieve. The id argument allows us to specify which user we want to retrieve data for.

The server will respond with a JSON object containing only the requested data, like this:

{
    "data": {
        "user": {
            "name": "John Doe",
            "email": "johndoe@example.com",
            "addresses": [
                {
                    "city": "New York",
                    "country": "USA"
                },
                {
                    "city": "Houston",
                    "country": "USA"
                }
            ]
        }
    }
}

By comparison, here are examples of REST requests that could be used to retrieve the same information:

GET https://example.com/users/abc123

The server would first respond with a JSON object containing the user data, like this:

{
    "name": "John Doe",
    "email": "johndoe@example.com"
}

To then retrieve the user's addresses, the client would need to make another request to a different URL, like this:

GET https://example.com/users/abc123/addresses

The server would then respond with a JSON object containing the address data, like this:

[
    {
        "city": "New York",
        "country": "USA"
    },
    {
        "city": "Houston",
        "country": "USA"
    }
]

As you can see, the GraphQL approach allows the client to specify the exact data they want to retrieve, while the REST approach requires the client to make multiple requests to different URLs to retrieve the same data.

This can be more efficient for the client, as it allows them to retrieve everything in a single round trip to the server.

Structure

Another key difference between GraphQL and REST is how data is structured on the server.

In REST, the structure of the data is determined by the URL hierarchy and the HTTP methods used to access it. For example, in the REST example above, the user and address data are accessed through different URLs, and the POST method is used to create new addresses.

In GraphQL, the structure of the data is determined by the schema defined on the server. The schema defines the types of data that can be accessed, as well as the fields and relationships between those types. For example, the types for the user and address data might be defined in the schema like this:

type User {
    id: ID!
    name: String!
    email: String!
    addresses: [Address!]!
}

type Address {
    id: ID!
    city: String!
    country: String!
}

These types define the structure of the user and address data respectively. The [] symbols denote a list of the enclosed type, and the ! symbol indicates a non-nullable field.
In addition to the User and Address types, there must always be a Query type, and optionally a Mutation type. These two special types define all queries a client can execute, for example:

type Query {
    userGet(id: String!): User
    addressGet(userId: String!): Address
}

type Mutation {
    userCreate(
        name: String!,
        email: String!
    ): User

    addressCreate(
        userId: String,
        city: String!,
        country: String!
    ): Address
}

With this schema in place, the client can use GraphQL to access and modify the user and address data in a consistent and predictable way. For example, they could use the following mutation to create a new address:

mutation {
    addressCreate(
        userId: "abc123"
        city: "Cleveland"
        country: "USA"
    ) {
        id
        city
        country
    }
}

In this example, the mutation keyword indicates that we are modifying data on the server, and the addressCreate field specifies the data we want to create. The arguments allow us to specify the values for the new address, and the id, city, and country fields specify the data we want to retrieve for the new address. The server would respond with a JSON object containing the newly created address data, like this:

{
    "data": {
        "addressCreate": {
            "id": "def456",
            "city": "Cleveland",
            "country": "USA"
        }
    }
}

If the client did not need the address id, or any other field, it could be excluded from the field selection, and it would not be included in the response.
In a REST API, the client would need to make a POST request to a specific URL to create a new address, like this:

POST https://example.com/addresses

{
    "userId": "abc123",
    "city": ”Cleveland",
    "country": “USA"
}

Efficiency

In some cases, it would be useful to create multiple resources at the same time. GraphQL allows this in a single request with query batching. Given the schema above, you could create multiple addresses for the same user in the same request with the following mutation:

mutation {
    address1: addressCreate(
        userId: "abc123"
        city: "Cleveland"
        country: "USA"
    ) {
        city
    }

    address2: addressCreate(
        userId: "abc123"
        city: "Seattle"
        country: "USA"
    ) {
        city
    }
}

Because we are requesting the result of two addressCreate fields, we need a way to distinguish them in the response data. This mutation uses a concept called aliasing to give different names to two field executions of the same name. Given this query, the server would respond with:

{
    "data": {
        "address1": {
            "city": "Cleveland"
        },
        "address2": {
            "city": "Seattle"
        }
    }
}

To achieve the same result with REST, two consecutive requests would be made to the POST address endpoint.

Errors

In GraphQL, error handling is done using the errors key in the response object. Every response will use a status code of 200 OK, and the server will include any errors that occurred during the query in the errors array. The data object entry for the field that encountered an error will have a null value, and the error object will include the key in the path array. This allows the client to identify any issues that may have occurred and handle them appropriately. For example, if creating an address failed because a user did not exist, the response might look like this:

{
    "data": {
        "addressCreate": null
    },
    "errors": [
        {
            "message": "User does not exist",
            "path": [
                "addressCreate"
            ]
        }
    ]
}

For a REST API, error handling is typically done using HTTP status codes. When an error occurs, the server will include the corresponding status code in the response. The client can use this to determine what type of error has occurred and handle it accordingly, regardless of whether the response includes a more descriptive message.

Overall, the main difference between the two approaches is that GraphQL provides more textual information about the errors that have occurred, while REST relies on standardized HTTP status codes.

Caching

Web caching is a technique used to improve the performance and scalability of web applications by storing frequently accessed data in a cache. This can help reduce the number of requests made to the server and improve the overall response time of the application.

With GraphQL, web caching is typically handled using a technique called "query caching". This involves storing the results of frequently-accessed queries in the cache, and returning the cached results when the same query is made again. This can greatly improve the performance of a GraphQL API, as it reduces the number of times the server has to execute the same query. Implementing a query cache requires a custom implementation which may not be trivial to develop.

In a REST API, web caching is typically handled using HTTP caching headers. These headers can be included in the response from the server to indicate whether and for how long the client can cache the response. The client can then use this information to store the response in a cache and return the cached data when the same request is made again, reducing the number of requests made to the server and improving the overall response time.

Which Do I Choose?

GraphQL is designed to enable clients to access and manipulate data in a more flexible and powerful way than is possible with REST. In particular, GraphQL allows clients to specify exactly which data they need, and the server will return only that data, in a single request. This can make it easier for clients to access and manipulate data and improve the API's performance and scalability.

On the other hand, REST is a more established and widely-used approach to building APIs, and it has a large ecosystem of tools and libraries that support it. This means that it is often easier to get started with REST, and it can be more straightforward to integrate with existing systems and infrastructure.

GraphQL and REST have unique strengths and weaknesses, and the best choice for a particular project will depend on the specific requirements and use cases. It is important to carefully evaluate both options and choose the one best suited to the project's needs.

Learn more

You can use the following resources to learn more and get help:
🚀 Appwrite Github
📜 Appwrite Docs
💬 Discord Community

Appwrite vs. Hasura vs. Apollo

Jake Barnby — Thu, 05 Jan 2023 17:22:14 +0000

The recent release of Appwrite 1.2, featuring GraphQL support, may have piqued the interest of developers curious about how it compares to other solutions.

In this concise overview, we will delve into the features and capabilities of Appwrite and compare it to several other popular GraphQL solutions. By evaluating the pros and cons of each tool, an objective comparison will be provided, giving you a full understanding of the relative strengths and weaknesses of each option and helping you decide which GraphQL solution is the best fit for your project.

Appwrite

Appwrite is an end-to-end backend server for Web, Mobile, Native, or Backend apps packaged as a set of Docker microservices. Appwrite abstracts the complexity and repetitiveness required to build a modern backend API from scratch and allows you to build secure apps faster.

Appwrite’s GraphQL solution offers full coverage of all existing services, allowing you to manage authentication, databases, functions, storage, and more using GraphQL queries and mutations.

Hasura

Hasura is a web service that provides a GraphQL API (and optionally a REST API) for accessing data from one or more sources. It allows you to merge other REST or GraphQL APIs into a single data access hub by federating, composing, or stitching them together.

The service also includes a configurable authorization layer that enables you to set permissions for accessing both data sources and REST/GraphQL API endpoints or resolvers at the schema, table, column, or row level.

Apollo Server

Apollo Server is a popular open-source server-side runtime for executing GraphQL queries. It is designed to be flexible and easy to use, and can be integrated into a variety of environments and architectures.

Built on top of the Express web framework, Apollo Server supports a wide range of features and capabilities. It allows developers to define a GraphQL schema and implement resolvers that specify how data is fetched and modified, and it supports subscriptions, caching, and other advanced features.

Use Cases

It is impossible to draw a direct comparison between these three products, as they are all fulfilling purposes at different levels:

Appwrite requires no configuration, it just works out of the box with all the existing APIs
Hasura requires configuration of data sources, but allows you to work with existing data, and merge from multiple sources if required
Apollo only gives you a server-side runtime, but allows you to develop a fully-custom solution

When deciding which solution is best for a specific project, it is important to consider the needs and requirements of the project, as well as the skills and resources available to the development team.

Appwrite and Hasura may be more suitable for projects that require a pre-configured backend with a range of APIs and services, while Apollo Server may be better suited to projects that require a fully custom solution or have more specialized or specific requirements.

Learn more

You can use the following resources to learn more and get help:

🚀 Appwrite Github
📜 Appwrite Docs
💬 Discord Community

Querying All Appwrite Developers - GraphQL Has Arrived

Jake Barnby — Wed, 28 Dec 2022 08:46:35 +0000

Hot on the heels of two huge releases comes Appwrite 1.2, bringing with it a brand new, highly anticipated service: GraphQL.

Our vision for Appwrite is always to meet developers where they are. Build relying on your knowledge, stack of choice, or preferred APIs.

Today, we take another step in following this vision. We’re happy to introduce an experimental GraphQL API. A new way to integrate with Appwrite and use all the services you already know and love.

In addition to a new API comes a GraphQL explorer, upgraded SDKs, and improvements to the documentation.

GraphQL API

GraphQL is a powerful technology that allows developers to easily and efficiently access data from an API. It provides a flexible and intuitive query language that makes it easy to retrieve exactly the data that an application needs. This eliminates the need for multiple round trips to the server and can reduce the amount of data that needs to be transferred, resulting in faster and more efficient applications.

The Appwrite GraphQL API offers full support for all of Appwrite’s services. This means you can manage your accounts, databases, storage, functions, and more, all via GraphQL queries and mutations.

The GraphQL API is exposed on the route /v1/graphql, all queries and mutations should be sent to this route as JSON, following the GraphQL HTTP request model:

{
  "query": "...",
  "operaiontName": "...",
  "variables": {},
}

The query key should contain the query or mutation you want to execute. operationName and variables are optional fields. operationName should only be included if there are multiple operations in the query.

A mutation to create an account could like this:

mutation {
  accountCreate(
    userId: "unique()"
    email: "team@appwrite.io"
    password: "Team.Appwrite.IO"
  ) {
    _id
    _createdAt
    status
    email
  }

To use variables, and allow re-using a query, the mutation could look like this:

mutation AccountCreate($userId: String!, $email: String!, $password: String!) {
  accountCreate(
    userId: $userId
    email: $email
    password: $password
  ) {
    _id
    _createdAt
    status
    email
  }

With this mutation, the variables parameter also needs to be passed in the request, to fill in the values for userId, email and password:

{
  "userId": "unique()",
  "email": "team@appwrite.io",
  "password": "Team.Appwrite.IO"
}

The mutation is now able to be used across multiple requests, all that would need to be changed are the values of the variables.

GraphQL Explorer

Appwrite GraphQL Explorer is a powerful tool for working with the new GraphQL API. Based on the Altair GraphQL client, it has a user-friendly interface that makes it easy to explore the GraphQL API, even for those new to the technology. It supports all the features of GraphQL, including query variables, fragments, and custom headers, which makes it a very versatile tool.

You can find the instructions to run the GraphQL explorer in this Gist.

Some extra features make it even easier and more enjoyable to use:

Searchable documentation
One-click query generation from documentation
Intelligent auto-complete and error highlighting for queries
Support for multiple tabs and environments

SDK Updates

The Appwrite SDKs have all been updated to support the GraphQL API by including a new service of their own. This can be used to interact with the API in the same way as other SDK services:

import { Client, GraphQL } from "appwrite";

const client = new Client()
   .setEndpoint('https://[HOSTNAME_OR_IP]/v1') // Your Appwrite Endpoint
   .setProject('[PROJECT_ID]');             // Your project ID

const graphql = new GraphQL(client);

const mutation = graphql.mutation({
   query: `mutation {
    accountCreate(
        userId: "unique()",
        email: "team@appwrite.io,
        password: "Team.Appwrite.IO"
    ) {
        _id
        email
    }
   }`
});

mutation.then(response => {
   console.log(response);
}).catch(error => {
   console.log(error);
});

This makes it possible to take advantage of GraphQL regardless of your preferred language or application platform.

Appwrite is agnostic when it comes to client support; this means any other GraphQL client can be freely used for those comfortable with a different product.

Documentation

To keep Appwrite as easy to use as possible as new APIs are added - the documentation underwent an upgrade. There are now dedicated quick-start guides for REST, GraphQL and Realtime, making it easier to get started with any of the available APIs.

To complement this expansion, there are now examples of REST requests and GraphQL queries for all services, so it is easy to see how to interact with Appwrite even if communicating directly over HTTP instead of via one of the many SDKs.

And More

Appwrite 1.2 includes other changes. Check out the changelog here for the full list of new features, bugs fixed and other changes.

Try It Now

We are super excited about releasing the GraphQL API, GraphQL Explorer, and SDK support. This update provides another powerful and intuitive way to access and manipulate Appwrite, and we hope it will greatly improve the developer experience. We encourage all developers to upgrade to this new version and take advantage of the new features. Thank you for your continued support, and we look forward to any feedback.

Learn more

You can use the following resources to learn more and get help:

Appwrite Loves Open Source: Why I Chose To Support Key Promoter X

Jake Barnby — Fri, 14 Oct 2022 02:49:33 +0000

Open-source is at the ❤️ of everything we do at Appwrite, and we want to enable and foster the open-source community that helped us grow to nearly 25,000 stars on GitHub. Open-source projects, though, require a great deal of effort to maintain and grow. We use open-source tools every day to build Appwrite, and we want to help our community. To give back, each Appwrite engineer gets to pick an open-source project for Appwrite to sponsor for one year.

Shortcuts Save Time

I am a big fan of efficiency as a developer; I like concise variable names, shorthand syntax and keyboard shortcuts wherever possible. The problem with keyboard shortcuts is that they are not always intuitive and can be hard to remember. I prefer JetBrains IDEs for development and there are a lot of shortcuts available, trying to learn them by referencing a list is futile.

Enter Key Promoter X: A plugin for JetBrains IDEs that helps to learn keyboard shortcuts from mouse actions while you are working. When you use the mouse on a button inside the IDE, Key Promoter X shows you the keyboard shortcut that you could have used instead.

This provides an easy way to learn how to replace tedious mouse work with keyboard keys and helps to transition to faster, mouse-free development.

I even learned a new shortcut for markdown context while writing this article!

There is also a separate pane provided to show you a list of your top missed shortcuts to help you learn which ones you may want to focus on:

Having these reminders that reinforce the shortcut could dramatically improve the amount of shortcut combinations you can retain.

Learn More About Appwrite

Appwrite is an open-source Backend-as-a-Service (BaaS), packaged as a set of Docker micro-services, to give developers of any background the tools necessary to build modern apps quickly and securely.

Chat with us on Discord, or, Learn more about Appwrite:

Check out Appwrite as the backend for your next web, Flutter, or server-side application. Here are some handy links for more information:

Migrate Firebase Users to Appwrite

Jake Barnby — Wed, 14 Sep 2022 13:18:11 +0000

With the release of Appwrite 1.0, a ton of new features are available. One of these features is the ability to import and export users. This means you can export your user's accounts from services like Firebase, Supabase, and others, then import them into Appwrite. This makes getting started with Appwrite a lot easier if you're coming from another backend as a service.

What is Appwrite?

Appwrite is an open-source, end-to-end backend server for web and mobile developers that allows you to build apps much faster. It abstracts and simplifies everyday development tasks behind REST APIs and tools, helping you build apps faster.

Step 1: Obtain Firebase Password Hash Parameters

The first step is obtaining the required properties from your Firebase project. To do this, head to your project and navigate to the Authentication service. Here you will see a list of your users. In the top right corner of the list, there is a settings menu. Opening this menu will reveal a Password hash parameters option. Clicking this will open a dialog with the information we are looking for.

From this dialog, we need to note down the base64_signer_key and base64_salt_separator. These will be used later when we import users into Appwrite.

Step 2: Export Firebase Users

The next step is to export all of the existing users in the project. There are two ways to do this, using the Firebase CLI directly or using the firebase-tools NodeJS wrapper. Let's first use the CLI and later look at an example script using NodeJS to export and import users. This assumes you already have the CLI installed and have logged in.

We can export users using the following command, ensuring you replace the project ID with your own:

firebase auth:export users.json \
    --project [PROJECT_ID] \
    --format json

This will create a file named users.json with all of the user information for the given project. Looking at the output JSON, we can see that each user has the following structure:

{
    "localId": "7hlgnwk4jth123pv0QWs4I594Op2",
     "email": "user1@appwrite.io",
     "emailVerified": false,
     "passwordHash": "/Q+0ZSsrgG06/T+UAM1osdfkm9wra7MdKN+08nGyVl2HMXzlaA==",
     "salt": "ENsdflkmBkUJw==",
     "createdAt": "1663120692349",
     "disabled": false,
     "providerUserInfo": []
}

We will need the email, passwordHash and salt specifically. We now have everything we need to move these users into Appwrite!

Step 3: Import Users to Appwrite

To import users into Appwrite, we can use any Server SDK to access the Users API. For this example, we will use the NodeJS SDK.

All server SDKs have the same functions and parameter names as listed below.

Newly added functions let you create a user with one of 7 different hashing algorithms. Firebase uses a modified version of the SCrypt algorithm, so we will use the createScryptModifiedUser function to create an Appwrite user from the Firebase one.

Let's look at the signature of this function:

async createScryptModifiedUser(
   userId,
   email,
   password,
   passwordSalt,
   passwordSaltSeparator,
   passwordSignerKey,
   name
)

Going through the function parameters one by one:

userId: The ID to assign to the new user in Appwrite. It can be custom, or you can use the SDK's new ID.unique() function to assign a randomly generated ID.
email: Corresponds to the email value from users.json
password: Corresponds to the passwordHash value from users.json
passwordSalt: Corresponds to the salt value from users.json
passwordSaltSeparator: The base64_salt_separator from the Firebase console
passwordSignerKey: The base64_signer_key from the Firebase console
name: The name to assign to the user. Can be null

Putting this all together, we could import all of the exported users into Appwrite like so:

const json = await fs.readFile('users.json', {encoding: 'utf8'});
const exported = JSON.parse(json).users;

await Promise.all(exported.map(async user => {
   await users.createScryptModifiedUser(
       ID.unique(),
       user.email,
       user.passwordHash,
       user.salt,
       base64SaltSeparator,
       base64Signer,
       null
   );
}));

Once complete, all the exported users can log in to Appwrite with their existing email and password! Even better, the first time the users log in to Appwrite after the import, their passwords will be re-hashed using the more secure Argon2 algorithm.

Automated Process with NodeJS

We can use the firebase-tools node module to automate more of the process. We export and import the Firebase users into Appwrite using node in the following script.

The configuration variables for both Appwrite and Firebase would need to be filled in with the appropriate values before running the script.

This script does not handle Firebase authentication, so you will still need to run firebase login beforehand or modify the script to provide credentials.

const {Client, Users, ID} = require("node-appwrite");
const firebase = require("firebase-tools");
const fs = require('fs/promises');

// Appwrite configuration
const endpoint = 'http://localhost/v1';
const appwriteProjectId = 'YOUR_PROJECT_ID';
const appwriteApiKey = 'YOUR_API_KEY';

// Firebase configuration
const firebaseProjectId = '';
const base64Signer = '';
const base64SaltSeparator = '';

const client = new Client()
   .setEndpoint(endpoint)
   .setProject(appwriteProjectId)
   .setKey(appwriteApiKey)
   .setSelfSigned()

const users = new Users(client);

const migrate = async () => {
   const outfile = 'users.json';
   await firebase.auth.export(outfile, {project: firebaseProjectId, format: 'json'})
   const json = await fs.readFile(outfile, {encoding: 'utf8'});
   const exported = JSON.parse(json).users;

   await Promise.all(exported.map(async user => {
       await users.createScryptModifiedUser(
           ID.unique(),
           user.email,
           user.passwordHash,
           user.salt,
           base64SaltSeparator,
           base64Signer,
           null
       );
   }));
};

migrate()
   .then(r => console.log('Done!'))
   .catch(e => console.log(e));

Check Out Appwrite 1.0 For Much, Much More

That's not all! There are many other new features, fixes and optimizations to make everyone's Appwrite experience the best it can be. For full details of the 1.0 release, you can check out the full changelog on GitHub. If you're upgrading from Appwrite 0.15, be sure to follow our upgrading guide.

Our list of awesome tutorials, videos, and demos keeps growing. Head to the awesome-appwrite repo to check them out.

If you've just discovered Appwrite and want to get started, check out our 30 Days of Appwrite series, where we explain step-by-step everything you need to know to build awesome Appwrite-powered apps.

Come hang out on Discord, follow us on Twitter, Dev, or wherever you find your friendly neighbourhood Appwriter.

Swiftly Awaiting Async Code Using Appwrite

Jake Barnby — Tue, 17 May 2022 16:02:55 +0000

Modern application development with Swift involves a lot of asynchronous (or "async") programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls is required. Using the new concurrency model makes this a lot more natural and less error-prone.

With the Appwrite 0.14 release, the Apple and Swift SDKs have been updated with first-class support for async/await. To understand why this is important, and see how to implement the changes, let's make a comparison between the old and new APIs.

🏚️ The Old Way

Async programming with explicit callbacks (also referred to as closures or completion handlers) has many problems. The most obvious issue is that they make code more difficult to read and maintain. They also make it hard to write testable code. Let's take a look at how some of those problems manifest:

Problem 1: Pyramid of Doom

A sequence of simple asynchronous operations often requires deeply-nested closures:

func getUserProfileImage(userId: String, completion: (Result<ByteBuffer, AppwriteError>) -> Void) {
    let database = Database(self.client)
    let storage = Storage(self.client)

    database.getDocument(collectionId: "profiles", userId: userId) { docResult in
        switch docResult {
        case .success(let document):
            storage.getFileDownload(bucketId: "profiles", fileId: document.data["profileImageId"]) { fileResult in
                switch result {
                case .success(let bytes):
                    completion(.success(bytes))
                }
            }
        }
    }
}

This "pyramid of doom" makes it difficult to read and keep track of where the code is running. In addition, having to use a stack of closures leads to many second-order effects that we will discuss next.

Problem 2: Error Handling

Looking at the above example - we are only handling success cases. What if the user doesn't exist? What if the user has no profile image? Callbacks make error handling difficult and very verbose:

func getUserProfileImage(userId: String, completion: (Result<ByteBuffer, AppwriteError>) -> Void) {
    let database = Database(self.client)
    let storage = Storage(self.client)

    database.getDocument(collectionId: "profiles", userId: userId) { docResult in
        switch docResult {
        case .success(let document):
            storage.getFileDownload(bucketId: "profiles", fileId: document.data["profileImageId"]) { fileResult in
                switch result {
                case .success(let bytes):
                    completion(.success(bytes))
                case .failure(let error):
                    completion(.failure(error))
                }
            }
        case .failure(let error):
            completion(docResult)
        }
    }
}

Problem 3: Missing completion calls or return statements

It's easy to bail-out of the asynchronous operation early by simply returning without calling the completion block. When forgotten, this issue can be very hard to debug:

func getUserProfileImage(userId: String, completion: (Result<ByteBuffer, AppwriteError>) -> Void) {
    let database = Database(self.client)
    let storage = Storage(self.client)

    database.getDocument(collectionId: "profiles", userId: userId) { docResult in
        switch docResult {
        case .success(let document):
            // ...
        case .failure(let error):
            return // <- Bail out early
        }
    }
}

Now if you call getUserProfileImage and an error occurs, the function will never complete and the call site code will be deadlocked. Even when you do remember to call the block, you can still forget to return after that:

func getUserProfileImage(userId: String, completion: (Result<ByteBuffer, AppwriteError>) -> Void) {
    let database = Database(self.client)
    let storage = Storage(self.client)

    database.getDocument(collectionId: "profiles", userId: userId) { docResult in
        switch docResult {
        case .success(let document):
            // ...
        case .failure(let error):
            completion(.failure(error)) // <- No return, execution continues
        }

        doSomethingElse(userId) // <- Executes on error
    }
}

✨ The New Way

Asynchronous functions (async/await) allow asynchronous code to be written as if it were synchronous code. This immediately addresses all the problems described above by allowing programmers to make full use of the same language constructs that are available to synchronous code.

Solution 1: No More Pyramid of Doom

The control flow simply reads from the top down, with no nesting:

func getUserProfileImage(userId: String) async throws -> ByteBuffer {
    let database = Database(self.client)
    let storage = Storage(self.client)
    let document = try await database.getDocument(
        collectionId: "profiles", 
        userId: userId
    )
    let bytes = try await storage.getFileDownload(
        bucketId: "profiles", 
        fileId: document.data["profileImageId"]
    )
    return bytes
}

As you can see, this code is much more readable, concise and easier to reason about, while performing the same operations as before.

Solution 2: Do/catch error handling

Errors can be handled using the do/catch syntax, the same way as synchronous code:

func getUserProfileImage(userId: String) async throws -> ByteBuffer {
    let database = Database(self.client)
    let storage = Storage(self.client)

    do {
        let document = try await database.getDocument(
            collectionId: "profiles", 
            userId: userId
        )
        let bytes = try await storage.getFileDownload(
            bucketId: "profiles", 
            fileId: document.data["profileImageId"]
        )
    } catch {
        throw error
    }

    return bytes
}

Solution 3: Completions and nested returns are gone completely

The solution to the third problem is to now... do nothing. We no longer have to worry about missing completion handler calls or nested returns using async/await code.

🔮 Future Possibilities

Async code has the potential to change how we develop apps with Swift. Overall, code will become much more readable and robust, with less effort required to implement (increasingly) common async patterns. I am excited to see what developers can create with async/await.

📚 Resources

You can use the following resources to learn more and get help.

Almost Netflix: An iOS Netflix Clone built with Appwrite

Jake Barnby — Tue, 08 Feb 2022 09:52:44 +0000

Welcome to the fourth post in our Almost Netflix series! We'll be building upon the project setup and build another frontend for our Netflix Clone! In this post, we will take a closer look at building the clone using iOS. In the next post of this series, we'll be building frontend for Android!

This one's all about iOS, so let's get started!

It would be impossible to write every piece of code in this article 😬 you will read about all essential concepts, components, and communication with Appwrite. Still, if you want to check out every corner of our Almost Netflix for iOS, you can check out the GitHub Source Code that contains the whole app.

🤔 What is Appwrite?
Appwrite is an open source backend-as-a-service that abstracts all the complexity involved in building a modern application by providing you with a set of REST APIs for your core backend needs. Appwrite handles user authentication and authorization, databases, file storage, cloud functions, webhooks, and much more! If anything is missing, you can extend Appwrite using your favorite backend language.

📃 Requirements

In order to continue with this tutorial, you will need the following:

Access to an Appwrite project or permission to create one. If you don't already have an Appwrite instance, you can install it following our official installation guide.
Setup Appwrite project following our Almost Netflix server setup guide
Access to XCode 12 or newer. Find more about Xcode here.
Know the basics of iOS development and Swift UI

🛠️ Create iOS project

We will start by creating a new project. Open Xcode and select Start New Project. On the next screen select iOS -> App, then click Next.

On the next screen, give your project a name, enter an organization id and for the interface, select SwiftUI with language set to Swift, then click next.

On the next screen, select the folder where you want to save your new project and click create. This will create a new project and open it in Xcode. You should now see the following screen.

↪️ Dependencies

We will start by adding dependencies. For this project we need two packages. First the Appwrite SDK and then Kingfisher image package for displaying images from URL. In order to add a package, go to File -> Add Packages

In the dialog box that appears, tap the top right search icon and type the following GitHub URL for the SDK https://github.com/appwrite/sdk-for-apple and hit Enter. You should see the sdk-for-apple package listed.

Now select the sdk-for-apple package and on the right side, select dependency rule as Up to major version and use version 0.3.0 for the latest SDK. Now click on the Add Package button. Xcode will download the Appwrite Apple SDK along with its dependencies and will add it to your project.

Make sure the proper target is selected in the Add to target in the dialog as shown above, then click Add Package button. The package should successfully be added to your project. Now following the same process, this time search for the Kingfisher package using the GitHub URL as the following https://github.com/onevcat/Kingfisher.

Now that we have all our dependencies, we will create an AppwriteService class and initialize the Appwrite client, database and authentication services. Let's start. First add a new Swift file and name it AppwriteService.swift containing the following:



class AppwriteService {
    let client: Client
    let database: Database
    let account: Account
    let storage: Storage
    let avatars: Avatars

    static let shared = AppwriteService()

    init() {
        client = Client()
            .setEndpoint("https://YOUR_ENDPOINT")
            .setProject("PROJECT_ID")
            .setSelfSigned() // Do not use in production

        database = Database(client)
        account = Account(client)
        storage = Storage(client)
        avatars = Avatars(client)
    }
}

Using the above code, we are initializing our client and database, account, storage and avatars services. Replace YOUR_ENDPOINT with your own endpoint and PROJECT_ID with your own project ID. Now that we have setup our Appwrite client and services, we will start implementing authentication in our application.

🔐 Authentication

We will start by creating basic views that are required to implement the authentication flow. Let's start with login view. First create a new SwiftUI View file and name it LoginView.swift. The full view definition can be found here, for now we will focus on the button actions, where they defer to a view model we will create later:



    @State private var email = ""
    @State private var password = ""  
    @EnvironmentObject var authVM: AuthVM

    var body: some View {
        VStack {
            ...

            Button("Login") {
                authVM.login(email: email, password: password)
            }

            ...
        }
    }
}

Create a similar file named SignupView.swift and update with the full view from here. This view is largely the same but calls a different method in our AuthVM when the Sign Up button is clicked.

We now need a view that we can use to switch between login and sign up. Create a new file called TitleView.swift. Here we will focus on the navigation aspect:



import Foundation
import SwiftUI

struct TitleView: View {

    @State private var selection: String? = nil

    var body: some View {
        NavigationView {
            VStack {

                ...

                NavigationLink(destination: LoginView(), tag: "Sign In", selection: $selection) {}
                NavigationLink(destination: SignupView(), tag: "Sign Up", selection: $selection) {}

                Button("Sign In") {
                    self.selection = "Sign In"
                }

                Button("Sign Up") {
                    self.selection = "Sign Up"
                }

                ...
            }
        }
    }
}

Here we use navigation links inside a navigation view to navigate to sign in or sign up. When a user taps one of the buttons, the selection state variable is set. This way, if we were to add more buttons, we only need to add new tags, not a new state variable for each button.

We now have a nice title view that navigates to either login or sign up that looks like this:

Now we need a view to navigate to on successful sign in or sign up. Create another file named HomeView.swift and update with the following code for now, to simply create a dummy home page to make sure the auth flow is complete and correct.



import SwiftUI

struct HomeView: View {

    var body: some View {
        NavigationView {
            ZStack {
                Color(.black).ignoresSafeArea()
            }
        }
    }
}

We also need a view that will display either a splash UI, login UI or the home page based on authentication state. Let's create a file named MainView.swift and update with the following code.



import SwiftUI

struct MainView: View {

    @EnvironmentObject var authVM: AuthVM

    var body: some View {
        Group {
            if !authVM.checkedForUser {
                SplashView()
            } else if authVM.user != nil {
                HomeView().environmentObject(MoviesVM(userId: authVM.user!.id))
            } else {
                TitleView()
            }
        }
    }
}

Now that we have all the views necessary for authentication flow, we will create a view model that will handle the authentication logic. Create a new swift file and name it AuthVM.swift. Inside the file create the following class.



class AuthVM: ObservableObject {
    @Published var checkedForUser = false
    @Published var error: String?
    @Published var user: User?
}

We also have defined three variables that will help us track and display the authentication state, error and user's details. Now let's add a function that will help us create an account. Add the following to the AuthVM class.



func create(name: String, email: String, password: String) {
    error = ""
    AppwriteService.shared.account.create(userId: "unique()", email: email, password: password, name: name) { result in
        switch result {
        case .failure(let err):
            DispatchQueue.main.async {
                print(err.message)
                self.error = err.message
            }
        case .success:
            self.login(email: email, password: password)
        }
    }
}

Above, we have a create method that accepts name, email and password and creates a new account using Appwrite's account service. Upon successful creation of an account, we are also calling login method to create session for the user. Let us now add the following login function to our AuthVM.



public func login(email: String, password: String) {
    error = ""
    AppwriteService.shared.account.createSession(email: email, password: password) { result in
        switch result {
        case .failure(let err):
            DispatchQueue.main.async {
                self.error = err.message
            }
        case .success:
            self.getAccount()
        }
    }
}

The login function accepts an email and password and creates a session using Appwrite's account service. Once a session is created, we call the getAccount function to get the details of the current user. Next, let us add the getAccount method that will get the user's account and help us check whether the user is logged in.



private func getAccount() {
    error = ""
    AppwriteService.shared.account.get() { result in
        DispatchQueue.main.async {
            self.checkedForUser = true

            switch result {
            case .failure(let err):
                self.error = err.message
                self.user = nil
            case .success(let user):
                self.user = user
            }

        }
    }
}

To get the user account we are simply calling the get function of the Appwrite's account service. Upon success we are setting the user property with the received user details. Finally let us add an initializer method to the AuthVM class that will call getAccount so that user's authentication state is checked on application start-up.



init() {
    getAccount()
}

That's it for authentication! Our application will now show a splash screen until we have checked if the user is logged in, if they are, they will be shown the home screen, otherwise the login screen.

🎬 Movies Page

Let us head back to the HomeView.swift file and start creating our movie carousel views. We need to create a horizontal scroll view within a vertical scroll view. The vertical scroller will iterate movie categories and the horizontal scrollers will iterate the movies within each category. We will first add the vertical scroll to our HomeView as follows:



    ScrollView(.vertical, showsIndicators: false) {
        if(moviesVM.featured != nil) {
            MovieItemFeaturedView(
                movie: moviesVM.featured!,
                isInWatchlist: moviesVM.watchList.contains(moviesVM.featured!.id),
                onTapMyList: {
                    self.onTapMyList(moviesVM.featured!.id)
                }
            )
        } else if(!((moviesVM.movies["movies"] ?? []).isEmpty)) {
            let movie = (moviesVM.movies["movies"]!).first!

            MovieItemFeaturedView(
                movie: movie,
                isInWatchlist: moviesVM.watchList.contains(movie.id),
                onTapMyList: {
                    self.onTapMyList(movie.id)
                }
            )
        }

        VStack(alignment: .leading, spacing: 16) {
            ForEach(appwriteCategories) { category in
                MovieCollection(title: category.title, movies: moviesVM.movies[category.id] ?? [])
                    .frame(height: 180)
            }
        }.padding(.horizontal)
    }

Let's break that down. Inside our scroll view, we first check if we have a featured movie. If we do, this is shown at the top of the page using a MovieItemFeaturedView that we will add later.

Below the featured movie, we have a vertical stack that iterates some pre-defined categories and displays a MovieCollectionView for each.

Now we can create our subviews. First, create a new file called MovieItemFeaturedView.swift and add the following:



import SwiftUI
import Kingfisher

struct MovieItemFeaturedView: View {
    @State private var isShowingDetailView = false

    let movie: Movie
    let isInWatchlist: Bool
    let onTapMyList: () -> Void

    var body: some View {
        ZStack{
            KFImage.url(URL(string: movie.imageUrl))
                .resizable()
                .scaledToFill()
                .clipped()

            VStack {
                HStack {
                    ...

                    Button {
                        onTapMyList()
                    } label: {
                        VStack {
                            Image(systemName: self.isInWatchlist ? "checkmark" :"plus")
                            Text("My List")
                        }
                    }

                    NavigationLink(destination: MovieDetailsView(movie: movie), isActive: $isShowingDetailView) { EmptyView() }

                    Button {
                        self.isShowingDetailView = true
                    } label: {
                        VStack {
                            Text("Info")
                        }
                    }
                }
            }
        }
    }
}

Our featured movie is now set-up, so let us move on to the MovieCollectionView. Create a new filed called MovieCollectionView.swift and update with the following code:



    ScrollView(.horizontal, showsIndicators: false) {
        HStack {
            ForEach(movies) { movie in
                MovieItemThumbnailView(movie: movie)
                    .frame(width: itemWidth, height: itemHeight)
            }
        }
        .frame(height: frameHeight)
    }

Here we have a scroll view, with a horizontal stack inside, which iterates each movie within the given collection and displays a MovieItemThumbnailView for each. Now we can create a new file, MovieItemThumbnailView.swift and add the following:



    NavigationLink (destination: MovieDetailsView(movie: movie)) {
        KFImage.url(URL(string: movie.imageUrl))
            .resizable()
            .scaledToFit()
            .cornerRadius(4)
    }

Here our image is nested inside a navigation link, so when the image is clicked, our app will navigate to the movie detail view. That's it for our movie feed. We now have a nested scroll view displaying collections of movies by category. Now we need to create a detail view for individual movies.

🕵️ Detail Page

Now we can define our movie detail view. Create a new file called MovieDetailsView.swift. Inside the details view we have a button that toggles adding the current movie to a users watchlist:



    Button {
        self.addToMyList()
    } label: {
        VStack {
            Image(systemName: moviesVM.watchList.contains(movie.id) ? "checkmark" : "plus")
            Text("My List")
        }
        .padding()
    }

    func addToMyList() -> Void {
        moviesVM.addToMyList(movie.id)
    }
}

Now we need to add the MovieGridView, which shows similar movies to the one displayed on the detail page. Let's add that now as a new file called MovieGridView.swift:



    LazyVGrid(columns: [GridItem(.adaptive(minimum: 100))], alignment: .leading, spacing: 4) {
        ForEach(movies) { movie in
            MovieItemThumbnailView(movie: movie)
        }
    }

Our movie detail view will now look like the following:

⚙️ Movies ViewModel

We need to add the View Model we are using to fetch movies and publish them to the UI. This class contains most of the logic for managing the movie feed as well as the currently logged in user's watchlist. Add a new file, MoviesVM.swift with the following:



class MoviesVM: ObservableObject {
    @Published var featured: Movie?
    @Published var movies: [String:[Movie]] = [:]
    @Published var watchList: [String] = []

    let userId: String

    init(userId: String) {
        self.userId = userId
        getMovies()
        getFeatured()
    }

    public func getMyWatchlist() {
        AppwriteService.shared.database.listDocuments(
            collectionId: "movies",
            queries: [
                Query.equal("$id", value: watchList)
            ]
        ) { result in
            DispatchQueue.main.async {
                switch result {
                case .failure(let err):
                    print(err.message)
                case .success(let docs):
                    self.movies["watchlist"] = docs.convertTo(fromJson: Movie.from)
                }
            }
        }
    }

    func addToMyList(_ movieId: String) {
        if(self.watchList.contains(movieId)) {
            removeFromMyList(movieId)
        } else {    
            AppwriteService.shared.database.createDocument(collectionId: "watchlists", documentId: "unique()", data: ["userId": userId, "movieId": movieId, "createdAt": Int(NSDate.now.timeIntervalSince1970)], read: ["user:\(userId)"], write: ["user:\(userId)"]){ result in
                DispatchQueue.main.async {
                    switch result {
                    case .failure(let err):
                        print(err.message)
                    case .success(_):
                        self.watchList.append(movieId)
                        self.getMyWatchlist()
                        print("successfully added to watchlist")
                    }

                }
            }
        }
    }

    func removeFromMyList(_ movieId: String) {
        AppwriteService.shared.database.listDocuments(collectionId: "watchlists", queries: [
                Query.equal("userId", value: userId),
                Query.equal("movieId", value: movieId)
            ], limit: 1) { result in
                switch result {
                case .failure(let err):
                    print(err.message)
                case .success(let docList):
                    AppwriteService.shared.database.deleteDocument(collectionId: "watchlists", documentId: docList.documents.first!.id) {result in
                        DispatchQueue.main.async {
                            switch result {
                            case .failure(let err):
                                print(err.message)
                            case .success(_):
                                let index = self.watchList.firstIndex(of: movieId)
                                if(index != nil) {
                                    self.watchList.remove(at: index!)
                                    self.getMyWatchlist()
                                    print("removed from watchlist")
                                }
                            }
                        }
                    }
                }
            }
    }

    func isInWatchlist(_ movieIds: [String]) {
        AppwriteService.shared.database.listDocuments(
            collectionId: "watchlists",
            queries: [
                Query.equal("userId", value: userId),
                Query.equal("movieId", value: movieIds)
            ]
        ) { result in
            DispatchQueue.main.async {
                switch result {
                case .failure(let err):
                    print(err.message)
                case .success(let docList):
                    let docs = docList.convertTo(fromJson: Watchlist.from)
                    for doc in docs {
                        self.watchList.append(doc.movieId)
                    }
                    if(docs.count > 1) {
                        self.getMyWatchlist()
                    }
                }

            }
        }
    }

    private func getFeatured() {
        AppwriteService.shared.database.listDocuments(
            collectionId: "movies",
            limit: 1,
            orderAttributes: ["trendingIndex"],
            orderTypes: ["DESC"]
        ) { result in
            DispatchQueue.main.async {
                switch result {
                case .failure(let err):
                    print(err.message)
                case .success(let docs):
                    self.featured = docs.convertTo(fromJson: Movie.from).first
                    if(self.featured != nil) {
                        self.isInWatchlist([self.featured!.id])
                    }
                }

            }
        }
    }

    private func getMovies() {
        appwriteCategories.forEach {category in
            AppwriteService.shared.database.listDocuments(collectionId: "movies", queries: category.queries, orderAttributes: category.orderAttributes, orderTypes: category.orderTypes) { result in
                DispatchQueue.main.async {
                    switch result {
                    case .failure(let err):
                        print(err.message)
                    case .success(let docs):
                        self.movies[category.id] = docs.convertTo(fromJson: Movie.from)
                        self.isInWatchlist(docs.documents.map { $0.id });
                    }

                }
            }
        }
    }
}

🔖 Watchlist Page

Bonus points: We have also implemented a Watchlist feature. To add this, we need to another new view, WatchlistView.swift:



    ScrollView(.vertical, showsIndicators: false) {
        if(!(moviesVM.movies["watchlist"] ?? []).isEmpty) {
            MovieGridView(movies: moviesVM.movies["watchlist"] ?? [])
        } else {
            Text("You have no items in your watchlist")
                .foregroundColor(Color.white)
        }
    }

This view will get all the movies in the users watchlist and display them in our previously created MovieGridView.

👨‍🎓 Conclusion

Ta-da! We have (almost) cloned Netflix, Swiftly and easily with Appwrite as our backend! To become part of the Appwrite community, you can join our Discord server. We look forward to seeing what you build and who you are (when you join our discord!)

With each Appwrite release amazing new features are being added and as they are, we will return to our Netflix clone to keep it growing!

🔗 Learn more

Swift 101: Building a Library with Swift Package Manager

Jake Barnby — Thu, 21 Oct 2021 07:39:31 +0000

The Swift Package Manager, or SwiftPM, is included with Swift 3.0 and above. Initially, it was only available for server-side or command line Swift projects. Since the release of Swift 5 and Xcode 11, SwiftPM is compatible with the Apple ecosystem for creating apps. This is great news because packages make it easier to divide your code into reusable, logical groups you can easily share across projects, or even with the entire world.

📦️ Modules

Before looking at packages, we first need to understand modules. Swift organises code into modules. Each module defines a namespace and which parts of the code can be used from outside the module. You can define all of your code in a single module, or break it up into multiple which can depend on each other. Using modules lets you easily build on your own re-usable code, or others code.

🎁 Packages

So what is a Swift package? A package is a collection of Swift source code files as well as a manifest file called Package.swift, that defines various properties about the package, such as its name, the products it produces, any dependencies it has, and the targets it is built up of.

🦴 Anatomy of a Package

Products define the libraries and executables produced by a package. A library is simply a collection of files, for use as a dependency by other Swift code. An executable is a package that can be run, such a web server.
Dependencies are other Swift Packages you want to use code from, within your package.
Targets are what defines the module(s) that a package contains and that other packages can import. Targets define their own dependencies and can depend on other targets the package, or products from packages that this package depends on.

⚙️ Creating a Swift Package

This tutorial assumes you already have Swift installed. You can check by running swift --help from your terminal.

Creating a Swift Package from the command line is easy, and can be completed with one simple command from the directory you want to create your package in. For this example we'll start with a directory named FooPackage.

$ mkdir FooPackage
$ cd FooPackage

FooPackage$ swift package init --type=library

That’s it! There’ll be some output detailing the files created for your new package. You should see:

1 source file created inside a Sources directory
1 test source file inside a Tests directory
A Package.swift manifest file at the root level
A README.md file at the root level
A .gitignore file at the root level

Of these files, only the single file in the Sources directory and the manifest file are required for the package to build. This means you could easily create your own package by manually creating these two files as well.

By default, the Sources directory must contain all source code for the package, but you can use sub-directories to define sub-modules, if they are also defined as separate targets in your manifest file. Let's take a look at the generated Package.swift for the new package to see the pieces we've discussed so far:

// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "TestPackage",
    products: [
        .library(
            name: "FooPackage",
            targets: ["FooPackage"]),
    ],
    dependencies: [
    ],
    targets: [
        .target(
            name: "FooPackage",
            dependencies: [          
            ]
        )
        .testTarget(
            name: "FooPackageTests",
            dependencies: [     
                "FooPackage"     
            ]
        )
    ]
)

Here you can see that our package defines one library, TestPackage, as well as one target of the same name, and one test target, with depends on the module target.

🥇 The first build

Now that the package has been created, let’s build it for the first time with the build command:

$ swift build

Because the package has no dependencies or code yet, this should complete almost instantly, displaying “Build Completed!” on success.

➕ Adding dependencies

Let's add a dependency and some code. Adding dependencies with SwiftPM is easy as you can use git URL's directly. We can add the following to our Package.swift top level dependencies block to allow us to the Appwrite Swift SDK in our library:

.package(name: "Appwrite", url: "https://github.com/appwrite/sdk-for-swift", from: "0.1.0")

This declares that our package will pull in the code from the Appwrite module in the sdk-for-swift repository on GitHub, from the tag 0.1.0 and allow us to add it to our targets dependencies as follows:

.target(
    name: "FooPackage",
    dependencies: [ 
        "Appwrite"    
    ]
)

Here we added Appwrite, as this is the name of the library we're using from the sdk-for-swift repository.

Let's take a look at the full manifest file with the new dependency added:

// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "FooPackage",
    products: [
        .library(
            name: "FooPackage",
            targets: ["FooPackage"]),
    ],
    dependencies: [
        .package(name: "Appwrite", url: "https://github.com/appwrite/sdk-for-swift", from: "0.1.0")
    ],
    targets: [
        .target(
            name: "FooPackage",
            dependencies: [    
                "Appwrite"
            ]
        )
        .testTarget(
            name: "FooPackageTests",
            dependencies: [     
                "FooPackage"     
            ]
        )
    ]
)

Since we've changed the dependencies of our package, we need to resolve them. This will happen automatically the first time you run swift build with a new dependency, but if you manually update a version, you'll need to manually resolve the new version. This can be done by running:

$ swift package resolve

This will update the Package.resolved to contain the version metadata about the Appwrite module we just added.

What's going on here?

Swift Package Manager uses a lockfile system similar to package.lock for NPM and composer.lock for Composer. This comes in the form of a file called Package.resolved, which contains metadata about the packages dependencies versions, as well as their transitive dependencies. When you run swift build and the dependencies are fetched, the versions from the Package.resolved file will be used if found.

Once resolved, we can build our package with swift build again. This time we'll see the sdk-for-swift repository pulled into the build checkouts, as well as built with the rest of the library.

📥️ Adding library code

Time to add some code. Let's open up the source file created earlier as Sources/FooPackage/FooPackage.swift and update with the following:

import Appwrite

struct FooPackage {

    static let client = Client()
    static let account = Account(client)

    public static func login(
        endpoint: String,
        projectId: String,
        email: String,
        password: String,
        completion: @escaping (Result<Session, AppwriteError>) -> Void
    ) {
        client
            .setEndpoint(endpoint)
            .setProject(projectId)

        account.createSession(
            email: email,
            password: password,
            completion: completion
        )
    }
}

We now have a login function! We just need to deploy the package, and we'll be able to use the login function from any other package or Apple app.

🧑‍💻 Deploying the package

Fortunately deploying packages with Swift Package Manager is very easy. As the packages are Git based, all you need to do is push your changes to your default branch and create a tag for your release:

$ git init
$ git add .
$ git remote add origin [GitHub Repository URL]
$ git commit -m "Initial Commit"
$ git tag 1.0.0
$ git push origin main --tags

📥️ Using as a dependency

Using the same method we used earlier to add the Appwrite Apple SDK as a dependency, we can now add the newly deployed package as a dependency of a second package:


    ...

    dependencies: [
        .package(name: "FooPackage", url: "https://github.com/[YOUR GITHUB USERNAME]/[YOUR GITHUB REPOSITORY]", from: "1.0.0")
    ],
    targets: [
        .target(
            name: "FooPackage",
            dependencies: [    
                "FooPackage"  
            ]
        )
    ]

    ...

)

🏗️ Using the dependency

With the package added as a dependency, we can now use the function we defined earlier anywhere in the second package:

import FooPackage

FooPackage.login(
    endpoint: "http://localhost/v1",
    projectId: "6bfgh45fng3",
    email: "test@test.test",
    password: "password"
) { result in 
    ...
}

🔽 Updating your package

To update your package, the process is the same as deploying the initial version. You just need to push your changes to the default branch and a new version tag to go with.

✅ That's it!

You've now created, deployed, used and updated your very own Swift Package! Packages are a great way to re-use code and share your creations with the world. Looking forward to seeing what new packages come next for Swift!

📚️ Resources

Getting started with Appwrite's Apple SDK and UIKit

Jake Barnby — Tue, 19 Oct 2021 12:10:29 +0000

One of the major highlights of Appwrite 0.11 is the official support for iOS, macOS, tvOS and watchOS. We've also released a brand-new Apple SDK to go alongside it! 😉

In this tutorial, we'll learn to set up Appwrite's Apple SDK, interact with Appwrite's Accounts API and also learn to set up OAuth Logins in your App. Let's get started!

We'll use UIKit in this tutorial, if you're using SwiftUI, check out this tutorial instead.

📝 Prerequisites

At this stage, we assume that you already have an Appwrite instance up and running. If you do not have Appwrite setup yet, you can follow the super easy installation step over at appwrite.io. It's not a typo. There really is only 1 step!

You should have also set up an OAuth provider with Appwrite to be able to follow the OAuth section of this tutorial. You can learn to set up OAuth providers in Appwrite with this tutorial.

🛠️ Create a new App Project

Create a new iOS > App in Xcode, selecting Storyboard for Interface and UIKit App Delegate for Life Cycle.

With the app created, now is also a good time to add our iOS, macOS, watchOS or tvOS app as a platform in the Appwrite Console. Head over to your project file and find your Bundle Identifier. It should look something like io.appwrite.Appwrite-iOS.

In your Appwrite console, click on Add Platform and select a New Apple App, then one of the iOS, macOS, watchOS or tvOS tabs. Give your app a name, add the bundle identifier and click Register.

Once this is complete, it's time to head back to our Xcode project add our dependencies.

👷 Setup Appwrite's Apple SDK

Using Xcode

The Appwrite Apple SDK is available via Swift Package Manager. In order to use the Appwrite Apple SDK from Xcode, select File > Swift Packages > Add Package Dependency. In the dialog that appears, enter the Appwrite Apple SDK package URL and click Next.

Once the repository information is loaded, add your version rules and click Next again.

On the final screen, make sure Appwrite is selected to add to your target as a library.

Using Swift Package Manager

Add the package to your Package.swift dependencies:

    dependencies: [
        .package(url: "https://github.com/appwrite/sdk-for-apple", from: "0.1.0"),
    ],

Then add it to your target:

    targets: [
        .target(
            name: "[YourAppTarget]",
            dependencies: [
                .product(name: "Appwrite", package: "sdk-for-apple")
            ]
        ),

Build your project and if there are no errors, we're ready to proceed!

🏗️ Create the ViewController

Create a new file ViewController.swift and add the following. This defines our controller for our storyboard and sets up our button click listeners that will call the ViewModel.

import Appwrite
import NIO
import UIKit

class ViewController: UIViewController {

    @IBOutlet weak var text: UITextView!
    @IBOutlet weak var register: UIButton!
    @IBOutlet weak var loginButton: UIButton!
    @IBOutlet weak var logOutButton: UIButton!
    @IBOutlet weak var getUserButton: UIButton!
    @IBOutlet weak var loginWithFacebook: UIButton!

    let client = Client()
        .setEndpoint("http://localhost/v1")
        .setProject("613b18dabf74a")
        .setSelfSigned()

    lazy var account = Account(client)

    var picker: ImagePicker?

    required init?(coder: NSCoder) {
        super.init(coder: coder)
    }

    @IBAction func register(_ sender: Any) {
        account.create(email: "tester@appwrite.io", password: "password") { result in
            var string: String = ""

            switch result {
            case .failure(let error): string = error.message
            case .success(let user): string = user.email
            }

            DispatchQueue.main.async {
                self.text.text = string
            }
        }
    }

    @IBAction func login(_ sender: Any) {
        account.createSession(email: "tester@appwrite.io", password: "password") { result in
            var string: String = ""

            switch result {
            case .failure(let error): string = error.message
            case .success(let session): string = session.userId
            }

            DispatchQueue.main.async {
                self.text.text = string
            }
        }
    }

    @IBAction func loginWithFacebook(_ sender: UIButton) {
        // To be added later.
    }

    @IBAction func getUser(_ sender: Any) {
        account.get { result in
            var string = ""

            switch result {
            case .failure(let error): string = error.message
            case .success(let user): string = user.email
            }

            DispatchQueue.main.async {
                self.text.text = string
            }
        }
    } 

    @IBAction func logOut(_ sender: Any) {
        account.deleteSession(sessionId: "current") { result in
            var string = ""

            switch result {
            case .failure(let error): string = error.message
            case .success(let success): string = String(describing: success)
            }

            DispatchQueue.main.async {
                self.text.text = string
            }
        }
    } 
}

Our ViewController has 4 state functions:

register - click handler for the Signup Button
login - click handler for the Login Button
logout - click handler for the Logout Button
getUser - click handler for the Get User Button

You should now be able to run your app and create users, login, logout and get information about the currently logged-in user!

🔐 Adding OAuth Support

You would have noticed that we have a Login With Facebook button in our UI, but it doesn't do anything yet; let's now add Facebook OAuth to our app!

The first step is to add a callback URL scheme to our Info.plist file.

<key>CFBundleURLTypes</key>
<array>
<dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLName</key>
    <string>io.appwrite</string>
    <key>CFBundleURLSchemes</key>
    <array>
        <string>appwrite-callback-[PROJECT-ID]</string>
    </array>
</dict>
</array>

Make sure you replace the Project ID in appwrite-callback-[PROJECT-ID] with your own.

Next we need to add a hook to save cookies when our app is opened by its callback URL. To do this, add the following function to your SceneDelegate.swift. If you have already defined this function, you can just add the contents below.

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        guard let url = URLContexts.first?.url,
            url.absoluteString.contains("appwrite-callback") else {
            return
        }
        WebAuthComponent.handleIncomingCookie(from: url)
    }

The last step is to invoke the SDK function createOAuth2Session from AccountViewController.swift from our existing button's action.

    @IBAction func loginWithFacebook(_ sender: UIButton) {
        account.createOAuth2Session(
            provider:"facebook",
            success: "https://demo.appwrite.io/auth/oauth2/success",
            failure: "https://demo.appwrite.io/auth/oauth2/failure") { result in
                var string: String = ""

                switch result {
                case .failure(let error): string = error.message
                case .success(let response): string = response.description
                }

                DispatchQueue.main.async {
                    self.text.text = string
                }
            }
    }

Re-run your app and you should now be able to trigger your Facebook OAuth Flow! With that, you now know how to interact with Appwrite's Accounts API in your iOS, macOS, tvOS and watchOS apps!

We've built a complete app that interacts with all of Appwrite's APIs, which you can find over at our Github Repo. If you'd like to learn more about Appwrite or how Appwrite works under the hood, we've just curated all the resources for you during 30 Days of Appwrite.

✨️ Credits

Hope you enjoyed this article! We love contributions and encourage you to take a look at our open issues and ongoing RFCs.

If you get stuck anywhere, feel free to reach out to us on our friendly support channels run by humans 👩‍💻.

Here are some handy links for more information:

Getting started with Appwrite's Apple SDK and SwiftUI

Jake Barnby — Mon, 18 Oct 2021 18:21:59 +0000

One of the major highlights of Appwrite 0.11 is the official support for iOS, macOS, tvOS and watchOS. We've also released a brand-new Apple SDK to go alongside it! 😉

In this tutorial, we'll learn to set up Appwrite's Apple SDK, interact with Appwrite's Accounts API and also learn to set up OAuth Logins in your App. Let's get started!

We'll use SwiftUI in this tutorial, if you're using UIKit, check out this tutorial instead.

📝 Prerequisites

You should have also set up an OAuth provider with Appwrite to be able to follow the OAuth section of this tutorial. You can learn to set up OAuth providers in Appwrite with this tutorial.

🛠️ Create a new App Project

Create a new Multiplatform > App in Xcode.

Once this is complete, it's time to head back to our Xcode project and add our dependencies.

👷 Setup Appwrite's Apple SDK

Using Xcode

Once the repository information is loaded, add your version rules and click Next again.

On the final screen, make sure Appwrite is selected to add to your target as a library.

Using Swift Package Manager

Add the package to your Package.swift dependencies:



    dependencies: [
        .package(url: "https://github.com/appwrite/sdk-for-apple", from: "0.1.0"),
    ],

Then add it to your target:



    targets: [
        .target(
            name: "[YourAppTarget]",
            dependencies: [
                .product(name: "Appwrite", package: "sdk-for-apple")
            ]
        ),

Build your project and if there are no errors, we're ready to proceed!

🏗️ Create the layouts

Create a new file AccountView.swift and add the following. This defines our SwiftUI view and sets up our buttons and their click listeners that will call the ViewModel.



import SwiftUI
import Appwrite
import NIO

let host = "http://localhost:80/v1"
let projectId = "613b18dabf74a"

let client = Client()
    .setEndpoint(host)
    .setProject(projectId)
    .setSelfSigned()

struct AccountView: View {

    @ObservedObject var viewModel: ViewModel

    var body: some View {

        VStack(spacing: 8) {

            viewModel.downloadedImage?
                .resizable()
                .aspectRatio(contentMode: .fit)
                .frame(height: 200)

            TextEditor(text: viewModel.$response)
                .padding()
            TextEditor(text: viewModel.$email)
                .padding()
            TextEditor(text: viewModel.$password)
                .padding()
            TextEditor(text: viewModel.$name)
                .padding()
            Button("Login") {
                viewModel.login()
            }
            Button("Login with Facebook") {
                // We'll add this later
            }
            Button("Register") {
                viewModel.register()
            }
            Button("Get User") {
                viewModel.getUser()
            }
            Button("Log Out") {
                viewModel.logOut()
            }
        }
        .registerOAuthHandler()
    }

}

struct ExampleView_Previews: PreviewProvider {
    static var previews: some View {
        ExampleView(viewModel: ExampleView.ViewModel())
    }
}

🔨 Create the ViewModel

Let's now create a ViewModel AccountViewModel.swift to manage state and interact with the Appwrite SDK in response to UI interactions.



import Foundation
import SwiftUI
import Appwrite
import NIO

extension AccountView {

    class ViewModel : ObservableObject {

        let account = Account(client)

        @State var email: String = "test@test.test"
        @State var password: String = "password"
        @State var name: String = "Name"
        @State var response: String = ""

        func register() {
            account.create(email: email, password: password) { result in
                switch result {
                case .failure(let error): self.response = error.message
                case .success(let user): self.response = user.email
                }
            }
        }

        func login() {
            account.createSession(email: email, password: password) { result in
                switch result {
                case .failure(let error): self.response = error.message
                case .success(let session): self.response = session.userId
                }
            }
        }

        func getUser() {
            account.get { result in
                var string = ""

                switch result {
                case .failure(let error): string = error.message
                case .success(let user): string = user.email
                }

                DispatchQueue.main.async {
                    self.text.text = string
                }
            }
        }

        func logOut() {
            account.deleteSession(sessionId: "current") { result in
                var string = ""

                switch result {
                case .failure(let error): string = error.message
                case .success(let success): string = String(describing: success)
                }

                DispatchQueue.main.async {
                    self.text.text = string
                }
            }
        }
    }
}

Our ViewModel has 4 state objects:

email
name
password
response

We also have 4 functions to interact with the Appwrite SDK:

register - onClick handler for the Signup Button
login - onClick handler for the Login Button
logout - onClick handler for the Logout Button
getUser - onClick handler for the Get User Button

🔧 Update The Application File

Finally, let's update our AccountApp.swift, which will initialise our application and create the AccountView and AccountViewModel.



import SwiftUI

@main
struct AccountApp: App {
    var body: some Scene {
        WindowGroup {
            AccountView(viewModel: AccountView.ViewModel())
        }
    }
}

You should now be able to run your app and create users, login, logout and get information about the currently logged-in user!

🔐 Adding OAuth Support

You would have noticed that we have a Login With Facebook button in our UI, but it doesn't do anything yet; let's now add Facebook OAuth to our app!

The first step is to add a callback URL scheme to our Info.plist file.



<key>CFBundleURLTypes</key>
<array>
<dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLName</key>
    <string>io.appwrite</string>
    <key>CFBundleURLSchemes</key>
    <array>
        <string>appwrite-callback-[PROJECT-ID]</string>
    </array>
</dict>
</array>

Make sure you replace the Project ID in appwrite-callback-[PROJECT-ID] with your own.

Next, we'll add a function to our ViewModel to call the createOAuth2Session() method of the Appwrite SDK.



func loginWithFacebook() {
    account.createOAuth2Session(
        "facebook",
        "\(host)/auth/oauth2/success",
        "\(host)/auth/oauth2/failure"
    ) { result in
        switch result {
        case .failure: self.response = "false"
        case .success(let success): self.response = success.description
        }
    }
}

The last step is to invoke this function from AccountView.swift, calling the function from our existing button's action.



Button("Login with Facebook") {
    viewModel.loginWithFacebook()
}

Re-run your app and you should now be able to trigger your Facebook OAuth Flow! With that, you now know how to interact with Appwrite's Accounts API in your iOS, macOS, tvOS and watchOS apps!

✨️ Credits

Hope you enjoyed this article! We love contributions and encourage you to take a look at our open issues and ongoing RFCs.

If you get stuck anywhere, feel free to reach out to us on our friendly support channels run by humans 👩‍💻.

Here are some handy links for more information:

Building apps just got Swifter! - Announcing Appwrite v0.11

Jake Barnby — Mon, 18 Oct 2021 14:07:08 +0000

The last month has been a wild one at the Appwrite community! We've been working tirelessly to bring you some awesome new features with each new version. That said, we're excited to announce our newest release: Appwrite 0.11 🥳 Packed with a ton of cool new features like support for Apple platforms (iOS, macOS, watchOS and tvOS), as well a brand new Swift Server SDK, a Swift Cloud Function runtime and more!

Let's not forget, this is also an Appwrite release, where our open source contributors have outnumbered the maintainers! 🤯 We've merged over 150 PRs from our contributors during Hacktoberfest, and still have over 450 PRs waiting to be merged! With all those exciting numbers aside, let's dive right in! 🐳

Appwrite is an open-source, self-hosted Backend-as-a-Service that aims to make app development easier with SDKs available in a variety of programming languages. Come hang out with us on Discord.

🍎 Apple Support

It's finally here 🌟 Appwrite now has official support for Apple platforms! Our SDK has just been released, and we're looking to gather some feedback from our amazing community! We've got all the setup instructions in our new Getting Started Guide. If you just can't wait to try it out, here are the steps to get you started ASAP.

Add the SDK

The Appwrite Apple SDK is available via Swift Package Manager. In order to use the Appwrite Apple SDK from Xcode, select File > Swift Packages > Add Package Dependency.

In the dialog that appears, enter the Appwrite Apple SDK package URL and click Next.
Once the repository information is loaded, add your version rules and click Next again.
On the final screen, make sure Appwrite is selected to add to your target as a library.

Make a Request

You can now make your first request 😍 below are two examples of simple integrations with the SDK, one for SwiftUI and one for UIKit.

Using SwiftUI

import Appwrite
import SwiftUI

@main
struct TestApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

struct ContentView: View {
    var body: some View {
        Button("Click Me!", action: {
            let client = Client()
                .setEndpoint("https://[HOSTNAME_OR_IP]/v1")
                .setProject("5df5acd0d48c2")

            let account = Account(client)

            account.create(email: "email@example.com", password: "password") { result in
                switch result {
                case .failure(let error): break
                case .success(let user): break
                }
            }
        })
    }
}

Using UIKit

import Appwrite
import UIKit

class ViewController: UIViewController {

    let client = Client()
        .setEndpoint("https://[HOSTNAME_OR_IP]/v1")
        .setProject("5df5acd0d48c2")

    lazy var account = Account(client)

    @IBAction func clickMe(_ sender: Any) {        
        account.create(email: "email@example.com", password: "password") { result in
            switch result {
            case .failure(let error): break
            case .success(let user): break
            }
        }
    }

We also have some example apps to help you get started:

A bare minimum Playground with SwiftUI to help you quickly start building apps.
A bare minimum Playground with UIKit to help you quickly start building apps.
A Job Portal App built with Appwrite.

🏎️ Swift Server SDK

We have also released a brand new Swift Server SDK to go along with the Apple one! Setting up the Swift SDK only requires adding the dependency to your Package.swift file. You can check out our Getting Started Guide or follow along for a quick summary.

Add the package to your Package.swift dependencies:

    dependencies: [
        .package(url: "https://github.com/appwrite/sdk-for-apple", from: "0.1.0 "),
    ],

Then add the library as a dependency of your target:

    targets: [
        .target(
            name: "[YourAppTarget]",
            dependencies: [
                .product(name: "Appwrite", package: "sdk-for-apple")
            ]
        )
    ],

You can now make your first request using:

import Appwrite

let client = Client()
    .setEndpoint("https://[HOSTNAME_OR_IP]/v1")
    .setProject("5df5acd0d48c2")

func main() {
    let account = Account(client)

    account.create(email: "email@example.com", password: "password") { result in
        switch result {
        case .failure(let error): break
        case .success(let user): break
        }
    }
}

We also have some example apps to help you get started

A bare minimum Playground to help you quickly start building apps.
We also have some really cool Cloud Function demos using our Swift SDK.

🏃 Swift Cloud Function Runtime!

Our Cloud Function runtimes list continues to grow with over 20+ (!) runtimes. This time we've added support for swift-5.5, which thanks to ABI stability, supports running code all the way back to Swift 4. We've got you covered 💪 no matter what your favourite language is! We have demos available for a wide variety of languages.

🚅 Everything else

We've introduced new Cloud Function runtimes for java-17, python-3.10, deno-1.12, deno-1.13 and deno-1.14. If you've been thinking about refactoring your Cloud Functions, this might a good time for it 😉
Appwrite v0.11 would not have been possible without the collaboration of almost 100 open source developers (!) who came together to help us during Hacktoberfest! Here's a huge shout out to all the amazing contributors 📢

@m1ga @mishmanners @stnguyen90 @GarvitSinghal47 @chefk5 @ivernus @takmar @oovk @thet3o @KaminskiDaniell @anshganatra @AmreshSinha @hardiksachan @sakshamgurbhele @vishal-codes @Gautam1302 @siw3kosky @toir427 @divshacker @Asmit2952
@HelloSeaNation @Sin-Sumit @aerabi @nataliarossini @kritika-srivastava @felixjeromedelafuente @DevGirisankar @PrerakMathur20 @RReiso @NeonSpork @mantasio @Exouxas @Vidushi-Gupta @krishguptadev @ar-ankou @avinashupadhya99 @waridrox @kostapappas @charithesh16 @banaboi @mazedlx @jakubhi @Emiliaaah @crossphoton @minna-xD @mendoza @didair @ezioishan @tacoelho @Rutam21 @harshita214 @kalpeshT101 @ErfanBahramali @hdkhoasgt @ArtixAllMighty @Biki-das @und1n3 @cristina-sirbu @wenzdey @yalematta @visheshjindal @abxhr @MatteoGheza @torn4dom4n @loftwah @Sooraj-s-98 @OscarRG @teeradon43 @Kokoden @dazzlerkumar @Nikhil-1503 @Sangwan5688 @chuiizeet @Ganzabahl @2002Bishwajeet @KKVANONYMOUS @mbos2 @ilmalte @TheLearneer @deshankoswatte @vj-codes @renato04 @Hrdtr @JaswanthRemiel @ssong @aniketh-varma @anoopmsivadas @Ln11211 @vivekkj123 @achromik @willtryagain @eigengravy @honeykpatel @vendz @Obnoxious-coder @izqalan @arsangamal @daniloff200
Let's not forget, you also helped us reach a major milestone of 13k GitHub stars ⭐️ making us one of the top 1500 projects in GitHub history! Thank you so much for all your support!

We've been having a lot of fun on our Discord server! Weekly chats and AMAs with the Appwrite maintainers, Live PR reviews, Hacktoberfest Countdown parties, impromptu chess games and most importantly, The community run #meme channel!. You'll find yourself right at home. Come on in

⛏️ Breaking Changes

This release introduces no breaking changes, which means you can upgrade your Appwrite instance without needing to run the Appwrite migration script.

😍 And More!

That's not all! We've included other small fixes and optimizations to make everyone's Appwrite experience the best it can be. For full details of the 0.11 release, you can check out the changelog on GitHub.

If you're upgrading from an older version of Appwrite, be sure to follow our upgrading guide so that you don't lose your way in uncharted territories 😉.

If you're curious about what's next for Appwrite, or have a great idea, head on over to our RFC repo for more details.

Our list of awesome tutorials, videos, and demos keeps growing, head over to the awesome-appwrite repo to check them out.

If you've just discovered Appwrite and would like to get started, check out our 30 Days of Appwrite series where we explain step-by-step everything you need to know to build awesome Appwrite-powered apps. Come hang out on Discord, follow us on Twitter, Dev, or wherever you find your friendly neighborhood Appwriter.