DEV Community: Eldad A. Fux

Everything New in Appwrite 1.0

Eldad A. Fux — Wed, 14 Sep 2022 13:15:25 +0000

We are thrilled with the announcement of Appwrite 1.0. The new Appwrite release is our first ever stable version, and one of the biggest milestones for the project and the Appwrite community.

Appwrite 1.0 is not only about stability, like in every Appwrite release, the new Appwrite version is jammed with exciting new features that take Appwrite dev-experience to a new level. In this post, we have summarized everything you should know about the new release with links and resources for helping you to master all the cool new things version 1.0 has to offer.

Permissions 2.0

We have completely upgraded the Appwrite permissions mechanism, adding new capabilities, and more flexibility. Starting with version 1.0, we have introduced the permissions methods create(), update() and delete() to allow granular control over which end user has access to which resource.

The new create() method will allow you to have more control over who can create a document or a file in a database collection or a storage bucket. For convenience, we have also kept the write() permissions which will be used as an alias for create() + update() + delete().

From now own you will also be able to use the role any() to give both signed or guests users access to read or write. This is now possible since the introduction of buckets. By default Appwrite will still keep your resources safe from unauthorized access, but now you could explicitly allow any kind of user to create resources to be stored on your Appwrite backend.

For more convenience, we have upgraded all SDKs to support both the new Permission and Role classes for quick and easy completion of the different permissions method and allowed roles.

import { Client, Databases, Permission, Role } from "appwrite";

const client = new Client();

client
    .setEndpoint('https://[HOSTNAME_OR_IP]/v1')
    .setProject('[PROJECT_ID]');

const databases = new Databases(client, '[DATABASE_ID]');

let promise = databases.createDocument(
    '[COLLECTION_ID]', // Collection ID
    {'actorName': 'Chris Evans', 'height': 183}, // Data
    [ // Permissions
        Permission.read(Role.any()), // Anyone can view this document
        Permission.edit([Role.team("writers"), Role.team("admin")]), // Only writers and admins can edit this document
        Permission.delete([Role.user("5c1f88b42259e"), Role.team("admin")]) // Only user 5c1f88b42259e and admins can delete this document
    ]
);

promise.then(function (response) {
    console.log(response);
}, function (error) {
    console.log(error);
});

Queries 2.0

The Queries system has also seen a major overhaul in Appwrite 1.0. We notice the list endpoints in Appwrite had inconsistent, yet bloated function signatures. For example, consider the example below which does nothing but sort by title in ascending order:

import { Databases} from "appwrite";
const databases = new Databases(client, "[DATABASE_ID]");  // 'client' comes from setup
databases.listDocuments(
    'movies', // collectionId
    [], // queries
    25, // limit
    0, // offset
    '', // cursor
    'after', // cursorDirection
    ['title'], // orderAttributes
    ['ASC'] // orderTypes
);

There are far too many parameters in the listDocument() method. To solve this problem we’ve overhauled the Queries system so that list endpoints take only a queries parameter. Each type of query, sort, or pagination action will now be passed to list endpoints through the queries parameter.

Here’s the same example in Appwrite 1.0:

import { Databases, Query } from "appwrite";
const databases = new Databases(client, "[DATABASE_ID]");
databases.listDocuments(
    'movies', // collectionId
    [
        Query.orderAsc('title'), // Order results in ascending order by title
    ], // queries
);

This new syntax is much more concise and easy to write. The new query also does pagination in a similar fashion like before:

import { Databases, Query } from "appwrite";
const databases = new Databases(client, "[DATABASE_ID]");  // 'client' comes from setup

// Page 1
const page1 = await databases.listDocuments('movies', [
    Query.greaterThan(year, 1999),
Query.limit(25)
]);
const lastId = results.documents[results.documents.length - 1].$id;

// Page 2
const page2 = await databases.listDocuments('movies', [
    Query.greaterThan(year, 1999),
Query.limit(25), 
Query.cursorAfter(lastId)
]);

Appwrite also required an exact index for querying and sorting in previous versions. If you had a query like the one below, you would have needed an index with the exact attributes and order of [‘title’, ‘year’, ‘studio’]. The index of [ ‘year’, ‘title’, ‘studio’] or [‘title’, ‘year’, ‘studio’, ‘language’] would not have worked.

// Page 1
const page1 = await databases.listDocuments('movies', [
    Query.equal(‘title’, “Lion King”),
Query.greaterThan(‘year’, 1999),
Query.equal(‘studio’, ‘Disney’)
]);

With the new flexible indexes in Appwrite 1.0, you can now perform the query with either of the previously mentioned index examples. This is the first of a series of planned improvements to increase database flexibility in Appwrite in the coming weeks and months.

DateTime Attributes and ISO8601 Support

A new attribute was introduced in Appwrite 1.0 after popular demand, which is DateTime Attributes. The new DateTime attribute follows ISO 8601 and displays time information in a human readable string. All DateTimes will be stored in UTC to avoid timezone confusion.

This is better than Unix Timestamps in the sense that it can represent dates before 1970 and after 2038. This is useful for scheduling or birthday type information that often require longer time frames. To be consistent, all timestamps returned by different Appwrite endpoints are also in DateTime format and UTC timezone in Appwrite 1.0.

Password Hashing

Appwrite 1.0 introduces a new API that allows you to import password hashes in different formats. The supported formats are BCrypt, MD5, SCrypt, SCrypt Modified (Firebase), Argon2, PHPass, SHA, and Plain Text. Appwrite will also be using Aragon2 as the new default hashing algorithm as recommended by OWASP. Here’s an example importing a password using BCrypt:

import { Client, Users, ID } from 'appwrite';

// make sure to have client with endpoint and project ID

const users = new Users(client);

