DEV Community: Steven

Announcing Hosting for Flutter Web: deploy your Flutter web apps with Appwrite

Steven — Thu, 22 May 2025 07:14:44 +0000

Appwrite has long been a powerful backend platform for Flutter developers building mobile applications. Today, we’re bringing that same seamless experience to the web. With full support for Flutter in Appwrite Sites, you can now deploy Flutter web apps directly from your Appwrite project. No extra configuration, no added complexity.

This means you can use your existing Dart and Flutter knowledge to create fast, responsive web apps without needing to learn HTML, CSS, or JavaScript. Build once with Flutter and deploy to mobile, desktop, and web. All from a single codebase, all hosted on Appwrite.

Why native Flutter web support matters

While most web environments are made for Node, Deno, or Bun runtimes, only a few are tailored for the needs of Flutter developers. Appwrite Sites is different. It’s designed with full Flutter web support in mind, not just as an afterthought. That means native framework detection, optimized build settings, and direct integration with your Appwrite backend products like databases, authentication, storage, and functions.

More importantly, it eliminates the common friction points of mobile app deployment. You don’t need to pay for developer accounts ($25 for Android, $99/year for Apple), wait days for store approvals, or navigate restrictive platform policies. With web deployment, your app is live the moment you push it.

And because web apps run anywhere with a browser, you’re no longer limited to iOS or Android. Your Flutter app can be accessed from a desktop, tablet, mobile phone, or even a smart fridge. The web is universal, and Appwrite makes it easy to reach your users.

Not just for full web apps

Even if you're not targeting the web as your primary platform, Appwrite Sites still solves real needs for Flutter developers.

Many apps include flows that rely on external links, such as email verification, password reset, or payments. These typically direct users to a browser. With Sites, you can now create and host those supporting pages using the same Flutter tooling you're already familiar with.

Instead of stitching together HTML pages or managing another stack, you can build these "satellite" pages as lightweight Flutter web apps, and deploy them effortlessly with Appwrite. It's a way you leverage your existing knowledge and a more consistent way to build, with fewer moving parts and one unified codebase.

Key features

Full Flutter framework support: Sites now recognizes and supports Flutter as a framework during setup.
Auto-detection: Flutter web projects are automatically identified. No manual config required.
Optimized static hosting: Deployed like any other static site, but with Flutter-first optimizations.
GitHub integration: Automatically deploy on every push from your GitHub repository.
Works on Cloud and Self-Hosted: Whether using Appwrite Cloud or Self-hosting, Sites for Flutter works everywhere.

How to get started

Step 1: Create Flutter Web app

First, you must either create a Flutter Web app or set up the Flutter Web starter template.

Open your terminal, and run the following command.

flutter create my_app

In case you have an existing Flutter app and want to add web support to it, you need to run the following command in your project directory:

flutter create . --platforms web

Push this project to a GitHub repo.

Step 2: Create Appwrite project

Head to the Appwrite Console.

If this is your first time using Appwrite, create an account and create your first project.

Step 3: Create site

Head to the Sites page in your Appwrite project, click on the Create site button, and select Connect a repository.

Connect your GitHub account and select the repository you intend to deploy.

Select the production branch and root directory from your repo.
Verify that the correct framework is selected. In case an incorrect framework is visible, pick Flutter Web from the drop-down list.
Confirm the install command, build command, and output directory in the build settings. The default build settings for Flutter Web are:
- Install command: N/A (leave empty)
- Build command: flutter build web
- Output directory: ./build/web
Add any environment variables required by the site.

Click on the Deploy button.

Step 4: Visit site

After successful deployment, click on the Visit site button.

Simplifying development

Sites for Flutter is part of Appwrite’s larger mission to simplify the developer experience. With support for backend and frontend services, including static hosting, databases, functions, and auth, Appwrite is the all-in-one platform to build any application.

Try it today on Appwrite Cloud or self-hosted, and you can take your Flutter app live in just a few clicks.

More resources

Building a Location-Based App with Appwrite

Steven — Tue, 13 May 2025 05:44:16 +0000

During my time on the Appwrite discord server, I’ve seen a handful of people ask about how to use Appwrite to create an app using GPS coordinates considering Appwrite doesn’t have geo queries yet. Although I had some ideas for how this could be implemented, I found the opportunity to tackle this problem during the Appwrite Hackathon on Dev with Places. Read on for details on how Places is designed and architected.

Overview

Places has 2 types of users:

Unauthenticated
Authenticated

Unauthenticated users should be able to:

View places on the map
View comments on a place
View photos on a place

Authenticated users should be able to do everything unauthenticated users can do as well as:

Add a place
Add a comment on a place
Add a photo on a place

Design

Collections

Given the use cases defined in the Overview, the following Collections are required:

Note: Appwrite’s relationship attributes are experimental and can lead to performance problems. To minimize the number of related documents fetched, we only create one-way many-to-one relationships from Comments and Photos to Places.

