DEV Community: kodumbeats

Appwrite Loves Open Source: Why I Chose To Support Lazygit & Lazydocker

kodumbeats — Wed, 23 Jun 2021 17:29:52 +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 10,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.

We're building Appwrite, an open-source Backend-as-a-Service (BaaS), packaged as a set of Docker microservices, to give developers of any background the tools necessary to build modern apps quickly and securely. Come chat with us on Discord.

Git and Docker Are Hard

I like terminal apps for the same reason I prefer Vim in a tmux session over VSCode: I need a simple, fast interface to complete my job quickly. Docker 🐋 and Git are ubiquitous in the development world, but just like Vim, take a lot of effort to learn all of the power they offer. In short, git and docker are hard. 🤕 What’s a rebase? What’s that command to shell into a container? How do I resolve a merge conflict? If StackOverflow is any indication, these tools are confusing at least.

Docker and Git are wonderfully powerful CLI tools, but I have to remember which command to use. 🤔 Even more, I only have access to the information I specifically request, which slows my workflow. To assist in development, I reach for the wonderful lazygit and lazydocker, both developed by Jesse Duffield. They’re both written in Go and each provide a mouse-friendly terminal interface 🖥️ to work with git repositories and docker environments. They’re most impressive in action:

Lazygit

Lazydocker

Both of these products have helped me save loads of time ⌛ and effort while traveling my path as a developer. If you're new to git or docker, or are just a bit lazy like I am, check out these products for yourself.

Open-source Software (OSS) Is Hard

Since Appwrite is open-source, we understand the challenges that OSS projects face. If you fall in love ❤️ with an open-source project (like we have), consider checking out ways to contribute. Most OSS projects happily accept contributions in their own way, whether they be in the form of commits, bug 🐛 reports, advocacy, or even monetary 💰 support. If you love lazygit and/or lazydocker, consider joining us as a GitHub Sponsor. Or, if you're interested in contributing to Appwrite, check out our contribution guide.

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:

#30DaysOfAppwrite: Docker Swarm Integration

kodumbeats — Fri, 28 May 2021 12:43:54 +0000

Intro

#30DaysOfAppwrite is a month-long event focused on giving developers a walk-through of all of Appwrite's features, starting from the basics to more advanced features like Cloud Functions! Alongside we will also be building a fully-featured Medium clone to demonstrate how these concepts can be applied when building a real-world app. We also have some exciting prizes for developers who follow along with us!

Deploy with Docker Swarm

Welcome to Day 28 👋 ! Your app has become an overnight success. Everyone is using your app, from celebrities to your friends. You never anticipated this and found yourself in a situation where your app isn't able to keep up with the overwhelming number of requests. Fret not! Appwrite was designed with exactly this in mind. As you already know, Appwrite is designed as a set of stateless microservices with scalability as one of our top priorities! While there are many ways to achieve scalability with lots of orchestration services, we will take a look at one of the most intuitive ones. Today, we're going to discuss horizontally scaling Appwrite with Docker Swarm.

What is Docker Swarm?

Docker Swarm is a container orchestration tool built right into the Docker CLI, which allows us to deploy our Docker services to a cluster of hosts instead of just the one allowed with Docker Compose. This is known as Swarm Mode, not to be confused with the classic Docker Swarm that is no longer being developed as a standalone product. Docker Swarm works great with Appwrite as it builds upon the Compose specification, meaning we can use Appwrite's docker-compose configuration to deploy to a swarm (with a few changes here and there). Its simplicity allows us to get started right away!

Deploying Appwrite with Swarm

Prerequisites

For this example, we'll need the following:

Docker is installed on each of your hosts.
The following ports must be open between your hosts:
- TCP port 2377 for cluster management communications
- TCP and UDP port 7946 for communication among nodes
- UDP port 4789 for overlay network traffic
The "leader" server has Appwrite's Compose files.

Creating the Swarm

We'll create the swarm on whichever host we want to be the "leader." Initialize the swarm with:

docker swarm init

Which should output:

Swarm initialized: current node (7db8w7aurb7qrhvm0c0ttd4ky) is now a manager.