const passwordHash = '$2a$12$SnuhggUBPwc0ZTFsLeENVuKD.UcNOl6h/fIFkzih8pRQYZa2oNVM2'; // Hash of password: AppwriteIsAwe$ome

users.createBcryptUser(ID.unique(), 'test@appwrite.io', passwordHash);

This is hashing API is only available on Server SDKs and intended for importing existing users from other platforms. All imported hashes that are imported are converted to Argon2 after the user is created, like normal users created on Appwrite.

Zstd Compression

In previous versions of Appwrite, we’ve only supported file compression using Gzip. In Appwrite 1.0, we introduced file compression using Zstandard which is a fast compression algorithm with high compression ratio intended for all types of online storage. You can now choose to use this type of compression algorithm in the Appwrite Storage service.

What is Coming Next?

Appwrite still has lots of room to grow and evolve. We're excited for the future roadmap of Appwrite and confident in the potential of Appwrite to revolutionize how software is built and maintained. Together with the open-source community and wider developers community, we believe Appwrite has endless possibilities to simplify developers' lives and allow all of us to focus on innovation.

Get Involved!

Appwrite is built and designed by a community of passionate open-source developers. Getting started in the Appwrite community and becoming more involved is very easy. While many love to support the project with code contributions, there are other great ways to give a hand. Helping in the Discord community or through GitHub issues, sharing your feedback, reporting bugs, or spreading the word by creating written or video content and engaging with other developers on social media. Every contribution counts and helps us make Appwrite better.

Announcing New Versions for Appwrite's Flutter and Dart SDKs

Eldad A. Fux — Thu, 01 Sep 2022 11:18:58 +0000

We're happy to announce the release of versions 7.0 and 6.1 of the Appwrite SDKs for Flutter and Dart. The new versions add some fixes and update outdated dependencies for both SDKs.

We're also happy to share that version 7.0 of the Flutter SDKs now fully supports OAuth authentication for Windows applications. If you're already using OAuth authentication with previous versions of the Appwrite SDK with Android devices, you will need to make sure you update the AndroidManifest.xml manifest file with the new settings:

<manifest ...>
 ...
 <application ...>
   ...
   <!-- Add this inside the `<application>` tag, along side the existing `<activity>` tags -->
   <activity android:name="com.linusu.flutter_web_auth_2.CallbackActivity" android:exported="true">
     <intent-filter android:label="flutter_web_auth_2">
       <action android:name="android.intent.action.VIEW" />
       <category android:name="android.intent.category.DEFAULT" />
       <category android:name="android.intent.category.BROWSABLE" />
       <data android:scheme="appwrite-callback-[PROJECT_ID]" />
     </intent-filter>
   </activity>
 </application>
</manifest>

In case you're using the package with web applications, you will need to update your callback file like the following example:

<!DOCTYPE html>
<title>Authentication complete</title>
<p>Authentication is complete. If this does not happen automatically, please
close the window.
<script>
 window.opener.postMessage({
   'flutter-web-auth2': window.location.href
 }, window.location.origin);
 window.close();
</script>

As you can see, the change is minor and meant to indicate that Appwrite is now using the flutter_web_auth_2 package instead of flutter_web_auth. The new package includes multiple improvements and bug fixes that should enable a better experience when using the Appwrite SDK for Flutter.

This is also a great opportunity to thank Nico Mexis for forking and maintaining the new flutter_web_auth_2 package and to many of the Appwrite community members, including Dom Jocubeit, Bishwajeet Parhi, Agon Noga and Kamil Pyrkosz for raising, discussing and helping address those issues.

Learn More

If you're new to Appwrite, Appwrite is a fully 100% open source backend as a service platform providing developers with all the core APIs required to build Web or Mobile applications. You can learn more about Appwrite and get started with the Appwrite SDK by visiting the Appwrite Documentation.

Announcing Appwrite 0.14 with 11 Cloud Function Runtimes! 🥳

Eldad A. Fux — Tue, 17 May 2022 15:04:13 +0000

We're back with yet another Appwrite release! Appwrite 0.14 is now LIVE with a lot more improvements! With the new release we focused heavily on features that the Appwrite community requested the most. With many exciting features and important bug fixes, Appwrite 0.14 now enables even more flexibility, performance, and integrations to build your amazing next project! Let’s deep dive and learn what this release has to offer. 🏊‍♀️

⏰ TL;DR

Two areas that received the most attention are Events and Certificates. With the new event model, you can now trigger actions with a lot more precision. The improvements around certificates makes it more easy, scalable, and reliable to generate and manage Let's Encrypt generated certificates. You can now lean back on your chair and enjoy the trusty 🔐 green lock in front of your domain 🍹

Alongside these features, we introduced new OAuth providers, Storage Adapters, and Function Runtimes to support an even wider range of amazing applications on more platforms. Some small features you can get excited about are Wildcard Hostnames, Async/Await support in Swift, and the ability to ignore files using the Appwrite CLI. We closed off the release with bug fixes and quality of life improvements around the Appwrite Console UI and API signatures.

New to Appwrite?

Appwrite is an open-source back-end-as-a-service that abstracts all the complexity of building a modern application by providing you with a set of REST and Realtime APIs for your core back-end needs. Appwrite takes the heavy lifting for developers and handles user authentication and authorization, databases, file storage, cloud functions, webhooks, and much more!

🧠 Event Model, the Smart Way

We're thrilled to introduce support for a lot more events, allowing your configuration to be as specific or as generic as you require. Previously, the following event would be triggered, for instance, when a new database document was created:

database.collections.create

This is great, but what if you have dozens of collections? You would end up with many events triggered for each collection. What if you're only interested in events from one of these collections?

With the new event model, we can specify specific resources we are interested in. The same example above could be written as follows if we were only interested in documents from the [MY_COLLECTION] collection:

collections.[MY_COLLECTION].documents.*.create

