DEV Community: Aditya Oberai

Stop Vibe Coding Every Damn Time!

Aditya Oberai — Mon, 02 Jun 2025 10:00:00 +0000

These days, the hype around vibe coding feels limitless. Tools that promise to turn your ideas into apps with nothing more than a chat prompt are everywhere. But back in March this year, I came across a tweet from a developer who discovered that one of those tools, Lovable, was exposing a user's Supabase API key. While it was a publishable API key, it had no permissions or restrictions, and the developer was able to access all the app's data without authentication, just by looking at the public build.

This is not innovation. This is a security breach waiting to happen.

Screenshot of a tweet

This is what happens when people lean too hard on the vibe. They build software by instinct, skip fundamentals, and trust that the tool knows best. But when you are shipping products that handle real data, real users, and real consequences, vibes alone will not cut it.

Welcome to 2025, where AI code-generation tools can get you 80 percent of the way there. And yet, so many early-career developers are building software like they are writing poetry at an open mic. No structure, no planning, no understanding. Just vibes. It’s high time we start fixing that!

Are Vibe Coding And AI-Assisted Coding The Same Thing?

First, let’s clear the air. Vibe coding is not the same as using an AI assistant.

Vibe coding is what happens when you build software without understanding how anything works, relying entirely on tools to fill in the gaps. You feed ChatGPT a vague prompt, drag in some randomly generated code blocks, wire up a few buttons, and hope it works. You ship without testing. You copy code you don’t understand. You build with vibes, not logic.

AI-assisted coding, on the other hand, is intentional. You still plan your features. You still understand how your system fits together. You just move faster because you’ve got an AI pair programmer who helps with boilerplate, explains confusing concepts, and suggests things you were going to write anyway.

Image generated using ChatGPT

The difference is in the mindset. AI-assisted developers are still the architects, while vibe coders hope the house stands because someone else drew the blueprint.

The Basics Still Matter

Even with AI, you still need to be a developer. If you’re not doing these things, please start today!

#1: Learn What You’re Building

Wanting to skip the learning process before building is the number one reason for the sloppily generated code currently available. It is precisely how developers lose all control over what they are building.

If you’re building an authentication system, you can’t not learn what tokens are, how sessions work, and why storing passwords in plaintext is a terrible idea. If you’re calling APIs, you must understand how requests are structured, what status codes mean, and how to handle errors gracefully. If you’re storing data, you should know how relational and NoSQL databases differ, when to use indexes, and what trade-offs come with each schema decision.

AI can help you write the code, but it can’t teach you to care. That part is on you. And in this case, to care is also to control. Every decision you delegate without understanding becomes a potential landmine waiting to explode (maybe not today, but definitely someday!)

#2: Pause and Assess

Before you open Cursor, start wiring up a UI, or churning out an API, just pause and ask yourself:

What am I actually trying to build?

Can I describe the core flow of this feature out loud or on paper?

Is there a simpler solution hiding behind the flashy one?

Every minute spent thinking before you build will save you ten debugging later. That pause could be the difference between launching a feature that works and shipping one that silently breaks user data in production. Sometimes, the best code is no code (or just a well-placed conditional). But you won’t realize that if you rush to prompt before you plan.

Image generated using ChatGPT

#3: Plan Before You Code

Design still matters, now more than ever. Start outlining your features, sketching out your user journeys, and writing pseudocode if that helps you structure your logic.

Even a basic plan, a few bullets on what the function needs to do, can guide your AI assistant to better output. If you just prompt “build me an upload feature”, the results will vary wildly. But if you’ve already planned: “I need to let users upload PDF files up to 10MB, store them in an S3 storage bucket, and tag them by user ID”, now you’ve got a little more clarity than before (and you still need more but hey, it’s a start).

Think about how data flows through your app, how users interact with it, and where things might break. These are the habits that turn junior developers into senior ones. AI can write snippets, but it can’t architect systems. That’s still your job.

#4: Prompt Better

AI is not a mind-reader. Vague prompts get vague answers. And vague answers lead to broken features.

You have to be specific. Mention your tech stack: React with Express backend, or Python using FastAPI. Define the scope: Only show me the server-side handler, I’ll wire up the frontend. Include constraints: File size should be under 5MB, and use S3-compatible storage. If something doesn’t work, you must refine your prompt instead of blindly retrying. Break down the problem. Iterate like you would with a human teammate.

And always test what it gives you. Don’t assume it’s correct. Run the code. Read the output. Check for edge cases. The better your prompt, the better your result (and the more you’ll learn in the process). Prompting well is a skill. The sooner you treat it like one, the faster you grow.

Use Tools as Collaborators, Not Crutches

AI isn’t magic. It’s a junior developer who works fast but needs direction. So start treating it like one. That means you:

Review everything it gives you

Test like it was written by a stranger (because it was)

Ask it to explain things, but still go read the docs

You cannot use these tools to avoid thinking, only to move faster after you’ve thought things through. Because the goal isn’t to ship fast. The goal is to ship things that don’t explode.

AI tools are here to stay. And that’s great. But if you’re a developer, especially early in your career, you don’t get to opt out of learning. Not if you want to build things that last. So stop vibe coding every damn time. Pause. Think. Prompt intentionally. Learn constantly.

Code like you mean it.

Image generated using ChatGPT

Improve your Appwrite developer experience with dev keys

Aditya Oberai — Thu, 22 May 2025 12:42:37 +0000

When building applications with Appwrite, developers often need a way to test and debug services repeatedly over short periods. Sometimes, this can become a hassle, as Appwrite enforces strict rate limits on client apps to prevent abuse. Developers needed a way to bypass these rate limits in their test environments and CI/CD workflows to ensure the robustness of their app functionalities.

And this is the exact problem dev keys are here to solve!

What are dev keys?

Dev keys are a type of secret used by Appwrite's client SDKs. They allow the developer to bypass any rate limits enforced by Appwrite and suppress any CORS errors caused by not using a configured hostname. A developer can configure the expiration date of a dev key to any of the three preset options (1 day, 7 days, or 30 days).

Dev keys should never be used in production environments, as they can make your app more susceptible to abuse and security breaches.

Try out dev keys in an app

To test dev keys, I created a simple demo web app that sends 200 requests to create a new document in an Appwrite database. To set this app up, you must complete the following steps:

Step 1: Setup Appwrite project

First, create an Appwrite Cloud account or self-host Appwrite 1.7. Create a project (which will lead you to the project overview page) and head to the Databases page from the left sidebar. Create a new database with the ID testDb and a new collection with the ID testCollection. Store both of these IDs for future usage. In this collection, add the following attribute:

Name	Type	Required
`number`	Integer	True