To add a worker to this swarm, run the following command:

docker swarm join --token SWMTKN-1-0wagrl3qt4loflf9jcadj8gx53fj2dzmbwaato7r50vghmgiwp-cvo3jflyfh2gnu46pzjtaexv2 your.ip.addr.ess:2377

Which should output:

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Now, let's run the provided command on our other system(s) - we're looking for the message This node joined a swarm as a worker. Once that's complete, we can go back to the "leader" host and can see both systems with:

docker node ls

Which should display the following:

ID                            HOSTNAME          STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
yfl7xsy5birfbpiw040chef67     appwrite          Ready     Active                          20.10.6
op3nf4ab6f5v1lulwkpyy2a83 *   appwrite_leader   Ready     Active         Leader           20.10.6

Update `docker-compose.yml`

Now that the swarm is ready, we'll need to make some changes to docker-compose.yml to make it Swarm-compatible.

Volumes in a Docker swarm aren't shared between hosts by default, so we'll use NFS to share directories between the hosts. Shared data can be accomplished in a variety of ways, but this is the simplest to get started. To do so, we'll replace all the named volumes with NFS mounts. DigitalOcean has a great guide on configuring NFS, so refer to that guide for more details.

We're going to configure these NFS volumes on our "leader" host and share those folders with other hosts in the swarm. We'll use the following directories to replace the Docker volumes and share via NFS:

mkdir -p /nfs/{mariadb,redis,cache,uploads,certificates,functions,influxdb,config}

Next, we'll create the corresponding /nfs directories on the second host (with the same command as above), where we'll mount the NFS share from the "leader" host.

Now, replace each named volume in docker-compose.yml with its corresponding NFS directory:

# - appwrite-uploads:/storage/uploads:rw
- /nfs/uploads:/storage/uploads:rw

# - appwrite-certificates:/storage/certificates:rw
- /nfs/certificates:/storage/certificates:rw

Then, we'll need to remove the depends_on and container_name stanzas from docker-compose.yml, as they aren't supported by Docker Swarm.

Overlay Networks

Docker uses overlay networks to connect each node together in the swarm, so containers can communicate with each other regardless of where it is deployed. We could create the overlay network with the Docker CLI, but instead, let's capture this change in docker-compose.yml:

networks:
  gateway:
  appwrite:
    driver: overlay

Ready to Deploy

Once everything is in place, we'll set our Appwrite environment variables and deploy them to the swarm with:

docker stack deploy -c <(docker-compose config) appwrite

If you see docker-compose config warnings, try upgrading the Compose version to version: '3.8' at the head of docker-compose.yml to utilize the latest Compose specification.

Our microservice workers rely on Redis to handle pub/sub, so you may see them restart until the stack self-heals. Once everything is deployed, you can check the status of the services with:

$ docker service ls
ID             NAME                                    MODE         REPLICAS   IMAGE                     PORTS
ktfto6dap451   appwrite_appwrite                       replicated   1/1        appwrite/appwrite:0.8.0   
hazw2csk4epd   appwrite_appwrite-maintenance           replicated   1/1        appwrite/appwrite:0.8.0   
fshro0zn8iw6   appwrite_appwrite-schedule              replicated   1/1        appwrite/appwrite:0.8.0   
jep5n0gnmvy6   appwrite_appwrite-worker-audits         replicated   1/1        appwrite/appwrite:0.8.0   
oiftp636aq6v   appwrite_appwrite-worker-certificates   replicated   1/1        appwrite/appwrite:0.8.0   
tlu7yxvtrr0r   appwrite_appwrite-worker-deletes        replicated   1/1        appwrite/appwrite:0.8.0   
rda2kspenbzr   appwrite_appwrite-worker-functions      replicated   1/1        appwrite/appwrite:0.8.0   
im800v9tct4n   appwrite_appwrite-worker-mails          replicated   1/1        appwrite/appwrite:0.8.0   
ry0u3v726o8h   appwrite_appwrite-worker-tasks          replicated   1/1        appwrite/appwrite:0.8.0   
734y2mr6gzkc   appwrite_appwrite-worker-usage          replicated   1/1        appwrite/appwrite:0.8.0   
bkotuk5kwmxx   appwrite_appwrite-worker-webhooks       replicated   1/1        appwrite/appwrite:0.8.0   
ff6iicbmf5my   appwrite_influxdb                       replicated   1/1        appwrite/influxdb:1.0.0   
892923vq96on   appwrite_mariadb                        replicated   1/1        appwrite/mariadb:1.2.0    
uw3l8bkoc3sl   appwrite_redis                          replicated   1/1        redis:6.0-alpine3.12      
ulp1cy06plnv   appwrite_telegraf                       replicated   1/1        appwrite/telegraf:1.0.0   
9aswnz3qq693   appwrite_traefik                        replicated   1/1        traefik:2.3               *:80->80/tcp, *:443->443/tcp