As you can see, we specified, we are only interested in events from the [MY_COLLECTION] collection in the new syntax. You can also notice the * symbol indicating we are interested in all documents inside a collection. This new syntax will allow developers to get exceptionally specific with their events and reduce the number of unwanted webhooks and function executions to zero.

🔐 Certificates You Can Trust

Certificate generation was fully refactored with a focus on simplicity and reliability. We introduced the concept of a main domain to ensure we don't generate certificates for domains you don't own.

Next, we updated the way we delete domains and certificates to ensure we only have one certificate per domain, and we delete it only once no domain needs it. This allows proper usage of the same domain under multiple Appwrite projects.

We then introduced a mechanism to automatically retry certificate generations. A certificate generation can fail for a lot of reasons like a 5XX error, NS downtime, DNS miss-configuration, cache etc. Some of them are recoverable while some others are not. The maintenance and certificates workers will now retry the certificate renewals and generations for up to 5 attempts to try and overcome the recoverable errors.

No need to worry about failed requests, since you will now receive an email notification every time a certificate generation fails, so you can investigate it 👀 Just ensure your email is set in the .env file.

Lastly, we introduced a new CLI command which comes in handy if you want to force the generation of a certificate for a specific domain:

docker-compose exec appwrite ssl domain="api.myapp.com"

👪 C++, .NET, Java & Kotlin join the party!

Let's welcome on board four new runtimes 🎉 A well-established Java and its friend Kotlin have joined the Appwrite Runtime family. They've also invited C++ and .NET to ensure Appwrite developers can have the best possible experience writing code in a language they love the most. All these runtimes are now available when creating a new Appwrite Function, and provide the same breathtaking performance we shared with you in the previous Appwrite release.

We didn't stop there! After a lot of feedback, we implemented Function Ignores to allow developers using Appwrite CLI to specify the files that will be part of a deployment. This comes in handy when you don't want to deploy files like your .env along with your functions. Another great use-case would be ignoring local dependencies that are not necessary for deployment but are required by your IDE to get proper typing support. With smarter ignores in your Appwrite Function, deployment can be safe and rapidly faster. All of this can be done either by having a .gitignore file in your function directory or by a manual configuration in your appwrite.json file.

💪 Flexible Wildcard Hostnames

If you've built a website before, or interacted with the Appwrite API, chances are, you've come across CORS issues. It all comes down to Appwrite protecting your backend from untrusted sources. Thankfully, in Appwrite 0.14 you can now use the wildcard symbol * to support all subdomains of a trusted domain. For instance, you could allow *.mydomain.com to trust all your subdomains. If you feel adventurous, you could even do myapp.* or simply *. Be aware, that the more you allow, the less control you have over who can use your backend!

⛔️ Say No to Callback Hells

With Appwrite 0.14 we have rewritten our Swift SDK to allow better code readability thanks to async/await support introduced in Swift 5.5. Awaiting asynchronous code not only allows you to write code in a simple top-to-bottom code block but also prevents callback hell and re-throwing errors.

Let’s start by looking at how a piece of code could look like without async/await support:

func prepareConnection() {
    getJWT() { jwt in
        print(jwt) // Do stuff with JWT
    }
}

func getJWT(completion: @escaping ((String) -> Void)) {
    account.createJWT() { result in
        switch result {
            case .failure(let error):
                fatalError(error.message)
            case .success(let response):
                completion(response.jwt)
        }
    }
}

As you can see, we had to use a completion callback and the code looks overall really complex. Let’s enhance the same code with async/await support:

func prepareConnection() async throws {
    let jwt = try await getJWT()
    print(jwt) // Do stuff with JWT
}

func getJWT() async throws -> String {
    let response = try await account.createJWT()
    return response.jwt
}

Wow, what a change! By marking methods as async and using await to get data from Appwrite, we can achieve exact same logic as previously while keeping the code simple and succinct.

🛰️ New Providers Everywhere - OAuth + Storage!

We introduced 3 new OAuth providers Zoom, Okta, Auth0, and 3 new storage adapters Linode, Backblaze, Wasabi. Appwrite was and always will play well with other technologies so the decision regarding the technology stack is in your hands, not ours.

🤩 And Much More!

Alongside all the amazing stuff, we also decided to clear some confusion around user deletion. We renamed our Client SDK method from account.delete() to account.updateStatus(). The new naming convention aims to indicate that the account is not deleted; instead the status is updated. To completely delete an account, you can use the Appwrite Dashboard or the users.delete() method in the Server SDK. Keep in mind we no longer reserve a user ID after deletion, so make sure to also delete all user-generated content and invalidate permissions before deleting the user to prevent any data leaks.

Appwrite Console (Dashboard) received a lot of attention in this update! A shiny new component for the new event model was added, a verification toggle on the user has been implemented, and an activity tab was added to the teams page. We also introduced better logs for function deployments, fixed missing attribute icons in the Database screens and project logos, and updated the enum attribute dropdown to show correct values.

📚 Learn More

This was only a tip of the iceberg of what Appwrite 0.14 has to offer! Check out the official release notes and stay tuned for more blog posts! In upcoming weeks we will describe all features in their own separate blogposts to give them well-deserved spotlights. We can't wait to see what you build with Appwrite! 😎

Announcing the Appwrite OSS Fund

Eldad A. Fux — Wed, 04 May 2022 14:38:02 +0000

Building and maintaining an Open Source Software(OSS), the project is hard. If your project gets popular, it becomes even harder. When I started building Appwrite two years ago, I fell in love with the community, the people, and the OSS way. It only took me a few days to understand there is nothing in life I want to do more. Finally, three months after the project started gaining momentum, I decided to leave my day job and follow my dream, of becoming a full-time OSS maintainer.

Little did I know how hard it would be. For months I worked on improving the project, providing support, creating content, and spreading the word. I always believed Appwrite has huge potential, but at the same breath, I knew it was going to require massive efforts and resources to get the project where it can and needs to be.