Then, head to the Settings tab of the collection, scroll down to the Permissions section, and add the following permissions:

	Create	Read	Update	Delete
Any	False	False	False	False

Lastly, return to the project overview page, head to the Settings page from the left sidebar, and copy your API endpoint and project ID for future usage.

Step 2: Create web app

Next up, we'll create our test app. This will require us to create two files in our working directory:

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Dev keys demo</title>
</head>
<body>
    <h1>Dev keys demo</h1>
    <p>Click on this button to add 200 documents to the database in less than 1 minute.</p>
    <button type="button">Add documents</button>

    <!-- Appwrite Web SDK -->
    <script src="https://cdn.jsdelivr.net/npm/appwrite@18.1.1"></script>

    <!-- Our app's script -->
    <script src="app.js"></script>
</body>
</html>

app.js

const client = new Appwrite.Client()
    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1') // Your API Endpoint
    .setProject('<YOUR_PROJECT_ID>'); // Your project ID

const database = new Appwrite.Databases(client);

document.querySelector('button').addEventListener('click', async () => {
    const promises = [];
    for (let i = 0; i < 200; i++) {
        const promise = database.createDocument(
        'testDb', // Your database ID
        'testCollection', // Your collection ID
        Appwrite.ID.unique(),
        { number: i + i }
        );
        promises.push(promise);
        console.log('Request initiated:', i+1);
    }

    await Promise.all(promises);
});

If you open the HTML page in your browser and click on the Add documents button, you will notice numerous errors in the console with the HTTP code 429, as Appwrite's rate limits allow one client to create 120 requests per minute for this API endpoint.

Step 3: Create dev key

Head back to your Appwrite project. On the overview page, select the Dev keys tab under the Integrations section and create a new dev key. You can add whatever name and expiry date you like.

After creating this dev key, head to the app.js file and update the Appwrite client to the following:

const client = new Appwrite.Client()
    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
    .setProject('<YOUR_PROJECT_ID>')
    .setDevKey('<YOUR_DEV_KEY>'); // Your dev key

Step 4: Test the app

Reopen the HTML page in your browser. Clicking the Add documents button will allow all 200 requests to execute successfully.

Next steps

And with that, you have successfully tested dev keys! Learn more about Appwrite by visiting the docs and joining the Discord community.

How to setup the SvelteKit starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 15:08:48 +0000

Building web applications requires both front-end expertise and back-end infrastructure. Appwrite Sites simplifies this process by providing a platform for deploying, hosting, and scaling web applications.

To ease this process even further, Appwrite Sites offers a variety of starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, SvelteKit, and Flutter. In this blog, you will learn how to set up the SvelteKit starter template and deploy it to Appwrite Sites.

Overview of the starter template

SvelteKit is a modern web framework built on top of Svelte that enables fast, server-rendered and client-enhanced web applications with powerful routing, data loading, and deployment features out of the box.

Appwrite's SvelteKit starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' SSR rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Head to the Sites page from the left sidebar, click on the Create site button, and select the Clone a template option. This will take you to the Appwrite Sites templates listing, where you should search Svelte starter and click on the template.

After selecting the template, you can choose to connect a GitHub repository now or at a later time. If you choose to connect a repository, ensure you select a production branch (leave the root directory as is). Then, review the preset environment variables, update the domain name if you want, and click on the Deploy button. You can watch the deployment logs as the site is built.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your SvelteKit starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Svelte starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? SvelteKit (sveltekit)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

After your site has been successfully deployed, Appwrite will show you a Congratulations page. You can then either choose to view the site by clicking on the Visit site button or view the site configuration (deployments, logs, domains, usage, and settings) by clicking on the Go to dashboard button.

Next steps

And with that, the SvelteKit starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to setup the Nuxt starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 13:47:42 +0000

To ease this process even further, Appwrite Sites offers a variety of starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, SvelteKit, and Flutter. In this blog, you will learn how to set up the Nuxt starter template and deploy it to Appwrite Sites.

Overview of the starter template

Nuxt is a framework built on top of Vue.js that makes it easy to develop server-rendered, statically generated, or single-page applications with features like routing, SEO optimization, and modular architecture out of the box.

Appwrite's Nuxt starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' SSR rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your Nuxt starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Nuxt starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? Nuxt (nuxt)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

Next steps

And with that, the Nuxt starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to setup the Next.js starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 13:10:06 +0000

To ease this process even further, Appwrite Sites offers a variety of starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, SvelteKit, and Flutter. In this blog, you will learn how to set up the Next.js starter template and deploy it to Appwrite Sites.

Overview of the starter template

Next.js is a React framework that enables developers to build fast, scalable web applications with features like server-side rendering, static site generation, and API routes out of the box.

Appwrite's Next.js starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' SSR rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your Next.js starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Next.js starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? Next.js (nextjs)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

Next steps

And with that, the Next.js starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to setup the Flutter starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 13:02:09 +0000

Most web hosting platforms don't support Flutter Web out of the box, often forcing developers to jump through hoops just to get their apps online. This lack of native support can make deploying Flutter Web projects unnecessarily complex and time-consuming.

Appwrite Sites changes that by offering built-in support for Flutter Web, making it easy to host and scale your applications. Alongside Flutter, Appwrite also provides starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, and SvelteKit. In this blog, you'll learn how to set up the Flutter starter template and deploy it to Appwrite Sites.

Overview of the starter template

Flutter Web is a part of the Flutter framework that allows developers to build responsive, high-performance web applications using a single Dart codebase.

Appwrite's Flutter starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' Static rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your Flutter starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Flutter starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? Flutter (flutter)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

Next steps

And with that, the Flutter starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How You Can Build The Best, Fastest Blog On The Internet

Aditya Oberai — Mon, 17 Feb 2025 14:35:43 +0000

