Signed URLs can be used to allow temporary access to private objects stored in Google Cloud Storage. In this article, we are going to learn how to generate a signed URL using Rust, but the steps should be easily translatable to your language of choice.

The final result

Google provides documentation on how to generate a signed URL, but even following those instructions, it took me a few tries to get it right, so I’m going to try to give an explanation here.

A signed URL looks like this:

1
https://storage.googleapis.com/<BUCKET_NAME>/<OBJECT_PATH>?<CANONICAL_QUERY_STRING>&X-Goog-Signature=<SIGNATURE>

We start by drawing the image into a canvas. To do this, we need to make sure the image has been loaded by the browser, which we can do with this function:

1
2
3
4
5
6
7
8
async function loadImage(url) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = () => resolve(img);
    img.onerror = reject;
    img.src = url;
  });
}

gcloud-sdk

At the time of this writing, there is no official Google Cloud library for rust. Google started working on google-cloud-rust, but it’s still under development.

The most popular alternative seems to be gcloud-sdk, so that’s what we’ll be using. This SDK uses tonic to build the gRPC clients, so a little familiarity with tonic, might be helpful.

Since we are going to focus on the Storage API, we need to add this dependency to our Cargo.toml file:

1
gcloud-sdk = { version = "0.27", features = ["google-storage-v2" ] }

A few years ago I wrote an article explaining Protocol Buffers, gRPC, and showing how to use them with Java. In this article, I’m going to show how to build the same server and client, but this time with Rust.

Project structure

There are going to be 3 parts for our example:

• Proto files
• Server
• Client

We’ll have a root folder and then a folder for each part:

1
2
3
4
/
├── client
├── protos
└── server

In this article, we are going to show how to get started with Geospatial data in PostgreSQL. More specifically, we are going to learn how to store spatial information (e.g. Coordinates in a map) and how we can index and perform searches on this data (e.g. Find all coordinates inside a given area).

Installing PostGIS

PostGIS is an extension of standard PostgreSQL that allows us to work with geospatial data. This means, if the extension is not present, we won’t have these capabilities.

To check if our database has PostGIS, we can use this query:

1
SELECT PostGIS_Version();

If PostGIS is not enabled, we will get a message similar to this one:

1
ERROR:  42883: function postgis_version() does not exist

If PostGIS is enabled, we will get something like this:

1
2
3
4
postgres=# SELECT PostGIS_Version();
            postgis_version
---------------------------------------
 3.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1

If PostGIS is not installed on our system, we can follow the installation instructions based on our system.

In this article, we are going to learn how to write software that uses configuration files using ESP-IDF.

Kconfig

Kconfig is the configuration system used by the Linux kernel and by ESP-IDF. It allows management of project settings through a structured and hierarchical menu system.

It allows developers to write configuration files that specify the available configuration options for a piece of software.

In this article, we are going to explore how the clipboard works when using different tools inside a terminal and how we can configure these tools so we get and intuitive experience.

Linux

The most basic example of using the clipboard would be using it directly from the operating system.

Most Linux distributions come with a built-in clipboard. This clipboard works as a temporary data storage that can hold a single item. To add an item to the clipboard, we can select it, right click it and select “Copy” or we can use the shortcut Ctrl-C.

There are different tools that can be used to inspect the clipboard. We will use xclip. To install:

1
sudo apt install xclip

Internationalization is the process of making a website that is adaptable to different locales (regions or languages). Translation is a large part of it, but there are other aspects, like date formatting, for example.

There is no single standard way to do internationalization. In this article we’ll learn the approach I chose, but there are other ways to achieve a similar result.

URLs

To make an internationalized app SEO friendly, it’s recommended to have locale-prefixed URLs. This means, if we have a dashboard page, the URL for it will be something like: /<lang>/dashboard.

This, of course, leaves the possibility of someone visiting our pages without a prefix, for example: /dashboard. In this scenario, we will use locale detection to redirect users to the correct page for their language.

In a previous post, we learned about asynchronous programming with Tokio. This time, we are going to use Axum to build a server that uses Tokio as runtime.

Hello world

Creating a simple server with Axum only requires a few lines:

1
2
3
4
5
6
#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(|| async { "Hello, World!" }));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

If we run this code, we will see a Hello, World! message if we visit http://localhost:3000.

I’m working a project that uses Firestore, so I’m using the firestore crate to help me interact with my database.

There are two examples showing the use of transactions in the source code:

• transactions.rs
• read-write-transactions.rs

There are some parts of those examples that are a little confusing, so I’m writing this article to try and shed some light.

I was not the only one confused by this, and luckily someone brought this up in a Github issue before I had to.