After 12 months of working on the project full-time, I started feeling financial pain. I was literally with my back to the wall. Understanding the product is far from complete or in a state where I can monetize it, I started to think about collecting OSS donations, providing premium support, and even as far as canceling my rental as I was starting to feel the pressure of overloading expenses.

In the best timing ever, I got an amazing investment offer from the wonderful individuals at Ibex and Seedcamp that offered to support my vision for Appwrite. Six months later, they were followed by an investment from Bessemer (Auth0, Cloudinary) and Flybridge (Firebase, MongoDB) that led our 8.5m seed round.

Today with over 27 full-time Appwriters and backed by a community of over 150,000 developers, we're stronger than ever, which means it's time to give back and support those who weren't as fortunate as us and remember the origins of our journey. Today is the time to announce the Appwrite OSS Fund.

Why OSS fund?

Open-source is all about collaborating, learning, sharing, and building together with the community. Keeping up this spirit, we at Appwrite thought of giving back to the community with the introduction to “Appwrite OSS Fund”. This is our way of giving back to the community - which forms the core of our company - growing and helping others grow. If reading Eldad's story made you think to yourself, "that sounds just like me," then this is your cue to apply for the OSS Fund, and take your project to the level you dreamt of.

In the journey of turning your dream project into a reality, all that you need to have is the vision to build an awesome open-source project. The idea behind the fund is to support developers like you and the open-source project you are building.

How does the fund work?

The Appwrite OSS Fund is simple:

You apply for it from here.
If selected, you get a fund worth $2500.
We pay you via GitHub sponsors or Open Collective.
You can nominate yourself or any other maintainers you know.
There is no bar to the number of nominations you make - with an exception of one project per nominee.
Once your application is received, a response email will be within 15-30 days.
To review the applications, we will set up a committee composed of the core Appwrite team and representatives of the Appwrite community to assess all applications. The committee will decide how the funding will be best used by applying projects based on multiple factors, ranging from project popularity, technological impact, innovation, and the current project’s financial capabilities.
For more information, visit here.

This Is Not Enough

We will always think of new ways to expand our support for the community and ensure this will be core to everything we do at Appwrite, but we also recognize our support alone will not be enough. We call other companies and individuals to join us. Support projects and maintainers in one of many ways possible, and work together to create a sustainable future where open source is not only something we get a lot from but also something we are actively giving back to.

Acknowledgment

We are humbled to have the opportunity and privilege to contribute to the growth of developers. Thank you for all the love and support that you all have showered on Appwrite, it gives us the enthusiasm to become better every day.

Let the spirit of open-source never get dull - share about the Appwrite OSS Fund to the maximum, help us reach the unheard voices.

Announcing Appwrite 0.13 with Major Upgrades to Storage and Functions

Eldad A. Fux — Wed, 02 Mar 2022 16:57:27 +0000

Only one month after the release of Appwrite 0.12, we’re excited to announce the release of Appwrite 0.13. The new release includes multiple major features to take your Appwrite experience to the extreme and help you implement some new and exciting use cases on top of your shiny, open-source, and self-hosted backend-as-a-service.

⏰ TL;DR

This new release has been focused on two main areas. The first is Appwrite Storage. We have added many new features, including buckets, (especially) big file support, stream downloads, and new storage adapters for S3, DigitalOcean Spaces, and other S3 compatible devices.

The second area of improvement is Appwrite’s Cloud Functions. The new Appwrite Functions API uses our new executor build on top of open-runtimes (more on open-runtime below) that improves Appwrite functions execution performance by over 10 times(!) and now allows the anxiously anticipated sync & async executions.

On top of these major additions, you can also expect multiple new and improved OAuth adapters, new logging providers, many bug fixes, and some UI improvements to the Appwrite console. Keep reading to learn everything you need to know about the 0.13 release.

New to Appwrite?

Appwrite is an open-source back-end-as-a-service that abstracts all the complexity of building a modern application by providing you with a set of REST APIs for your core back-end needs. Appwrite takes the heavy lifting for developers and handles user authentication and authorization, databases, file storage, cloud functions, webhooks, and much more!

📦 Storage Buckets

Storage buckets are very similar to collections for the Appwrite Database. Buckets allow you to group different files under the same permissions and settings. For each bucket, you can define which file type it should accept, the max file size allowed and and toggle file encryption and file antivirus scan.

Using buckets, you can choose between bucket-level or file-level permissions and set a dedicated bucket per user or a bucket for each type of file your app needs to store, like profile images or PDF files.

🗄 Storage Adapters and S3 Support

We designed Appwrite to be flexible and technology agnostic with the idea that you should be able to integrate Appwrite with your favorite technology stack. With this release, you can now use your S3 or S3 compatible services like DigitalOcean spaces as the storage adapter for your Appwrite files.

This allows you to quickly scale Appwrite using managed solutions for all the Appwrite persistent services (storage and database). With this change, the Appwrite layer of your setup becomes completely stateless and easier to manage on self-hosted setups. Furthermore, with cloud providers like AWS, DigitalOcean, and others you can also utilize managed backup and monitoring solutions and be carefree about managing your Appwrite storage layer.

This release unlocks new possibilities, and the Appwrite team has already started working on new storage adapters for even more flexibility. Contributing a new storage adapter is also possible and relatively simple using our updated contribution guide.

📈 Support for (VERY) Big Files

Another significant improvement that Appwrite 0.13 adds to the storage API is supporting very large file uploads. In previous Appwrite versions, each file is loaded to your server memory which means that the biggest file you can upload is limited to the amount of free memory you have available. This is no longer the case. Appwrite 0.13 now internally handles files in small chunks to ensure you always have enough memory available to serve other API calls and background jobs.