I've included my completed Compose file in a GitHub gist for reference.

Configuration

Docker Swarm has a lot of configuration options available, so we won't cover everything here. Instead, let's talk about some of the most useful stanzas when configuring your deployment.

Replicas

Since Appwrite is largely stateless, you can scale each service up or down individually, depending on your app's needs. For example, we may want to have two Functions workers so we can handle twice as many function executions:

deploy:
  replicas: 1

We can check that the replica was deployed by filtering for the specific service:

$ docker service ls --filter name=appwrite_appwrite-worker-functions 
ID             NAME                                 MODE         REPLICAS   IMAGE                     PORTS 
rda2kspenbzr   appwrite_appwrite-worker-functions   replicated   2/2        appwrite/appwrite:0.8.0

Node Constraints

Docker Swarm allows us to control where containers deploy in the swarm using placement constraints. For example, we could configure Traefik or MariaDB to just reside on a manager node with the following added to docker-compose.yml:

deploy:
  placement:
    constraints: [node.role == manager]

What's Next

We just covered the tip of the iceberg. For further reading on running Appwrite in a Docker Swarm:

Docker's admin guide has a lot of extra information about how to manage nodes in a swarm and some considerations for production.
Docker secrets and Docker configs can be used to more easily control and distribute sensitive data through the swarm.

Credits

We hope you liked this write-up. You can follow #30DaysOfAppwrite on Social Media to keep up with all of our posts. The complete event timeline can be found here

Feel free to reach out to us on Discord if you would like to learn more about Appwrite, Aliens, or Unicorns 🦄. Stay tuned for tomorrow's article! Until then 👋

#30DaysOfAppwrite : Appwrite for Production

kodumbeats — Thu, 27 May 2021 12:38:54 +0000

Intro

Appwrite is an open-source, self-hosted Backend-as-a-Service that makes app development easier with a suite of SDKs and APIs to accelerate app development. #30DaysOfAppwrite is a month-long event focused on giving developers a walkthrough of all of Appwrite's features, starting from the basics to more advanced features like Cloud Functions! Alongside we will also be building a fully-featured Medium clone to demonstrate how these concepts can be applied when building a real-world app. We also have some exciting prizes for developers who follow along with us!

Appwrite for Production

Welcome to Day 27 👋. Now that we've covered many of the capabilities of Appwrite, we should discuss running Appwrite in production once your app is finally ready for users.

First and foremost, good security is a moving target. Appwrite provides a suite of APIs that abstracts many security requirements of your application, but hosting software online means exposing a computer to the internet. While we can't cover everything, let's discuss some security best practices when running Appwrite in production.

The Server

Before discussing the steps to run Appwrite in production, we need to talk about the system on which Appwrite will run. These tips assume you're running Appwrite on a Linux-based server, but the principles apply to any operating system.

Updates

Most security breaches occur on systems that run out-of-date software versions with security vulnerabilities. The problem is understandable - it's hard to keep up with system updates. Running updates on a cron schedule isn't the best either, as security updates are best installed immediately. Use tools like Ubuntu's unattended-upgrades and Fedora's dnf-automatic packages to run with the latest updates for your software.

Firewall and SSH

A security best practice is a deny-by-default security policy - we should only give explicit access to the services we want. Appwrite considers this in its default configuration: the only service exposed to the outside world is what we need, the Traefik proxy. So, if Appwrite is the only service we want to expose on the server publicly, we can use firewall tools to block access to any other unused ports.