It is (almost) a rite of passage for every developer today to develop and host a blog on their own (because we really love to "engineer" our own solutions, don't we?) In all honesty, developers are so spoilt for choice today with the number of web frameworks, CMS solutions, and other tools available in the market that it has become next to impossible to pick that "one correct solution" any longer.

Now, while the title of this blog is pure clickbait (sorry!) and the irony of not publishing this on a self-hosted blog is not lost on me, we do have a legitimate challenge here. Therefore, in this blog, we will discuss how you can build a simple yet highly performant blog site and deploy it on the internet.

Defining our requirements

First things first, we must define what we need from this blog site. If I were to host my own blog, I would ideally want the following features at the minimum:

Simple, consistent experience (just one layout works)
Easy content authoring system (ideally, one that allows writing Markdown)
Quick load times (all content should be pre-rendered)
SEO-friendly (pre-rendering can help here too)
Easy to preview and test (should be simple to locally deploy)
Simple and cheap to deploy (pick one of 'n' hosting platforms with GitHub CI/CD available)

With these decided, we can now pick a tech stack to build our blog site.

Choosing the tech stack

Considering the feature set above, I have chosen the following tech stack to build a blog site:

Web framework: SvelteKit

SvelteKit is a full-stack framework for building modern web applications using Svelte. It provides file-based routing, multiple rendering methods (including Static Site Generation or SSG), API handling, and other powerful features to help you build your web apps.

Content authoring system: Markdoc

Markdoc is a Markdown-based content authoring framework developed by Stripe. It extends standard Markdown by adding custom tags, components, and validations, making it more powerful for structured content in web applications.

Site hosting: Azure Static Web Apps

Azure Static Web Apps is a fully managed hosting service for static sites and web frameworks like Next.js, Nuxt, and SvelteKit. It provides automatic deployments from GitHub, free SSL, global CDN, and built-in serverless functions support (via Azure Functions).

Note: You can pick a different hosting platform if you like. Azure Static Web Apps is a personal preference. Platform choice will not directly affect the site's functionalities; however, it may affect site reliability and scalability.

Developing the blog site

Now that we have decided on our site's tech stack, we can start building the blog site.

Step 1: Create a SvelteKit app

Pre-requisite: install Node.js on your system if you haven't already.

To create a SvelteKit app, you must open your terminal and run the following command:

npx sv create

This will lead us to an interactive setup process, where must pick our project directory, template (pick SvelteKit minimal, type checking, and other configuration settings.

┌  Welcome to the Svelte CLI! (v0.6.21)
│
◇  Where would you like your project to be created?
│  blog
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with Typescript?
│  No
│
◆  Project created
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  prettier, eslint
│
◆  Successfully setup add-ons
│
◇  Which package manager do you want to install dependencies with?
│  npm
│
◆  Successfully installed dependencies
│
◇  Successfully formatted modified files
│
◇  Project next steps

Once that is done, enter your project directory, run the npm install command, and your minimal SvelteKit app is ready!

Step 2: Integrate Markdoc with SvelteKit

To easily integrate Markdoc with SvelteKit, my team member from Appwrite, Torsten Dittmann, has developed an open-source NPM package, svelte-markdoc-preprocess that acts as a preprocessor and converts Markdoc to Svelte at build time.

We will install this in our app by running the following command:

npm install svelte-markdoc-preprocess

Then, visit the svelte.config.js file and update its content:

import adapter from '@sveltejs/adapter-auto';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';
import { markdoc } from 'svelte-markdoc-preprocess';

const config = {
    preprocess: [vitePreprocess(), markdoc()],
    extensions: ['.markdoc', '.svelte'],
    kit: {
        adapter: adapter()
    }
};

export default config;

This will enable the app to use the preprocessor at build time and designate .markdoc as a valid file extension.

Step 3: Prepare a Markdoc layout

Next, we must create a Markdoc layout. This will define a common, consistent structure and styling for our blog pages. In the src directory, create a directory, markdoc. Within that, create two subdirectories, layouts and styles.

The layouts sub-directory

In the src/markdoc/layouts directory, add a file Blog.svelte:

<script>
    import "../styles/blog.css";
    import { formatDate } from "$lib/utils/date";

    let { title, description, author, date, timeToRead, children } = $props();
</script>

<svelte:head>
    <title>{title}</title>
    <meta name="description" content={description} />
</svelte:head>

<main>
    <section id="title">
        <a href="/"><em>&larr; Back to blog</em></a>
        <h1>{title}</h1>
        <p class="description">{description}</p>
        <ul>
            <li>{author}</li>
            <li>{formatDate(new Date(date))}</li>
            <li>{timeToRead} mins</li>
        </ul>
        <hr />
    </section>

    {@render children()}
</main>

<style>
    main {
        width: 80%;
        padding: 1.5rem 2.5rem;
        margin: 1.5rem auto;
        justify-content: center;
        align-items: center;
        background-color: #ffffff;
        box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
        border-radius: 8px;
    }

    #title > ul {
        display: flex;
        flex-direction: row;
        justify-content: space-between;
        list-style: none;
        padding: 0;
    }
</style>

This layout will load any frontmatter (metadata added to a .markdoc file) from our blogs and allow us to use the information on our rendered page.

Now, if you were paying close attention, you may have noticed that a non-existent formatDate function was included in this layout. To make its existence real, create a date.js file in the src/lib directory and add the following code:

export const formatDate = (date) => {
    const dt = new Date(date);
    const month = dt.toLocaleString('en-US', { month: 'short' });
    const day = dt.getDate();
    const year = dt.getFullYear();
    return `${month} ${day}, ${year}`;
};

The styles sub-directory

In the src/markdoc/styles directory, add a blog.css file. You can copy the following CSS code:

body {
  margin: 0;
  padding: 0;
  font-family: 'Arial', sans-serif;
  background-color: #f8f9fa;
  color: #343a40;
  line-height: 1.6;
}

h1 {
  font-size: 2.5rem;
  font-weight: bold;
  margin-bottom: 1.5rem;
  color: #007bff;
}

h2, .description {
  font-size: 2rem;
  font-weight: 600;
  margin-bottom: 1rem;
  color: #495057;
}

p {
  font-size: 1.125rem;
  margin-bottom: 1.5rem;
  color: #495057;
}

img {
  max-width: 40%;
  height: auto;
  border-radius: 0.5rem;
  margin: 1.5rem auto;
}

a {
  color: #007bff;
  text-decoration: none;
  transition: color 0.3s;
}

a:hover {
  color: #0056b3;
  text-decoration: underline;
}

blockquote {
  font-size: 1.25rem;
  font-style: italic;
  margin: 2rem 0;
  padding-left: 1.5rem;
  border-left: 0.25rem solid #007bff;
  color: #6c757d;
  background-color: #f8f9fa;
}

pre {
  background-color: #e9ecef;
  padding: 1rem;
  border-radius: 0.5rem;
  overflow-x: auto;
  font-size: 1rem;
  color: #343a40;
}

ul, ol {
  margin-bottom: 1.5rem;
  padding-left: 2rem;
}

li {
  margin-bottom: 0.5rem;
  font-size: 1.125rem;
}

#title > ul {
  display: flex;
  flex-direction: row;
  justify-content: space-between;
  list-style: none;
  padding: 0;
}

table {
  width: 100%;
  border-collapse: collapse;
  margin: 1rem 0;
  border: 1px solid #ddd;
}

th, td {
  padding: 0.75rem;
  text-align: left;
  border: 1px solid #ddd;
}