Theoretically, once you change your _APP_STORAGE_LIMIT env var, Appwrite doesn’t enforce any limit on the size of files you’ll be uploading. That said, you might hit other filesystem or vendor limits. For example, AWS and DigitalOcean S3 services have a file size limit of 5TB, ext4 filesystem has a limit of 16TB, and NTFS has a limit of 256TB.

With big files support enabled in Appwrite, the Appwrite server will still support the built-in ability to compress and encrypt files but limit those features to files smaller or equal to 20MB. This design ensures we keep a decent balance between flexibility and performance. With storage buckets support, you can also completely disable file compression and encryption at your discretion.

🧑‍💻 CLI v2.0 and a new Build Worker

Beside version 0.13, we’re also excited to share the release of the new Appwrite CLI version 2.0. The new version was completely rewritten to decouple our CLI from Docker, and have a better and easier workflow for deploying new Cloud Functions.

The new CLI 2.0 will have two new commands, init for creating resources and deploy for deploying resources. The new CLI will also support starter templates for Functions in different languages, Console scope to manage the creation of projects, API keys, and more, and an appwrite.json file to store your configuration and deploy on different Appwrite instances.

⚡️ Improved and (WAY) Faster Runtimes for Cloud Functions

One of the biggest improvements of Appwrite 0.13 is our new Functions runtime and execution architecture. The new architecture uses TCP communication instead of the Docker CLI to start, run, and execute functions. The new communication method allows warm functions to run over 10X faster compared to previous Appwrite releases.

The new architecture also allows the Appwrite Functions API to execute functions synchronously and asynchronously. This new capability should allow an enormous amount of new use-cases to be built on top of the Appwrite functions and brings Appwrite very close to serverless capabilities of major cloud providers like GCP and AWS. We’ll soon release our latest benchmarks to emphasize how the new performance improvements look like.

🤩 Many More Features

Appwrite 0.13 includes many more new features. We have added two new OAuth providers for Stripe and Notion. We have upgraded the Microsoft OAuth adapter to accept new settings and be much more flexible. New support for OAuth refresh token was added, and we added a new error logging adapter for managing your Appwrite server errors with LogOwl.

In the new version we have also improved the format of errors displayed by the Appwrite API. Now each error includes a specific type of code as documented in the updated error codes page in the official documentation.

📚 Learn More

Appwrite 0.13 includes many more features, bug fixes, and security patches you should really care about that just can’t fit in one blog post. You can learn more by reviewing our official release notes. In the next couple of weeks, we will continue the Appwrite 0.13 release party with more content, events, and demos created by the core team to highlight the different features and powerful capabilities in this new version of Appwrite. Stay tuned!

It's Here! Announcing the Release of Appwrite 0.12!

Eldad A. Fux — Wed, 05 Jan 2022 10:37:45 +0000

We're excited to share that Appwrite 0.12 is now officially available! The new Appwrite version includes our biggest ever performance improvements, enhanced developer experience, and many new features designed to make developers' lives easier. Trust us, this one's a biggie! In addition, the latest release includes over 1,500 commits and contributions from 29 new contributors that have helped make this release possible.

🧪 Database on Steroids

In version 0.12, we have completely rewritten the Appwrite data management layer. We have improved the internal data structures, background workers, and we’ve enabled new concepts such as attributes (instead of rules) and indexes to allow maximum performance and flexibility.

We’ve also added a new easy-to-understand query syntax. The new syntax allows new capabilities, like OR statements, and opens the door for the core team to implement many more advanced features we’re passionate about, like includes operator and GEO-based queries.

The team has done a lot of work to enable other databases providers, and we hope to release support for more loved databases soon. A major part of our agenda is to enable dev teams the comfort and confidence to use Appwrite the way they wish to, with tools they already love, know, and feel confident with.

The new database does introduce some breaking changes before we move to version 1.0. Please take time to review the list of changes and our migration tutorial. To support existing Appwrite users we'll continue to support the 0.11 branch for at least the next six months.

📑 Pagination Just Got A LOT Faster!

With Appwrite 0.12, we are happy to introduce the new cursor pagination strategy. While the traditional offset and limit pagination is very intuitive and easy to understand it doesn’t scale well. To tackle this problem, we have limited the limit+offset pagination to a maximum of 5,000 documents. With this limit, you can still use the offset+limit pagination for small dataset, but as your data grows, you can migrate to the new cursor pagination that scales very well with almost no regard to your collection size.

The chart below demonstrates how significant this performance difference can be on a collection containing 1M documents. The bigger the dataset, the bigger the difference, and now Appwrite can allow you to scale your pagination with confidence.

The new change will apply to all the Appwrite resources where pagination is possible. Whether it's your custom collections, list of files, users, functions and other relevant resources.

🚧 Permissions are Easier and More Flexible

When we initially designed Appwrite, we wanted to have a simple declarative permission model that is also secure by default. With the release of Appwrite 0.12, we're happy to introduce the next evolution of the Appwrite permissions: Permission Models. You will now be able to choose between two different permission models for your collections, collection-level permissions and document-level permissions.

If you're already familiar with Appwrite, the document-level model will act in the same way as you already know. Each document can have read and write permissions that define which Appwrite entity (user/team/role) has access to each operation.

The new Collection Level model introduces new and easier to use collection permissions. Using the collection permissions, you only need to set the read and write permissions once. In addition, the collections permission will act the same for all the documents regardless of any permissions that may have been set on a specific document.

The new model offers more flexibility for other use cases, which may not require you to leverage the original, document-level permissions. The new collection-level permission can also lead to enhanced performance as the Appwrite API is not required to validate each permission individually.

🎛 More Dashboards, and More Control

We have upgraded the Appwrite console with more dashboards with your Appwrite projects' usage metrics. This is the first of many upgrades where we aim to make more usage metrics easily available through the console. Using our new dashboards, you can quickly get insights into your project performance, size, and cost. In addition, the new dashboard will now show data for your entire project, files, users, collections and documents over time. We've also added charts for your CRUD operations.