If you use SSH to administer your system, don't forget to leave that open in your firewall! SSH is considered a private service, meaning that it should be publicly accessible, but only to authorized accounts. The best practice is to use cryptographic tools like SSH keys instead of passwords, as they're much, much harder to falsify.

Securing Appwrite

Now, let's discuss setting up Appwrite for production.

Environment Variables

You can easily configure Appwrite for production with the many environment variables that it offers. The following variables should be set in the hidden .env file in your appwrite installation directory when deploying for production:

_APP_ENV: Change to production.
_APP_OPTIONS_ABUSE: Enables abuse checks and rate-limiting for the API. Set to enabled.
_APP_OPTIONS_FORCE_HTTPS: Forces connections to use HTTPS for secure data transfer. Set to enabled.
_APP_OPENSSL_KEY_V1: This is the secret used to encrypt information like sessions and passwords. Please change this to something secure and random, and keep it safe and backed up.
_APP_DOMAIN: Set this to your domain name for Appwrite to auto-generate an SSL certificate.

Restrict Console Access

Three environment variables are available to restrict access to the Appwrite console:

_APP_CONSOLE_WHITELIST_EMAILS
_APP_CONSOLE_WHITELIST_IPS
_APP_CONSOLE_WHITELIST_ROOT

Set the _ROOT var to enabled if you only want a single account to have access to the console. You can restrict access to specific email and IP addresses with their respective environment variables for multiple users.

Antivirus

For production, you can enable clamav scanning of uploaded files for any known malicious objects. Set _APP_STORAGE_ANTIVIRUS to enabled and uncomment the service in docker-compose.yml to use this feature. Don't forget to also uncomment clamav in the depends_on section of the main appwrite service.

Functions

Cloud Functions can be customized to suit the needs of your production system, largely for controlling resources available to Function executions:

_APP_FUNCTIONS_CPUS: The maximum number of CPU cores that Cloud Functions can use.
_APP_FUNCTIONS_MEMORY: The maximum memory available to Cloud Functions (in megabytes).
_APP_FUNCTIONS_CONTAINERS: The maximum number of containers Appwrite keeps alive defaults to 10. Increase this number to increase the number of warm functions.
_APP_FUNCTIONS_RUNTIMES: A list of available runtimes for new Cloud Functions.

All Appwrite environment variables can be found in our docs.

Credits

We hope you liked this write-up. You can follow #30DaysOfAppwrite on Social Media to keep up with all of our posts. The complete event timeline can be found here

Feel free to reach out to us on Discord if you would like to learn more about Appwrite, Aliens, or Unicorns 🦄. Stay tuned for tomorrow's article! Until then 👋

Appwrite 0.8: ARM Support

kodumbeats — Sat, 22 May 2021 06:27:38 +0000

Appwrite 0.8 brings support for ARM64 processors - you can now install Appwrite on Amazon's Graviton2 instances, Apple M1 systems (without Rosetta 2), Raspberry Pi 4 SoCs, or any other 64-bit ARM device! To appreciate ARM's position in today's computing, let's take a brief tour of the history of CPU architectures.

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. We love chatting about Appwrite, Aliens 👽 or Unicorns 🦄 over at Discord.

Beginning with the 8086

Photo by Thomas Nguyen - Own work, CC BY-SA 4.0,

The Intel 8086 processor was released in 1978 and was carried into households with the widespread success of the IBM 5150 Personal Computer, the PC. Intel then built on the success of the 8086 with following processors: the 80286, 80386, 80486, and more, all the way through Pentium and beyond. The set of instructions used to command these processors, known now as "x86", is still supported on chips today - any assembly program written for the 8086 will run out-of-the-box on modern Intel processors, albeit much, much, much faster.

Ever wonder how AMD is able to make x86-compatible processors without lawsuits from Intel? The legal landscape around the x86 architecture is fascinating - check out this commentary from Harvard Law to learn more.