Places: Stores the places on the map using latitude and longitude
Users: Stores the name users publicly since Appwrite’s Users’ data is not publicly accessible
Comments: Stores comments for a place
- $createdAt: ISO 8601 formatted timestamp
- place: one-way many-to-one relationship with Place
- user: one-way many-to-one relationship with Users
- text: comment text
Photos: Stores photos metadata for a place
- $createdAt: ISO 8601 formatted timestamp
- fileId: $id of the file from the Storage API
- place: one-way many-to-one relationship with Place
- user: one-way many-to-one relationship with Users
- text: description of photo

Storage

2 buckets are used for the actual photo files:

Photo Uploads: Write only bucket that allows users to submit photos
Photos: Read only bucket for the photos exposed to users

Functions

In order to ensure the integrity of the data such that there are no comments for places that don’t exist and a user can’t impersonate another user, the Comments and Photos collections are not publicly writable. Instead, Appwrite Functions validate and auto-populate attributes before creating the document. In addition, event based functions are used for for Users and Photos.

Create Comment and Create Photo

Each of these functions accept the following input:

placeId
text

Then, they:

Validate placeId exists by fetching for the Place by ID
Auto populate user using the user ID of the user who executed the function
Create document in corresponding collection

Create User

This function triggers when a user creates an account. The only thing the function does is creates a User document using the user ID and name.

Process Photo

Because the Storage API only supports files without any other metadata besides name (which is read-only via JavaScript), a Photos collection is used for the metadata (linking the user and place to the photo). An Appwrite function is used to keep the Photo document and file in sync as well as perform any processing on the photo. The flow for uploading a photo is as follows:

Create Photo document
Create File providing the Photo document ID as the custom ID

The Process Photo function, then, triggers and does the following:

Exits if bucket is not the Photo Uploads bucket
Get user ID from File read permission
Validate user ID matches the Photo document’s user
- This ensures the user who uploaded the file is the same as the user who created the document.
Download the uploaded file from Photo Uploads bucket
Resize the image so photos are not unnecessarily large
Remove location metadata from the photo to protect user privacy
Create a new file in Photos bucket
Update the fileId of the existing Photos document with the newly created file ID
Delete file from Photo Uploads bucket to prevent the bucket from getting too large

Front End

The front end is built with the following libraries:

React because it’s a widely popular front end library
TypeScript because the static type checking greatly improves the developer experience by catching errors early and providing informative code completion
MUI because it’s a widely popular UI library and makes it quick and easy to build a nice looking, responsive UI
React Leaflet because we’re using React and Leaflet is an open source mobile friendly maps library with lots of plugins

Fetching GPS Data

The magic that makes working with the GPS data so easy is the React Leaflet library. When people first came to the discord server asking how to query the data, I thought it was necessary to use trigonometry to calculate the North-South-East-West bounds given a center point and a radius.

Doing the math was one approach, but I soon learned it was totally unnecessary. It turns out the React Leaflet library exposes a map.getBounds() function that returns a LatLngBounds object containing North-South-East-West bounds of the current view of the map.

map.getBounds()
{
  "_southWest": {
    "lat": 51.46684144864419,
    "lng": -0.15964508056640628
  },
  "_northEast": {
    "lat": 51.5429188223739,
    "lng": -0.020256042480468753
  }
}

So, the only thing left to do was to build a query to filter based on these bounds:

const b = map.getBounds();
const documentList = await sdk.database.listDocuments<Place>(
  Collections.Places,
  [
    Query.greater(Attributes.Places.Latitude, b.getSouth()),
    Query.lesser(Attributes.Places.Latitude, b.getNorth()),
    Query.greater(Attributes.Places.Longitude, b.getWest()),
    Query.lesser(Attributes.Places.Longitude, b.getEast()),
  ]
);

Gotchas

Panning East and West

Since the earth is round, if you pan West, you’ll eventually end up back in the same place as you started. However, how does this translate to longitude in the app? It turns out, Leaflet doesn’t reset the longitude and just continues to decrement or increment. For example, if you start at (40.71, -74.01) and go West around the world twice to the same location again, you’ll end up at (40.71, -794.01). This causes problems when viewing places and adding a place.

Panning when Viewing a Place

The problem with panning when viewing places is if a place was added at (40.71, -74.01), but the user panned to (40.71, -794.01) they wouldn’t see the place.

To handle this, if a user pans past a certain point, the map will reset to stay within a certain range. When using 0 and 360 as the range, I noticed a problem where the map appeared to glitch when crossing the boundary. This can be improved by using -180 and 180 as the boundary. Since this boundary is over the Pacific Ocean, without any land, the glitch was much less visible and may not even be experienced if the user doesn’t pan across the Pacific Ocean.

Panning when adding a place