🤟 Anyone Ask for Custom IDs?

Custom IDs were probably one of the most requested features we’ve ever got. Now they're here! With custom IDs, you can define human-readable IDs on most Appwrite resources including users, teams, functions, projects, files, collections, and documents. If you still want to use the previous unique IDs, you can use the reserved unique() keyword.

With custom IDs, you can have a much smoother development experience. Instead of using meaningless strings in your code, you can now use proper naming conventions that allow you to easily migrate your code between different Appwrite environments without managing complex configuration files or programmatic setups for your project.

✅ Your Services, Your Choice!

We always wanted Appwrite to play well with other tools. However, we understand that one tool can’t always be the right solution to every problem. For that reason, we’ve created our server API, Cloud Functions, and our Microservice architecture that enables you to use Appwrite alongside your existing stack and even your own backend server.

With version 0.12, Appwrite became more flexible by allowing you to choose which Appwrite services you wish to enable or disable. This is also a great security feature designed to reduce your attack surface by blocking services and resources you don’t consume. You can visit the new Services section from your project settings and choose which services to use. For convenience, each project you own can have different settings.

🚨 Introducing Logging Providers!

Error logging and monitoring are crucial for any application, Appwrite being no exception. We wanted to make it extremely easy to collect and monitor your logs while staying true to our philosophy of being completely platform agnostic. With Appwrite 0.12, we've introduced support for some amazing open source logging providers like Sentry, Raygun and AppSignal!

We're always on the lookout for more logging providers and we'd love your contributions to the logging library.

📚 Learn More

Appwrite 0.12 includes many more features, bug fixes, and security patches you should really care about that just can’t fit in one blog post. You can learn more by reviewing our official release notes. In the next couple of weeks, we will continue the Appwrite 0.12 release party with more content, events, and demos created by the core team to highlight the different features and powerful capabilities in this new version of Appwrite.

🗂⚡️☁️ What's Next?

If you like Appwrite 0.12, you will love Appwrite 0.13! Appwrite 0.12 release will enable us more flexibility and solid foundations to take Appwrite to new places, never seen in the backend-as-a-service space.

Appwrite 0.13 will be the first release of many to enjoy the perks of the hard work the Appwrite core team with over 500 collaborators have done for the Appwrite project and ecosystem. The next version will include some very cool features like buckets support for the Appwrite storage, more flexibility with new storage devices, Sync & Async serverless functions that have been highly requested, and amazing performance boost thanks to our improved function execution model and new runtimes.

Beside the upcoming releases and features, we’ve just recently announced the ability to sign up and be the first to use the upcoming Appwrite Cloud. The Appwrite Cloud is already in the works, and once available it will provide the easiest way to build on top of Appwrite and to scale your backend effortlessly. You can learn more on our new dedicated landing page for the Appwrite Cloud.

Getting Started With Appwrite's Apple SDK 📱💻

Eldad A. Fux — Thu, 21 Oct 2021 04:40:39 +0000

Earlier this week, we announced the official release of Appwrite 0.11 and the new Appwrite SDKs for Apple devices and Swift. Yesterday we had a short live session with Aditya, Jake, and Damodar, demonstrating how you can quickly start building apps for Apple devices with Appwrite as your backend server.

To learn more, you can check our official Appwrite 0.11 announcement post, and check our Apple and Swift SDKs. If you have any further questions you can join the Appwrite team and community on the Appwrite Discord server.

It's Here! Announcing Appwrite 0.10 and the new Realtime API!

Eldad A. Fux — Tue, 31 Aug 2021 06:03:18 +0000

After long anticipation and great feedback we got from the Appwrite community during our alpha launch, we're thrilled to announce the official release of Appwrite 0.10, including one of our most anticipated features: the Appwrite Realtime API! 🥁

Besides the Realtime API, Appwrite 0.10 also comes with some exciting features, including new APIs, improved performance for the Appwrite Cloud Functions API, and multiple bug fixes.

🤔 What is the Appwrite Realtime API?

Appwrite's new Realtime API introduces a new entry point to your Appwrite server in addition to the existing Appwrite REST API, and allows you to subscribe to any real-time events you'd like across your Appwrite projects.

The Realtime API brings a powerful websocket server to your apps to supercharge the Database API and more! You'll be able to listen to real-time events for any of your Appwrite services including users, storage, functions and more. That way, you get notified about a new file being created, a user creating a new session, or a function execution being completed.

In addition, the new Appwrite client SDKs include new supporting methods to allow you to subscribe to any events and trigger any callbacks you wish directly from your Web, Flutter, or Android application (native iOS coming soon 😉).

The new Realtime server has the potential to support hundreds of thousands of concurrent connections on a single server with millions of open subscriptions. This is a great start, and we're constantly working to improve these numbers and push Appwrite's performance 🚀 to the limits!

The Realtime API leverages the same easy Appwrite permissions mechanism to ensure only users with ‘read’ access to your different resources would get notified once a relevant event has triggered.

As with all our existing SDKs, the new subscribe methods of the Realtime API follow the trusty and predictable Appwrite coding style! Here's a sneak peak of the new API signatures

🌎 Web

🦋 Flutter

🤖 Android

To learn more and start to integrate your apps with these neat real-time capabilities, read our updated getting started tutorials for Web, Flutter, and Android, or check our advanced documentation section for the Realtime API.

⏲️ Improved Function Execution Times

As part of our ongoing efforts to tune the Appwrite Cloud Functions service, version 0.10 will significantly boost the execution times. In addition, as part of a more extensive effort, we have migrated the Functions executions API to directly interact with Docker TCP API instead of the Docker CLI. This change resulted in 60-120ms performance improvement for most available runtimes!