The first "x86" instruction sets supported very basic processor-level operations: reading/writing from memory, basic arithmetic, and control flow logic, to name a few. To meet ever-growing computing demands, Intel needed to expand the x86 instruction set to handle more complex operations like handling memory in chunks, complicated maths like square root, logarithms, and trigonometry, and more. While the instruction set grew, so too did the power requirements. The computing industry was fine with power consumption, so long as their computers ran faster, that is, until power consumption mattered - the era of smartphones.

The Tale of Two ARMs

Smartphones require a specific balance of power consumption and performance, and x86 processors didn't fit the bill - the complex x86 instructions required extra electricity, logic gates, and silicon surface area, and mobile computing had opposite requirements. RISC (Reduced Instruction Set Computers) processors took a more specialized approach: only include the basic instructions required for a modern computer, and make those instructions highly optimized.

ARM, an English semiconductor company, designs RISC instruction sets and licenses them to manufacturers to handle production.You probably recognize a few of these manufactors: Samsung, Broadcom, Qualcomm, and NVidia, to name a few. These companies handle the manufacturing and distribution of ARM-based systems, including smartphones, tablets, smart TVs, washing machines, cars, printers, and so much more.

Low-power processors aren't just for mobile/IoT devices anymore, nor are they less capable than x86 computers. Most notably, the Apple M1 (ARM-based) has made a big splash with ARM now powering iPads, Macbooks, Mac Minis, and now iMacs, with other manufacturers set to follow in their footsteps. Amazon has also been a pioneer of ARM in the datacenter - Amazon employs a 64-core(!) Neoverse N1 ARM processor in their Graviton2 virtual servers.

What's Next?

You can get started with your favorite 64-bit ARM device now - follow the installation instructions to get started. The Appwrite community is very excited about Appwrite apps which are now possible thanks to Appwrite on RPi (especially me), and we've installed it on a variety of operating systems: PiOS, Ubuntu, and BalenaOS. You can see Appwrite running on a Raspberry Pi 4 2GB with Ubuntu 20.04:

What are you most excited to build? Do you have any homelab projects which just became easier thanks to Appwrite on ARM? Let us know on Discord, Twitter, Dev.to, or anywhere you find a friendly Appwriter. :) Also, the awesome-appwrite repo keeps growing with new tutorials, demos, videos, and more!

Announcing Appwrite 0.8 - an open-source, self-hosted BaaS

kodumbeats — Wed, 19 May 2021 16:11:20 +0000

We're incredibly excited to announce the release of Appwrite 0.8, packed with a ton of cool new features like JWT support, ARM support, Anonymous Login, and more! Last month, we gave a sneak peek of some of the changes, and we're back today to keep you waiting no longer. Let's dive 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.

Anonymous Login and JWT 🔐

Not every app needs users to create an account right away. With Anonymous Login, save sessions without asking for email addresses, and convert those users to registered accounts later with ease. The implementation is just like creating a normal user session via the createSession method:

let sdk = new Appwrite();

sdk
    .setEndpoint('https://[HOSTNAME_OR_IP]/v1') // Your API Endpoint
    .setProject('5df5acd0d48c2') // Your project ID
;

let promise = sdk.account.createAnonymousSession();

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

Also, if you've ever needed to act as a user from a server SDK, Appwrite now supports authentication via JSON Web Tokens (JWT). This change allows Appwrite to work with the server-side rendering capabilities of frameworks like Next.js, Nuxt.js, and Gatsby.js, as well as unlock user actions from server-side SDKs.

First, a JWT is created for the user from a Client SDK:

appwrite
    .account.createJWT()
    .then(function (response) {
        console.log(response);
    }, function (error) {
        console.log(error);
    });

Then, the JWT is used to act on behalf of the user server-side:

const sdk = require('node-appwrite');

let client = new sdk.Client();

client
    .setEndpoint('https://[HOSTNAME_OR_IP]/v1') // Your API Endpoint
    .setProject('5df5acd0d48c2') // Your project ID
    .setJWT('919c2d18fb5d4...a2ae413da83346ad2') // Your JWT

ARM Support 🦾