th {
  background-color: #f4f4f4;
}

tr:nth-child(even) {
  background-color: #f9f9f9;
}

@media (max-width: 768px) {
  .container {
    margin: 1.5rem;
    padding: 1.5rem;
  }

  h1 {
    font-size: 2rem;
  }

  h2, .description {
    font-size: 1.75rem;
  }

  p {
    font-size: 1rem;
  }

  img {
      max-width: 90%;
      height: auto;
      border-radius: 0.5rem;
      margin: 1rem auto;
  }

  blockquote {
    font-size: 1.125rem;
  }
}

Note: This is just a rudimentary stylesheet generated by GitHub Copilot. Please ensure you make any necessary updates.

Once this is done, revisit the svelte.config.js file and update it as follows:

import adapter from '@sveltejs/adapter-auto';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';
import { markdoc } from 'svelte-markdoc-preprocess';
// Add two new imports
import { dirname, join } from 'path';
import { fileURLToPath } from 'url';

const config = {
    preprocess: [
        vitePreprocess(), 
        // Update markdoc configuration to include the layout
        markdoc({ 
            layouts: {
                blog: join(dirname(fileURLToPath(import.meta.url)), './src/markdoc/layouts/Blog.svelte')
            }
        })
    ],
    extensions: ['.markdoc', '.svelte'],
    kit: {
        adapter: adapter()
    }
};

export default config;

This will allow us to use the layout we just created with our blogs. We're now ready to add our first blog.

Step 4: Add a new blog

To add our first blog, go to the src/routes directory (home to all pages in a SvelteKit app) and create a new directory, blogs. This subdirectory will become home to all the blogs that exist on your site. Inside this, create a subdirectory with whatever route you would like your blog to exist on (using my-first-blog will make the route of this blog /blogs/my-first-blog on your deployed website). Here, add a file +page.markdoc and add the following content:

---
title: "Test blog title 1"
description: "Description of this test blog"
author: Aditya Oberai
date: 2025-02-16
timeToRead: 3
layout: blog
---

## Tersis supplex causa rapida inpatiensque nomen egi

### Et non foret Pallade nec patrium genus

Lorem markdownum Bacchei vitiantur contulit in corpus ferre aselli Lycei celebrant accipis. In diem! In praestem remittas quicquid ecquis arte: nuda stabant sequens rogantis **et dextrae** serta.

- Sed velut deplorata reperire Iphis et grave
- Ingenium credere ignem conciperet numeros cum forti
- Retemptat sibi cupido

### Bibit Clytiumque merui progenuit medio