The next Appwrite version will include more upgrades as we plan to add support for both synchronous and asynchronous function executions and more performance improvements expected to boost execution times even more significantly. So stay tuned 😉

⚡️ Introducing New APIs

As requested by many members of the Appwrite community, we have now added three new API endpoints for updating your users' name, email address, and password using both the Users API and the Appwrite console!

Using the new endpoints, developers of your projects get full freedom to manage your app users without the need to use the Accounts API or a JWT secret for handling this kind of behaviour from the Server API.

🔐 New Authentication Method!

With this release, we introduced a new authentication method we like to call Magic URL! Think of this as a password-less authentication method where a user can signup or login simply via their email ID! Here's a quick preview 👀

😍 And More!

We still haven't covered everything! There's lots more bug fixes and other micro optimizations we made under the hood to make your experience with Appwrite better! To get all the details on Appwrite 0.10, check out all the changes in the changelog on GitHub.

Are you curious about the big ideas we have up next, or have a great idea for Appwrite's future? Check out the RFC Repository for more details. Also, our awesome-appwrite repository keeps growing with new tutorials, videos, and demos.

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

👀 What's Next?

Appwrite 0.11 is not far away and we promise it's going to be even more exciting 🤩! We'll continue improving upon Appwrite's solid performance, flexibility and adding amazing new features.

Do you have ideas for an exciting new feature ? Open up a Github Discussion so you can get feedback from the core team, maintainers and our ever growing community.

You're welcomed to join us on Discord to get all the latest updates about new Appwrite versions and chat directly with the Appwrite team.

Announcing the Appwrite Official Swag Store! 🛍

Eldad A. Fux — Thu, 03 Jun 2021 16:12:47 +0000

We're super excited to announce the launch of the Appwrite Swag Store. Yes! Our Swag Store is now live, and you can order merch from your favourite open-source project starting now ❤️.

We have been wanting to do this for quite some time now, and we realized it would be perfect to have the store up in time to distribute swags for #30DaysOfAppwrite event! We had two main motivations when we started out with this idea:

We wanted the process of shipping swags to be much easier, and allow anyone liking our projects to be able to get any Appwrite swags they desire, and we also wanted a fun way to sponsor and support other open source projects.

Giving Back to The OSS Community 👩‍💻👨‍💻

We love ❤️ Open Source and we know that you do too! We also know that some OSS projects might find it hard to sustain themselves. That's why we decided that any profit that the new Appwrite swags store makes will be invested back in the open-source community!

We realized that a swag store would be a great way to support some exciting open-source projects, giving both you and us a sense of satisfaction. As with everything we do at Appwrite, we love transparency, here are some details.

The price you see on our store accounts for all the production costs like store hosting, transaction commissions, and manufacturing costs and an additional 5-10% on each product. We will be sharing updates about the store revenue and the details about the projects we decide to sponsor each month in our monthly newsletter!

Easy Distribution ✈️

We love giving away swags, and it lights up our faces every time one of you tags us on social media or sends us pictures of your Appwrite goodies.

But then, scale happened! We started getting an overwhelming amount of responses during various events like Hacktoberfest, the Easter Egg Hunt, #30DaysOfAppwrite, and people actually asking to support us and buy hoodies. Having all these new contributions is a great problem to have, but it became increasingly difficult to manage the procurement, warehousing, logistics and shipping of Goodies! Having the store takes that burden away, allowing us to invest more time in making Appwrite the best OSS alternative to Firebase we can! For all our future events, we will be distributing swag cards to make purchases easy for all of you!

The Products 👚 👕

With our motivations aside, let's talk a little bit about the products! We have debug_mugs() to help you while you crush those nasty bugs, phone.protect(), laptop.protect(), init_pillows() and many new Notebooks() to name a few. Check out the store for a complete list of products and grab some before we run out of stock! You can find our store over at https://store.appwrite.io/

We're anxiously awaiting feedback about what's good, what's bad, and what you'd like to see more of! We would love to hear about products you'd like to see, your favorite open-source projects we could sponsor, and everything else in between. If you have experience running an online store, hit us up! We would love to hear more about your learning and experiences.

Introducing: The Appwrite Gang of Four (and new ways to get swags)

Eldad A. Fux — Sat, 17 Apr 2021 11:05:56 +0000

We're happy to introduce you to the new Appwrite gang of four (yeh, like the book, but not really), a set of four TODO example applications built using all popular JS frameworks, including React, Vue, Angular and Svelte. The new examples are designed to demonstrate how you can utilize Appwrite in your favorite set of technologies.

At Appwrite, we believe backend as a service should be as simple and most intuitive to use. Following that believe we designed the new examples to be as simple and straightforward but still give you an excellent idea of how to start using Appwrite and scale and grow with it.

New to Appwrite?

Appwrite is an open-source, end-to-end development platform designed to abstract the most complex and repetitive processes involved in building a modern app. Appwrite is a self-hosted solution you can host on any infrastructure and provides you all the core APIs and tools required to create any persistent modern application. You can learn more on our website or Github repository.

Go and Test Our New Demos!

All the new demos are already available on Github and offer a one-click-deployment setup to your favorite hosting service, including Vercel, Netlify, and DigitalOcean.

💙 React TODO: https://github.com/appwrite/todo-with-react
💚 Vue TODO: https://github.com/appwrite/todo-with-vue
❤️ Angular TODO: https://github.com/appwrite/todo-with-angular
🧡 Svelte TODO: https://github.com/appwrite/todo-with-svelte

We Have Some Hidden Swags Waiting For You!

Our access credentials were recently "compromised", and someone tried to ruin our new and shiny demos 😉. They decided to leave behind 15 easter eggs 🥚 for you to discover. If you find them, submit a PR cleaning up that section of the code to claim some cool Appwrite Swag 🤩 (One PR per person across all the repos). You can track the number of claimed Easter Eggs using the badge at the top.