The ARM ecosystem has been booming since Apple's M1 processors landed in their new lineup of devices. Starting with 0.8, install Appwrite on your favorite 64-bit ARM device, from Amazon Graviton2 down to the Raspberry Pi 4! [1] ARM support falls in line with our mission to make Appwrite technology agnostic, and we're excited to hear all of the new places where Appwrite can run.

To celebrate this milestone, we have ARM systems to give away as a part of #30DaysofAppwrite! 🥳 Through the month of May, we're building a Medium.com blog clone to demonstrate how easy the developer experience is with Appwrite, and we invite you to build alongside us. Eligible submissions get some cool 😎 swag, and the best projects will receive Raspberry Pi 4 development kits. 😍

[1] For both Graviton2 servers and Raspberry Pis, we recommend at least 2GB of RAM for the best Appwrite experience.

Control your Console 🖥️

We've updated the console with a few new goodies. First, if you enable the new "root" account setting, only a single admin account can be created on your Appwrite server. If you need to share access to the Appwrite console, you can restrict account creation to specific IP addresses with the _APP_CONSOLE_WHITELIST_IPS environment variable.

Additionally, Appwrite 0.8 brings new settings to users - now, you can choose which of our growing authentication methods you'd like to use for your apps: email/password login, anonymous login, JWT auth, and more!

New Cloud Function Runtimes 🏃

Appwrite 0.8 introduces Python 3.9, Deno 1.8, and Dart 2.12 as new runtimes for Cloud Functions. Upgrade existing functions or write new ones! If you're using Cloud Functions in a cool way, let us know on Discord.

Slimmer and Faster ⏩

You'll notice Appwrite 0.8 is a bit slimmer on system resources out-of-the-box. We found that the SMTP and antivirus services weren't helping new developers, so we've toggled off ClamAV and the included SMTP server for development. Because of these changes, we have been able to reduce our minimum requirements to 1GB of RAM (though we recommend 2GB for the better experience).

We also updated our codebase to take advantage of the increased performance of some of our under the hood technologies. Based on our testing, we're seeing improved performance of about 8% compared to previous Appwrite versions 🚀

Breaking Changes ⚒️

Before you upgrade your Appwrite server to 0.8, check out the breaking changes that were introduced to see if you need to update any code.

The deleteUser method in the Users API has been renamed to delete to remain consistent with the rest of the API.
Only logged in users with active sessions can execute functions. If your app relies on this behavior, check out Anonymous Login.
Only the user who triggers an execution gets access to the relevant execution logs.
The createMembership method has a new rate limit of 10 requests per 60 minutes per IP address.
The environment variable _APP_FUNCTIONS_ENVS has been renamed to APP_FUNCTIONS_RUNTIMES.
Several function execution environment variables have been renamed:
- APPWRITE_FUNCTION_EVENT_PAYLOAD is now APPWRITE_FUNCTION_EVENT_DATA
- APPWRITE_FUNCTION_ENV_NAME is now APPWRITE_FUNCTION_RUNTIME_NAME
- APPWRITE_FUNCTION_ENV_VERSION is now APPWRITE_FUNCTION_RUNTIME_VERSION

And More! 😍

That's not all! To get all the details on Appwrite 0.8, 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 Repo for more details. Also, our awesome-appwrite repo 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 neighborhood Appwrite.

#30DaysofAppwrite: SSL Certificates

kodumbeats — Thu, 06 May 2021 12:39:49 +0000

Intro

Appwrite is an open-source, self-hosted Backend-as-a-Service that makes app development easier with a suite of SDKs and APIs to accelerate app development. #30DaysOfAppwrite is a month-long event focused on giving developers a walkthrough of all of Appwrite's features, starting from the basics to more advanced features like cloud functions! Alongside we will also be building a full-featured Medium clone to demonstrate how these concepts can be applied when building a real-world app. We also have some exciting prizes for developers who follow along with us!

SSL Certificates in Appwrite

Welcome to Day 6 👋 of #30DaysofAppwrite. Today, we're going to discuss how to secure your Appwrite API traffic with SSL certificates: what they do, how to get them, and how to troubleshoot SSL problems in Appwrite.

What is SSL?