Cornua dat nec; domabile et seraque Siculique alebat sic? Sacra est mediis parentis exire naides non illum morando fecere, nunc o. Manifestam tunc, vix [auferat tantum pudor](http://fatebere.io/) radiorum labant deae: illi adfata est; coepisse te. Usum tristis quodque umerumque natam agantur nosti mihi semine quaesitae erat orbem, est. Ante Pleuron clausas, **de forte**, et urbs triste timor sit meruit verti concipias, sit sacra in.

1. Eram est lacu forsitan rapienda
2. Post rami
3. Res vomentem viscera deposuisse naris quondam simul

### Fuerunt versus in spiro dolor etiam

Ignes corpora canum sucis studio colla lacrimis est umbra speculabar avia dereptis *corpore a effugies* locuti ad terga, et. Docta est, sibi pars corporis senectae domos volandi multifori Idomeneus visum ad Aeolidae lacrimam veni. Pondere [parum](http://www.atque.com/) auras in genus laesi demunt **tu est in** votis adopertaque neque, homini dignos. Acris *intabescere Tydides vicit*; surgunt mille possent virum fatetur maiorque tu verba exspirat acumine ferenti nimiumque suis dicenda corporis. Retrahebat et meus precor, committi signis arsit tamen multa post, voluisti videre.

> Pars dispar, sit labori subiecta curvi [horrendis dea](http://cumnomine.net/deos); est. Durat dicta, arduus
> [sed tamen commisit](http://www.erat.net/mensas-vocant) plangorem, fuit. Murmure
> Tisiphone premit, nobiliumque tamen Thessalidum ante, *non*.

Posse et lolium. Sint illis, est morte potest gestu **novissimus** heros celebrandaque illic in troia morte: herba quae.

{% table %}
* Foo
* Bar
* Baz
---
*
  ```
  puts "Some code here."
  ```
* Text in a table
---
*
  A "loose" list with

  multiple line items
* Test 2
* Test 3
---
* Test 1
* A cell that spans two columns {% colspan=2 %}
{% /table %}

![Aditya Oberai's Pic](https://oberai.dev/pic)

Locally running our app via the command npm run dev and visiting the route /blogs/my-first-blog will render the following:

Step 5: Create a basic landing page with an index of blogs

Now that our blog layout is functional, we must also create a simple landing page. Since each blog site also needs an index of blogs for people to find content they are interested in, that is what we shall build. This will feature a couple of components:

The +page.js file

First, create a +page.js file in the src/routes directory. The +page.js file will house a load function to fetch the information of all Markdoc-based routes in the ./blogs subdirectory before the page is rendered. Add the following code to the +page.js file:

import { base } from "$app/paths";

export function load() {

    const blogsGlob = import.meta.glob('./blogs/**/*.markdoc', {
        eager: true
    });

    const blogs = Object.entries(blogsGlob)
        .map(([filepath, postList]) => {
            const { frontmatter } = postList;

            const slug = filepath.replace('./', '').replace('/+page.markdoc', '');
            const postName = slug.slice(slug.lastIndexOf('/') + 1);

            return {
                title: frontmatter.title,
                description: frontmatter.description,
                author: frontmatter.author,
                date: new Date(frontmatter.date),
                timeToRead: frontmatter.timeToRead,
                slug,
                href: `${base}/blogs/${postName}`,
            };
        })
        .sort((a, b) => {
            return b.date.getTime() - a.date.getTime();
        });

    return {
        blogs
    }
}

This load function finds all .markdoc files in the src/routes/blogs directory, extracts and processes the frontmatter of each blog post, and prepares all the information to make it available as a property in our index page's .svelte file.

The +page.svelte file

In the src/routes directory, open the +page.svelte file and replace the code with the following:

<script>
    import { formatDate } from "$lib/utils/date";

    let { data } = $props();
</script>

<svelte:head>
    <title>Blog Demo</title>
    <meta name="description" content="A test blog site built with SvelteKit and Markdoc" />
</svelte:head>

<div class="container">
    <h1>Aditya Oberai's Blog</h1>
    <ul>
        {#each data.blogs as blog}
            <li>
                <a href={blog.href}>{blog.title}</a>
                <span class="date"> | {formatDate(blog.date)}</span>
            </li>
        {/each}
    </ul>
</div>

<style>
    .container {
        max-width: 800px;
        margin: 50px auto;
        padding: 20px;
        background-color: #ffffff;
        box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
        border-radius: 8px;
    }

    h1 {
        font-size: 2.5rem;
        font-weight: bold;
        margin-bottom: 2.5rem;
        text-align: center;
        color: #007bff;
    }

    ul {
        list-style: none;
        padding: 0;
    }

    li {
        margin: 1.25rem 0;
        font-size: 1.2rem;
    }

    a {
        text-decoration: none;
        color: #007bff;
        transition: color 0.3s;
    }

    a:hover {
        color: #0056b3;
        text-decoration: underline;
    }

    .date {
        font-size: 0.9rem;
        color: #6c757d;
    }

    @media (max-width: 768px) {
        .container {
            margin: 2.5rem;
            padding: 1.5rem;
        }

        h1 {
            font-size: 2rem;
        }

        li {
            font-size: 1rem;
        }
    }
</style>

Locally running our app via the command npm run dev and visiting the index page at the route / will render the following:

Note: I added 2 new blogs for representation purposes. All blogs will be listed in descending order of their date of creation.

Step 6: Configure pre-rendering

To improve the blog's load times and make it more SEO-friendly, we must pre-render all the pages at build time so that all the pages are simple HTML files.

To do so, install the SvelteKit static adapter (and remove the auto adapter as it is an unnecessary dependency):

npm uninstall @sveltejs/adapter-auto
npm install @sveltejs/adapter-static

Then, visit the svelte.config.js file and edit the adapter import to the following:

- import adapter from '@sveltejs/adapter-auto';
+ import adapter from '@sveltejs/adapter-static';

Lastly, visit the src/routes directory, create a +layout.js file, and add the following code:

export const prerender = true;

This will ensure that every single page in the app is pre-rendered as HTML.

At this point, I built our blog app using npm run build and previewed it to generate a Lighthouse report.

We received a 100 in the Performance and SEO categories.

We can now push the SvelteKit app to GitHub and are ready to deploy it.

Step 7: Deploy the blog site

Pre-requisite: create an Azure account

Deploying the blog site on Azure Static Web Apps is fairly simple due to their in-built GitHub integration. Go to the Azure portal, click on the Create a resource button, search Static Web App, and create a resource.

Select (or create) a resource group, add a name for your web app, select a pricing plan, and connect your GitHub account and repo.

Azure will auto-detect the framework (SvelteKit) and prepare a GitHub Action for you. Leave those settings as default and create the resource.

Note: Don't forget to click on each step and expand to understand what must be done!

Conclusion

And with that, you have built the best, fastest blog on the internet! If you liked this blog site, please star it on GitHub.

adityaoberai / sv-markdoc-demo

SvelteKit Markdoc Blog Demo

A blog that uses Static Site Generation on SvelteKit and Markdoc to render blogs from Markdown

Setup

Run the following commands in your terminal:

git clone https://github.com/adityaoberai/sv-markdoc-demo.git
cd sv-markdoc-demo
npm install
npm run dev

Add new blog

To add a new blog, go to the directory ./src/routes/blog, create a new directory (the name of this directory will act as your endpoint), and add a +page.markdoc file with content in the following style:

---
title: Title of the blog
description: Description of the blog
author: Aditya Oberai
date: 2024-12-16
timeToRead: 3
layout: blog
---

<Add blog content in Markdown here>

Note: Do not edit the layout: blog field. ALso, the date is in yyyy-mm-dd format.

View on GitHub

You can also try out the demo blog deployed on Azure Static Web Apps.

Try out the blog

Thank you so much for reading this blog, wish you all happy building!

Announcing Appwrite’s Hacktoberfest 2024 Hackathon: Build, innovate, and win!

Aditya Oberai — Tue, 01 Oct 2024 17:15:58 +0000

Hacktoberfest is almost here, and we’re excited to announce that Appwrite will be hosting our own Hacktoberfest 2024 Hackathon! Whether you're a seasoned developer or just dipping your toes into open-source, this is the perfect opportunity to create something impactful while being part of the global Hacktoberfest movement.

From October 1st to October 31st, join thousands of developers worldwide as we work together to push the boundaries of creativity and innovation. This year, we’re looking for projects that showcase not only technical skills but also a fresh perspective on the tools and problems that matter most to the developer community.

What you need to know:

Dates: The hackathon will run for the entire month of October, kicking off on October 1st and concluding on October 31st.
Team size: You can work solo or with a team of up to 4 members.
Project requirements: Your submission must be a brand-new project. Whether it's a web app, a mobile app, a game, or a tool, we want to see something fresh and innovative.
Focus areas: We're looking for projects that highlight creativity and innovation. Don't be afraid to push the envelope and try something out of the ordinary!
Prizes:
- The top team will each walk away with The Appwriter, an exclusive award for the best overall project.
- 2nd and 3rd-place teams will receive the Appwrite swag kit.

Why join the Appwrite Hackathon?

Aside from being part of one of the most exciting open-source events of the year, this hackathon is your chance to:

Collaborate with like-minded developers across the world.
Showcase your skills by building something new and exciting.
Learn and grow, whether you’re deepening your knowledge of Appwrite or trying it out for the first time.
Win awesome prizes and, of course, eternal bragging rights.

This Hacktoberfest, we’re focusing on innovation and creativity. Developers who are given the space to experiment and push their boundaries can build extraordinary things. We want to see your ideas come to life! Read this article about hackathon ideation to get your creative juices flowing.

How to get involved

Gather your team (or get ready to fly solo) and start brainstorming!

Don’t forget to register your team and project for a chance to win the prizes. Registration is open here from today until October 31st.

Join our Discord server to keep up with all future Hackathon news, and mark your calendars for the official kickoff on October 1st!

Get ready to build, innovate, and show the world what you can create. Let’s make Hacktoberfest 2024 unforgettable!

Twilio Challenge: Language Translator via Twilio Functions, WhatsApp, Appwrite & OpenAI

Aditya Oberai — Sun, 16 Jun 2024 13:28:03 +0000

This is a submission for Twilio Challenge v24.06.12

What I Built

As an avid translator who often faces challenges with different languages when traveling across different countries. To solve my own problem, I wanted to create a simple chatbot that lets me quickly translate text from my preferred language to another, making it so much easier to communicate with other people.

Therefore, I created an AI Language Translator using the WhatsApp Sandbox mode in Twilio Programmable Messaging, Twilio Functions, Appwrite Database and OpenAI's GPT-4o API.

Demo

Watch how it works

Here is a demo video of the app:

Tech Stack

The chatbot uses Twilio Programmable Messaging (WhatsApp Sandbox) and Twilio Functions to communicate with the user.
Appwrite Database is primarily used to store the state of the user through the conversation, and all conversation data is deleted as soon as the translation is sent to the user.
OpenAI's GPT-4o API is used to translate the text to the specified language.

Steps to try

You can try it out by scanning the QR Code in the image or by texting the code join trail-has to the number +14155238886 on WhatsApp.

Once that is done, send the message Hello Twilio to begin using the chatbot.

Source code

You can also view the source code of the Twilio Function on GitHub:

adityaoberai / language-translator-twilio-function

Twilio function that translates language using GPT-4o and responds through the Twilio Programmable Messaging on WhatsApp

Twilio Challenge: Language Translator via Twilio Functions, WhatsApp, Appwrite & OpenAI

Description

Twilio function that translates language using GPT-4o and responds through the Twilio Programmable Messaging on WhatsApp

Screen_Recording_20240617_172845_WhatsApp.mp4

How it works

Twilio Programmable Messaging (WhatsApp Sandbox) and Twilio Functions is used to communicate with the user
Appwrite Database is used to store the state of the user through the conversation, and all conversation data is deleted as soon as the translation is sent to the user
OpenAI's GPT-4o API is used to translate the text to the specified language

View on GitHub

Twilio and AI

To create this chatbot, I used OpenAI's GPT-4o API in a Twilio Function. This function consumes the text to translate, and the target language based on the user's input and returns the translated text.

Additional Prize Categories

Twilio Times Two: The project uses Twilio Programmable Messaging (WhatsApp Sandbox) and Twilio Functions.
Impactful Innovators: In a far more interconnected world than ever, a tool that simplifies cross-language communication will help bring people from different cultures closer together.

Feedback, Updates, and Testimonials

During the process of developing the Twilio Function, I discovered an issue with the max length of environment variables. The issue has already been acknowledged by the Twilio team.

Aditya Oberai • Jun 17

Just finished my submission 🥳

@anthonyjdella, I do have some product feedback. When trying out Twilio Functions, I noticed that the max length of environment variables is set to 255 characters. I was using Appwrite Databases as a part of my project, and the API keys happened to be 256 characters in length. This made it somewhat challenging to use environment variables for that purpose.

The project is getting real-world usage and positive user feedback publicly!

// Detect dark theme var iframe = document.getElementById('tweet-1803512147663868323-77'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1803512147663868323&theme=dark" }

Rethinking password security: say goodbye to plaintext passwords

Aditya Oberai — Tue, 02 Apr 2024 10:41:21 +0000

Recently, we came across a report by BleepingComputer, which shared how misconfigured Firebase projects led to the leakage of 19 million plaintext passwords on the public internet. This was primarily caused by missing or incorrectly configured security rules on Firebase instances that consequently permitted read access to databases, resulting in a massive data leak that exposed:

Names: 84,221,169
Emails: 106,266,766
Phone numbers: 33,559,863
Passwords: 20,185,831
Billing info (bank details, invoices, etc.): 27,487,924

For passwords, the problem was a lot worse because 98% of them, or 19,867,627 to be exact, were in plaintext. While this problem is not inherently a Firebase bug, it does signify a massive lack of understanding around authentication tooling and password security. Therefore, this blog will discuss why plaintext passwords are bad for your security and alternative solutions.

The dangers of plain text passwords

Storing passwords in plaintext presents significant security risks and vulnerabilities for both users and organizations. Here are several vital points illustrating why plaintext passwords are bad:

An easy target for hackers: Plaintext passwords can be easily read and exploited by anyone who gains unauthorized access to the storage database, making them prime targets for hackers.
Lack of confidentiality: Storing passwords in plaintext fails to protect the confidentiality of user information. If a security breach occurs, users’ passwords are exposed without any layer of protection.
Non-compliance with security standards: Many industry standards and regulations, such as GDPR, PCI DSS, and HIPAA, require that personal data, including passwords, be adequately protected, and storing passwords in plaintext can result in non-compliance.
Increased risk of insider threats: Plaintext passwords are vulnerable to external threats and insider threats. Employees with access to the database can view and potentially misuse this information, leading to internal security breaches.
Higher impact of data breaches: When passwords are stored in plaintext, the impact of a data breach is magnified. Attackers can access the compromised system and use the same credentials to attempt access to other services, exploiting the common habit of password reuse.
No defense against brute force attacks: Plaintext passwords offer no defense against brute force attacks. While hashed passwords can also be vulnerable, hashing makes decoding user passwords a lot more difficult.
Damage to reputation: A company found to be storing passwords in plaintext can suffer significant damage to its reputation. Users and clients lose trust in a business that doesn’t prioritize their information’s security.

Alternatives to plaintext passwords

Fortunately, modern authentication systems are built with the drawbacks of plaintext passwords kept in mind. Two major solutions that have been developed to solve this problem are as follows:

Password hashing

Password hashing is a security technique that converts a plaintext password into a fixed-size string of characters, which is virtually impossible to reverse. This process uses a hash function to transform the original password, ensuring that even if the data storage is compromised, the actual passwords are not easily deciphered.

Benefits of password hashing compared to storing passwords in plaintext include:

Enhanced security: Hashed passwords are extremely difficult to reverse-engineer, providing a higher level of security against data theft.
Data breach protection: In the event of a breach, hashed passwords significantly reduce the risk of passwords being used for unauthorized access.
Compliance with standards: Hashing passwords helps organizations comply with data protection and privacy regulations.
User trust: By securing passwords effectively, businesses can maintain and even boost user trust by demonstrating a commitment to privacy and security.
Mitigation of reuse attacks: Hashed passwords make it harder for attackers to use stolen credentials on other sites, reducing the impact of credential reuse attacks.
Scalability and future-proofing: Hashing algorithms can be updated and strengthened over time, providing flexibility as security standards evolve.

You can read our blog on password hashing algorithms to learn more.

Passwordless authentication

Passwordless authentication eliminates the need for users to create and remember passwords, aiming to enhance both security and user experience. Instead of relying on a traditional password, passwordless methods verify identity through alternative means. This approach can significantly reduce the risk of phishing attacks and password theft, as there’s no password to steal or guess.

Some common passwordless authentication methods are:

Biometric verification: Uses unique biological characteristics, such as fingerprints or facial recognition, for identification.
Magic links: Sends a one-time use URL to the user’s registered email address for login.
One-time passwords (OTPs): Generates a single-use code sent via SMS or email.
Authentication apps: Generates time-based codes or push notifications for user approval.
Smart cards and security tokens: Physical devices that the user must possess to gain access.

You can read our blog on passwordless authentication to learn more.

How Appwrite solves this problem

Appwrite Authentication makes building secure and robust authentication easy and supports many authentication methods. Currently, the following authentication methods are available on Appwrite to combat plaintext passwords:

Email and password login with Argon2id password hashing
OTP-based login via SMS and email
Magic URL login via email
30+ external OAuth2 providers, including Google, Facebook, GitHub, LinkedIn, and Apple
JSON Web Token (JWT) creation to extend user authentication to server-side functions
Custom token login to allow integration with any external authentication solution of your choice
Two-factor authentication to add an additional layer of security to user accounts

Additionally, to prevent unauthorized data access, Appwrite features a robust permissions system that is thoroughly coupled with Appwrite Authentication. The most significant benefit of Appwrite’s permissions system is that any developer needs to offer read or write access to any user intentionally. No default rule provides open access to your application’s client, and the process of setting permissions is simplified by using Appwrite’s console UI.

Appwrite also enforces the setting of authorized clients to communicate with an Appwrite project for all supported client platforms (web, Android, Apple, and Flutter). This way, no unauthorized clients can access data, adding an extra layer of protection.

Moving forward

No matter what rules and systems any platform provides, combating plaintext passwords is a responsibility shared by all application developers. If you, as a developer, care about the security and privacy of your user accounts and data, you must take the necessary actions to safeguard their authentication information. Appwrite takes this problem very seriously and will continue to add new tools and improve our existing ones to make user authentication simpler and safer for all developers and their users.

Learn more about Appwrite Authentication through our docs and join our Discord server.

Improving user experience with passwordless authentication

Aditya Oberai — Tue, 02 Apr 2024 10:41:00 +0000

Today, as concerns about security and user convenience only grow with digital activity, traditional password-based authentication systems are becoming a relic of the past. In recent times, we have seen a rise in passwordless systems, which are increasingly seeing adoption in both small and big companies alike, such as Expensify (whose transition was also covered in a Forbes article in 2023. A survey from Enterprise Strategy Group, a division of TechTarget, in 2022 also revealed that:

31% of respondents picked passwordless authentication as their top identity-related activity
34% of respondents chose passwordless authentication among their top three identity-related activities
54% of respondents have started to transition to passwordless authentication
Of organizations transitioning to passwordless strategies, more than 50% experienced a significant positive impact on risk reduction and improved UX
Almost two-thirds reported increased efficiency for IT and security teams

Therefore, in this blog, we'll explore what passwordless authentication is, the drawbacks of conventional methods, and how embracing passwordless solutions can be a game-changer.

The drawbacks of traditional password-based systems

As per an article by Lastpass, passwords need to be treated like a user experience today because repeated login attempts, forgotten passwords, mandatory password changes, and looking up passwords in a document or notebook only slow employees down and create friction in their workflow. Traditional password systems, despite their ubiquity, come with significant drawbacks, including:

Password fatigue: Users struggle with remembering numerous passwords for different accounts.
Security risks: Weak or reused passwords increase vulnerability to hacking and data breaches.
User inconvenience: Managing complex passwords is often cumbersome and frustrating and only causes more fatigue.
Time-consuming: Resetting forgotten passwords and managing accounts adds unnecessary steps.
Phishing vulnerabilities: Traditional passwords are susceptible to phishing attacks and can open up new attack vectors for a product.
Limited physical security: Passwords can be easily observed or stolen, especially in public or shared spaces.

What is passwordless authentication?

Passwordless authentication is exactly what it sounds like – a way to authenticate users without the need for passwords. This paradigm shift in user verification employs methods like passkeys (fingerprint, facial scans, or screen lock), magic links (one-time clickable links sent via email or SMS), and one-time passcodes (OTPs) sent to a user's device. These methods are not only innovative but also align with the natural human tendency to seek convenience and simplicity.

Benefits of passwordless authentication for user experience

The transition to passwordless authentication brings a myriad of benefits:

Enhanced security: By eliminating passwords, we inherently reduce the risk of password-related breaches.
Improved ease of use: Users no longer need to remember or manage a plethora of passwords. This simplifies the login process, leading to a more frictionless user experience.
Accelerated process: Authentication becomes quicker, with just a click or a touch, streamlining the user's journey.
Higher authentication speed: Users can access services faster, without the delay of typing a password.
Enhanced user retention: Easier login processes can lead to lower user drop-off rates.
Accessibility for all users: Such methods can be more accessible for users who have difficulty remembering passwords or have physical disabilities that make typing challenging.
Lower support costs: A lack of passwords reduces the volume of password reset requests and related support issues, saving an immense amount of IT and support effort and cost.
Scalability: Easily adapts to growing user bases without the need for extensive password management systems.
Reduced risk of internal threats: Minimizes the risk of password theft or misuse by internal actors within an organization.

Tradeoffs of passwordless authentication

While the benefits are substantial, passwordless authentication isn't without its tradeoffs, such as:

Implementation complexity: It can be more challenging and resource-intensive to implement than traditional methods.
Hardware dependencies: Some methods require specific hardware, like biometric scanners, which add further costs and may not be as readily accessible everywhere.
Privacy and security concerns: The collection of biometric data raises privacy issues for individuals as well as opens up newer security challenges in regard to how the data must be stored.
User adaptation: Users are often accustomed to well-set systems and may need time to adapt to new authentication methods.
Potential technical issues: Some methods rely on the proper functioning of user devices and external systems (like email or SMS services), which the company may not have control of.

Implementing passwordless authentication using Appwrite

Appwrite Authentication also features three commonly used passwordless authentication methods: magic links, email OTPs, and phone authentication, which can be integrated into applications seamlessly with Appwrite’s client-side SDKs. This approach not only enhances security but also significantly improves the user experience by simplifying and streamlining the login process.

Magic URLs

Magic URL authentication is a two-step process in Appwrite.

First, we initialize the login process by sending an email with the magic URL. If the email has never been used, a new account is also generated.

import { Client, Account, ID } from "appwrite";

const client = new Client()
    .setEndpoint('https://cloud.appwrite.io/v1')
    .setProject('<PROJECT_ID>');

const account = new Account(client);

const user = await account.createMagicURLSession(ID.unique(), 'email@example.com', '<APP_URL>');

After receiving the secret from an email, you can create a session for the user.

const urlParams = new URLSearchParams(window.location.search);
const secret = urlParams.get('secret');
const userId = urlParams.get('userId');

const user = await account.updateMagicURLSession(userId, secret);

Email OTPs

Email OTP authentication is a two-step process in Appwrite.

First, we initialize the login process by sending an email. If the email has never been used, a new account is also generated.

import { Client, Account, ID } from "appwrite";

const client = new Client()
    .setEndpoint('https://cloud.appwrite.io/v1')
    .setProject('<PROJECT_ID>');

const account = new Account(client);

const sessionToken = await account.createEmailToken(
    ID.unique(),
    'email@example.com'
);

const userId = sessionToken.userId;

After receiving the secret (6-digit number) in the email, you can use it along with the returned user ID to confirm the user.

const session = await account.createSession(
    userId,
    '[SECRET]'
);

Phone auth

Phone authentication is a two-step process in Appwrite.

First, we initialize the login process by sending an SMS. If the phone number has never been used, a new account is also generated.

import 'package:appwrite/appwrite.dart';

final client = Client()
    .setEndpoint('https://cloud.appwrite.io/v1')
    .setProject('<PROJECT_ID>');

final account = Account(client);

final sessionToken = await account.createPhoneSession(
    userId: ID.unique(),
    phone: '+14255550123'
);

final userId = sessionToken.userId;

After receiving the secret (6-digit number) in the SMS, you can use it along with the returned user ID to confirm the user.

final session = await account.updatePhoneSession(
    userId: userId,
    secret: '[SECRET]'
);

Passwordless authentication stands at the forefront of a new era in digital security and user experience. My recommendation to all is to embrace the future – say goodbye to passwords and hello to a more secure, convenient digital experience.

Learn more about Appwrite Authentication from our docs and join our Discord community to interact with fellow developers using the same.

Social media authentication: convenience vs privacy

Aditya Oberai — Tue, 02 Apr 2024 10:39:47 +0000

Social media authentication has become an integral part of our digital lives, offering a streamlined way to access various online services. We may not even realize it at times; however, logging in with Facebook, X, Linkedin, and other such providers are common authentication methods we come across in most major applications today. There are challenges to using social media providers as authentication methods, though. A massive Facebook incident in 2021 rendered over a billion people helpless as they lost access to a major part of the internet. Such dependence on major social media providers for essential internet activity can have major drawbacks, too. Therefore, in this blog, let us discuss the pros and cons of social media authentication and the delicate balance of convenience and privacy surrounding it.

The benefits of social media authentication

Social media authentication has a number of benefits for developers and consumers of their products:

Simplified login process: Social media authentication streamlines the login process. Users can access multiple services without the need to create and remember different usernames and passwords. This ease of access reduces friction and enhances user experience significantly.
Increased registration and conversion rates: For websites and apps, offering social media authentication can lead to higher registration rates. Users are more likely to sign up for a service if they can do it with just a few clicks rather than filling out a lengthy registration form.
Reduced password fatigue: With the overwhelming number of online accounts today, password fatigue is a real issue. Social media authentication helps mitigate this by reducing the number of passwords a user has to remember.
Faster account recovery: Recovering accounts is generally more straightforward with social media authentication, as it often involves fewer steps than traditional email/password recovery processes.
Social proof and trust: Users often trust social media platforms they frequently use. By offering authentication through these platforms, services can leverage this trust, making users feel more secure about signing up or logging in.
Improved security: Often, social media platforms have robust security measures in place. Using their authentication systems can, in some cases, offer better security than relying on traditional username-password systems, especially if users tend to create weak passwords.
Access to social data: For businesses, social media authentication can provide access to certain user data from their social media profiles (with user consent). This data can be used to personalize and enhance the user experience.

The drawbacks of social media authentication

While the list of benefits that social media authentication brings is not small, the drawbacks are not insignificant. Here are some of the cons to keep in mind:

Privacy concerns: Social media authentication often requires sharing personal information from social media accounts with third-party services. Users may unintentionally grant access to more data than they realize, raising serious privacy concerns.
Data security risks: Linking multiple accounts through social media authentication can create a single point of failure. If a user's social media account is compromised, it could potentially jeopardize the security of all connected accounts.
Limited control over data: Users typically have less control over what data is shared when using social media login options. They might be sharing personal information like email addresses, friend lists, or even browsing habits without explicit knowledge.
Dependency on social media platforms: This authentication method creates a dependency on social media platforms. If a social media service experiences downtime or decides to change its policy or authentication process, it can directly impact all linked services. Additionally, if a user loses access to their social media account, it also means losing access to all relying services.
Loss of anonymity: Users may prefer to keep their social media profiles private and separate from other online activities. Social media authentication can erode this separation, leading to a loss of anonymity online.
Potential for data breaches: The interconnectedness of accounts through social media authentication can escalate the impact of data breaches. A breach in one service could potentially expose information across multiple platforms.
Legal and compliance issues: Relying on social media authentication can complicate compliance with privacy laws and regulations, such as GDPR, especially when it comes to obtaining consent for data sharing and processing.

Implementing alternative authentication methods

Developers have several alternative authentication methods at their disposal, offering different benefits in terms of security, privacy, and user experience. Here are some noteworthy alternatives:

Email and password: The traditional method of using a unique combination of email and password remains popular. It gives users full control over their credentials, though it requires robust security measures to prevent breaches.
Biometric authentication: Utilizing fingerprints, facial recognition, or iris scans for authentication. This method offers high security and a good user experience but requires specific hardware and can raise privacy concerns.
Magic links: These are one-time-use links sent to the user's email address. Clicking the link logs the user into the application. Magic links enhance security by eliminating the need for passwords and are user-friendly.
OTP-based authentication: This involves sending a code via SMS or email to a user, which they enter into the application. While user-friendly, this method has been criticized for security vulnerabilities (especially with SMS).
Smart cards and USB keys: Physical devices like smart cards or USB keys can be used for authentication. They provide a high level of security but require users to have the physical device on hand.
Federated identity: This involves linking the user's identity across multiple systems and services, allowing for the portability of identity and personal information. It's complex to implement but offers a seamless user experience. One major platform that leverages this method is Mastodon.

Of these methods, Appwrite offers email-password authentication, magic links, and OTP-based authentication as a part of its suite of authentication offerings. You can learn more about them in Appwrite’s documentation.

Moving forward

Social media login is convenient but has privacy and security issues. It's important for both users and developers to understand these risks. Fortunately, there are other ways to log in, like using email and password, biometric data, magic links, etc. These alternatives can protect user privacy better in certain circumstances and reduce dependence on social media platforms. Ultimately, the choice of authentication method should be guided by a thorough understanding of its benefits and limitations, always with the end user's best interests in mind.

Learn more about Appwrite Authentication from our docs and join our Discord community to interact with fellow developers using the same.