What’s Next?

You can learn more about the different Appwrite features or check out some of our latest Feature Spotlights:

If you’re new to Appwrite, you can try and install it. It will take you only 2.5 minutes. After you got yourself a copy of the Appwrite server, you can check some of our getting started guides for Web, Flutter, or Server, and visit our Discord community where we chat about Appwrite non-stop.

We really love our Github Stargazers 🤩. If you like what we're doing, head over to our Github repo and drop us a ⭐️

Appwrite 0.8 is Coming Soon and This is What You Can Expect 🚀

Eldad A. Fux — Fri, 26 Mar 2021 05:27:19 +0000

After launching v0.7 last month with the new Appwrite Cloud Functions and the Appwrite CLI, we are happy to share that Appwrite version 0.8 is nearing completion. We have prepared a list a list with some of the coolest features you can expect from the soon-to-be-released version.

Appwrite 0.8 will take the project one step closer to our anticipated release of Appwrite first stable release, version 1.0.

Anonymous Login 🕵️

It is important to consider the user experience when someone first comes to your application. The registration process can often prove to be a hurdle for users to use an application, especially if parts of the application are bound to an authentication process and hidden behind a login screen. Moreover, in today's world, the issue of privacy and data protection is a delicate one, especially because of new data privacy regulations, like GDPR and CPRA.

The anonymous login is used, allowing users to create an account - without providing personal information such as an email address, username, or password and convert it to a real account at a later stage.

JWT 🤖

By adding support for JWT authentication, developers can perform actions on behalf of their users and create a lot of new use-cases.

With the new JWT support combined with Cloud Functions and the Appwrite Server API, the ability to customize your backend workflows and create new scenarios in reaction to the user or Appwrite events is endless.

ARM Support 🧑‍💻

In order to keep up with the demands of ARM, all of our core containers now officially support the ARM ecosystem. This allows you to run Appwrite on Raspberry PI, Apple M1, AWS Graviton, and more. We aim to make Appwrite as tech agnostic as possible, and this matches very well with our self-hosted first approach, allowing Appwrite to run in any environment possible. And for all you Raspberry PI fans, yes, you could run appwrite on PI4, we're still working to allow all the features to be enabled, but it should be good to go. 😃

New Env Vars for Functions 🌩

Thanks to the community feedback, we have added some helpful environment variables to our Cloud Functions. From v0.8, every Cloud Functions will have access to the current project ID, user ID (if the function was triggered by an authenticated user), and a valid JWT. This will allow you to extend the Appwrite API easily and perform actions on behalf of your users from the function context.

New Image Preview Capabilities 🌠

Appwrite has advanced image delivery capabilities, including advanced image cropping and image optimization (WEBP). With the new version, we will introduce new capabilities to the image preview endpoint, including adding image borders, radius, and opacity. This will allow you to use Appwrite as a complete OSS alternative to other commercialized image serving solutions and is an excellent fit for integrating into applications that require high performant clients, and image serving has been an issue.

More Control Over Auth Methods 🔐

Giving you more control over what authentication methods are available and to what extent - we added more settings to the dashboard, which lets you configure your projects according to your needs.

The Root Account 🤴

In previous versions, the access to the Appwrite Console had to be configured by allowing specific Emails or IPs manually. Therefore the registration was open by default, and to prevent abuse, we added an option to limit the console to one root account. This will allow only a single administrative user. When a user has already signed-up, the console account creation endpoint will be blocked. This option will be enabled by default. You could still invite new members to join your project, but you won't have to worry about securing your console login before moving to a public host.

What's next? 💡

As we mentioned before, the Appwrite team is working hard to provide the stack with more cool features and stability required for Appwrite to run well in any production environment. These days, we focus on multiple big features released in our next releases, like Realtime capabilities and a GraphQL entry point.

We are also working on refactoring our database to allow you to choose between multiple different adapters and add custom DB indices. These changes are part of our ongoing efforts to allow developers using Appwrite to leverage their existing knowledge and run with confidence with the tools they already love.

Our new capabilities around custom DB indices will allow Appwrite to run in much bigger scale environments and are expected to result in a major performance boost when appropriately tuned.

Appwrite 0.7: Introducing Built-in Brotli Compression for Improved API Performance

Eldad A. Fux — Tue, 23 Feb 2021 16:32:03 +0000

The new Appwrite version introduces Brotli compression support for faster HTTP communication and optimized network usage.

Photo by Cris Ovalle on Unsplash

The new Brotli compression in Appwrite is optional, and you can control how you want to use it using your standard HTTP encoding headers. If your end client doesn’t support it, Appwrite will skip it automatically. The new compression support will continue to work alongside the classic gzip compression Appwrite already supported.

Got here, but you’re new to Appwrite? Appwrite is an end-to-end backend server packaged as a set of Docker micro-services that are really easy to set up and learn. Appwrite provides developers with all the core APIs, tools, and SDKs required to build a modern app. Appwrite can save you lots of time and is pretty fun to use.

What is Brotli?

Brotli is also a compression algorithm like GZIP. It is developed and maintained by Google and is best used for text compression. The reason being, it uses a dictionary of common keywords and phrases on both client and server-side and thus gives a better compression ratio. In version 0.7 of Appwrite, you can enable the Brotli compression for any JSON or text-based response. Actually, the new Brotli support has significantly improved the Appwrite dashboard loading times.

Client Support

As of 2021, Brotli is supported by all major web browsers, but if you’re using the Appwrite server API and your HTTP client supports Brotli, you can use it to improve performance and reduce your network bandwidth.

What’s Next?

You can learn more about the different Appwrite features or check out some of our latest Feature Spotlights:

We also really like Github stars, if you like what we do you go over to our Github repo and give us one ⭐️.