SSL is a security protocol that cryptographically provides authentication for computers communicating with each other on the Internet, improved and later replaced by TLS years ago. Despite TLS replacing SSL, both names are commonly used to refer to the same process: secure HTTP sessions with certificate keypairs (fancy text files) signed by a Certificate Authority, CA for short.

Trusting Certificates

The TLS protocol provides cryptographically unique keypairs that not only provide encryption, but also include domain, host, and organization information in the certificate. However, since TLS technology is open-source, anyone can operate as a CA and sign certificates. To keep users secure, computers and browsers ship with lists of pre-vetted CAs to trust automatically[1]. Websites that use certificates issued by these trusted sources get the all-important lock🔒 next to their domain in the URL bar. Websites without them, however, face the dreaded Warning: Potential Security Risk Ahead.

[1] For the curious, here's Mozilla's list of trusted sources for Firefox.

The process of becoming a universally trusted CA on these lists can be costly, which is why organizations like IdenTrust and DigiCert charge money for their services. These companies have the resources and knowledge to provide a range of security guarantees, protecting financial institutions, governments, militaries, and more. Though, I'm assuming that you're not starting a bank, and don't have the funds to get a commercial SSL certificate. Where are the free options?

Welcome, Let's Encrypt

Let's Encrypt is a free, automated, and trusted Certificate Authority that aims to provide for a safer, more secure Internet. Appwrite uses their popular certbot tool under the hood to automatically handle certificate generation and renewal, so you can focus on building your app.

Securing Appwrite with HTTPS

To illustrate by example, let's assume I've installed Appwrite on a VPS and bought the domain example.com for my next Appwrite-powered project. What steps are necessary to serve my app on example.com?

Domain records

Your registrar ultimately has control over your domain (our example.com), so we'll need to start there to point the domain at the IP address of your VPS. For this, we can use a DNS A record. Adding DNS records to your domain varies by registrar, so check out our docs on Custom Domains for a bunch of helpful links and more specific instructions.

SSL Certificates in Development

As mentioned before, all the required technology to generate your own SSL certificate is open-source, but it just isn't globally trusted by browsers. That's totally fine for development (assuming you trust yourself 😂) - Appwrite provides a self-signed certificate out-of-the-box (via the Traefik proxy), so your work is immediately encrypted. To do this, we need to let Appwrite know we're trying to use the self-signed certificate. Our SDKs all accept a client.setSelfSigned() method to handle this. Here's an example using our Web SDK:



import * as Appwrite from "appwrite";

let client = new Appwrite();

client
    .setEndpoint('https://example.com/v1')
    .setProject('5df5acd0d48c2')
    .setSelfSigned()
;

SSL Certificates in Production

Now, say you're past the development stage for example.com, and you're ready to move to production. The following is required for Appwrite to issue a production-ready SSL certificate (with the lock🔒):

Appwrite in production mode via _APP_ENV=production
A valid email set via _APP_SYSTEM_SECURITY_EMAIL_ADDRESS
A public-facing domain set via _APP_DOMAIN
Traefik (proxy webserver) listening on port 80
Remove references to client.setSelfSigned

Our docs on Appwrite environment variables are a good reference when changing Appwrite's configuration.

To apply new environment variables, run:



docker-compose up -d

This is where the Appwrite Certificates worker takes the reigns, calling certbot to generate a certificate signed by Let's Encrypt. The worker then stores the certificates in a Docker volume for persistence and queues up a job to check the certificate renewal periodically (Let's Encrypt certificates are valid for 90 days by default).

Debugging

The first place to look for any certificate problems is the Certificates worker. You can check the service logs with:



docker-compose logs appwrite-worker-certificates

If you've configured your domain after your Appwrite server has started, you can re-trigger the Certificates worker by restarting Appwrite:



docker-compose restart appwrite

If you still can't figure it out, you can find help on Discord.

Credits

We hope you liked this write-up. You can follow #30DaysOfAppwrite on Social Media to keep up with all of our posts. The complete event timeline can be found here

Feel free to reach out to us on Discord if you would like to learn more about Appwrite, Aliens or Unicorns 🦄. Stay tuned for tomorrow's article! Until then 👋