The problem with the panning when adding a place is if someone pans to (40.71, -794.01) and adds a place there, when someone views the same location, but at (40.71, -74.01), the place won’t appear.

To solve this problem, I modified the longitude right before sending it to Appwrite. While the longitude was less than -180, add 360. While the longitude was greater than 180, subtract 360.

Conclusion

As you can see, it’s perfectly possible to create a location-based app with Appwrite even without geo queries. Places effectively showcases:

How to design related collections
How to ensure integrity of related data via Appwrite Functions
How to store and fetch location data

Although it wasn’t mentioned in this article, Places also makes use of:

Realtime API to fetch asynchronously processed data
Responsive design to build a Progressive Web App

To see a demo of Places, browse to https://places.pages.dev. For the full source code, check out GitHub.

Places: Appwrite and Maps

Steven — Sat, 07 May 2022 07:20:25 +0000

Overview of My Submission

Places is an app that allows users to tag a location on a map and comment and/or upload photos for the location.

The app is a responsive web app to ensure easy access without the need to download another app. The front end uses React, MUI, React Leaflet, and Redux Toolkit.

I got the idea for the app after using Plug Share and thought it would be useful to have a similar app to provide information about where dog waste bag dispensers were and if they were in stock or not. In addition, it was a good way for me to play around with maps as there have been people on the Appwrite Discord server asking about how to work with location data on Appwrite. As I started building the app, however, I realized I didn't need to narrow the use case to just dog waste dispensers; the app can actually serve as a starting place for any location based app!

Submission Category:

Web2 Wizards

Link to Code

stnguyen90 / places

Places

This app allows users to add comments and photos to locations on a map.

Getting Started

Appwrite

The following steps use the Appwrite CLI to set up Appwrite.

Create the project via the Appwrite Admin Console
- ID: places
- Name: Places
Copy the appwrite.json.default to appwrite.json
Deploy the collections
1. echo a | appwrite deploy collection
Create an API Key
1. appwrite projects createKey --projectId places --name "Places Functions" --scopes documents.read documents.write files.read files.write
2. Take note of the secret
Deploy the functions
1. Update variables in the appwrite.json
  1. APPWRITE_FUNCTION_ENDPOINT - your HTTPS Appwrite endpoint
  2. APPWRITE_FUNCTION_API_KEY - the secret from the previous step
2. Compile each of the functions in the appwrite-functions folder:
  1. Go into the function folder
  2. Run npm i && npm run build
3. Go back up to the folder with appwrite.json and deploy all the functions:
  1. echo a | appwrite deploy function
Create the storage buckets
1. appwrite storage createBucket --bucketId photo-uploads --name…

View on GitHub

Additional Resources / Info

A live demo can be accessed here.

Technical details of the app can be found here.

Handling Null JSON Arrays in Go

Steven — Fri, 10 Jul 2020 21:25:09 +0000

One of the most frustrating things with Go is how it handles empty arrays when encoding JSON. Rather than returning what is traditionally expected, an empty array, it instead returns null. For example, the following:

Outputs:



{"Items":null}

This occurs because of how the json package handles nil slices:

Array and slice values encode as JSON arrays, except that []byte encodes as a base64-encoded string, and a nil slice encodes as the null JSON value.

There are some proposals to amend the json package to handle nil slices:

But, as of this writing, these proposals have not been accepted. As such, in order to overcome the problem of null arrays, we have to set nil slices to empty slices. See the addition of line 22 in the following:

Changes the output to:



{"Items":[]}

However, this can become quite tedious to do everywhere there can potentially be a nil slice. Is there a better way to do this? Let’s see!

Method 1: Custom Marshaler

According to the Go json docs:

Marshal traverses the value v recursively. If an encountered value implements the Marshaler interface and is not a nil pointer, Marshal calls its MarshalJSON method to produce JSON.

So, if we implement the Marshaler interface:



// Marshaler is the interface implemented by types that
// can marshal themselves into valid JSON.
type Marshaler interface {
    MarshalJSON() ([]byte, error)
}

Our MarshalJSON() will be called when encoding the data. See the additional MarshalJSON() at line 14:

This would then output:



{"Items":[]}

The Alias on line 15 is required to prevent an infinite loop when calling json.Marshal().

Method 2: Dynamic Initialization

Another way to handle nil slices is to use the reflect package to dynamically inspect every field of a struct; if it’s a nil slice, replace it with an empty slice. See NilSliceToEmptySlice() on line 15:

This would then output:



{"Items":[]}

Review

The drawback of the custom marshaler is you have to write one for every struct that has slices. Because it’s custom, though, it can target the specific field that might be a nil slice.

The dynamic initialization approach is definitely slower because every field of the struct needs to be inspected to see if it needs to be replaced. However, this approach works well if you have lots of structs with slices and few places where you call json.Marshal().

Which approach would you use? Let me know in the comments below!