Appwrite Releases Open Source Documentation

kodumbeats — Wed, 10 Mar 2021 11:01:30 +0000

At Appwrite, we're focused on creating the best developer experience possible, which is why we build tools that are easy to learn. To that end, we're thrilled to announce that our docs are now open-sourced, available on GitHub!

We're building Appwrite, an open-source Backend-as-a-Service (BaaS), packaged as a set of Docker microservices, to give developers of any background all of the tools necessary to build a modern apps quickly and securely.

Docs as Code

Appwrite uses the Utopia Framework under the hood, which encourages a declarative approach to building APIs. We explicitly declare route metadata - from labels to abuse limits to parameter definitions - as a part of our codebase, allowing us to procedurally generate not only the API specification, but also SDKs and code examples in multiple programming languages.

For example, the parameter descriptions on the listCollections method are used directly in the endpoint documentation:

App::get('/v1/database/collections')
    ->desc('List Collections')
    ->label('sdk.method', 'listCollections')
    ->label('sdk.description', '/docs/references/database/list-collections.md')
    ->param('search', '', new Text(256), 'Search term to filter your list results. Max length: 256 chars.', true)
    ->param('limit', 25, new Range(0, 100), 'Results limit value. By default will return maximum 25 results. Maximum of 100 results allowed per request.', true)
    ->param('offset', 0, new Range(0, 40000), 'Results offset. The default value is 0. Use this param to manage pagination.', true)

Our SDK Generator does the heavy lifting of creating code examples for each API endpoint with Twig templates. The above API route metadata creates the following Node.js code:

const sdk = require('node-appwrite');

// Init SDK
let client = new sdk.Client();
let database = new sdk.Database(client);

client
    .setEndpoint('https://[HOSTNAME_OR_IP]/v1') // Your API Endpoint
    .setProject('5df5acd0d48c2') // Your project ID
    .setKey('919c2d18fb5d4...a2ae413da83346ad2') // Your secret API key
;

let promise = database.listCollections();

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

Better Together

Appwrite is a remote-first, international team, so we appreciate the strength of diverse opinions. With open-source docs, our community can lend its wide expertise to help us improve any resource that lacks clarity, detail, or brevity (or has spelling mistakes). Development tools are only as strong as their technical documentation, and we've set out to make ours the best.

Getting Started

If you're interested in improving Appwrite, check out the contribution guide on GitHub. We're always happy to welcome new members to our growing Appwrite community.

DEV Community: kodumbeats

Appwrite Loves Open Source: Why I Chose To Support Lazygit & Lazydocker

Git and Docker Are Hard

Lazygit

Lazydocker

Open-source Software (OSS) Is Hard

Learn more about Appwrite

#30DaysOfAppwrite: Docker Swarm Integration

Intro

Deploy with Docker Swarm

What is Docker Swarm?

Deploying Appwrite with Swarm

Prerequisites

Creating the Swarm

Update docker-compose.yml

Overlay Networks

Ready to Deploy

Configuration

Replicas

Node Constraints

What's Next

Credits

#30DaysOfAppwrite : Appwrite for Production

Intro

Appwrite for Production

The Server

Updates

Firewall and SSH

More Reading

Securing Appwrite

Environment Variables

Restrict Console Access

Antivirus

Functions

Credits

Appwrite 0.8: ARM Support

Beginning with the 8086

The Tale of Two ARMs

What's Next?

Announcing Appwrite 0.8 - an open-source, self-hosted BaaS

Anonymous Login and JWT 🔐

ARM Support 🦾

Control your Console 🖥️

New Cloud Function Runtimes 🏃

Slimmer and Faster ⏩

Breaking Changes ⚒️

And More! 😍

#30DaysofAppwrite: SSL Certificates

Intro

SSL Certificates in Appwrite

What is SSL?

Trusting Certificates

Welcome, Let's Encrypt

Securing Appwrite with HTTPS

Domain records

SSL Certificates in Development

SSL Certificates in Production

Debugging

Credits

Appwrite Releases Open Source Documentation

Docs as Code

Better Together

Getting Started

Extra Reading

Update `docker-compose.yml`