Updates

When working with traditional databases, relational fields are commonly tedious to manage and interact with. In SQL, for example, obtaining the destination record of a relational column requires increasing the size of the original query significantly, by adding JOIN statements, causing an impedance mismatch that must be resolved with additional tooling.

RONIN deeply embeds relations into the way in which you write code, and exposes them to you in the most natural way possible: As nested fields of your records, which are automatically resolved for you, regardless of whether you are retrieving records, updating them, or even creating them.

As an example, if your app requires a “Session” schema for managing the sessions of user accounts, you could create a new session like so:

await create.session.with({
  browser: 'Chrome',
  account: {
    handle: 'elaine'
  }
});

This query will create a new record for the “Session” schema, with the browser field set to "Chrome", and the account field set to the ID of the “Account” record that RONIN will resolve for the account handle you’ve provided. No additional syntax needed.

Establishing relations and retrieving them is quite straightforward on RONIN, as you can see. And today we are taking this experience even further, by making it possible to define actions that should be triggered whenever your records are updated or deleted.

Once you’ve created sessions for the accounts of your users, for example, it is important that your application never gets into the state of an inconsistency. Meaning whenever an account is deleted, the sessions related to it must be deleted as well, otherwise sessions would remain that point to a non-existing account, and that’s likely not something you would want to allow in your application.

That’s why, as of today, every Record field defined on the RONIN dashboard now provides an Actions section in the field editor, in which you can define what should happen to the child record whenever the parent record gets updated (using set queries) or deleted (using drop queries).

Read on to learn more about the role that Record Field Actions play in your schemas.

As your web app or website grows over time, you will likely find yourself also wanting to offer an increasingly better experience to your customers, which often translates into an increased amount of complexity in your application stack.

There are different ways to manage this complexity, and as teams grow, one of those will be creating more Git repositories for different projects or parts of the app, rather than sticking to a single monorepo that combines all of them.

Once you’ve defined your RONIN schemas for one app, you will likely want to interact with the same data from multiple Git repositories. To accomplish this, you will need to set up private packages that can share code between repositories or find a similar approach of sharing code, which, in turn, requires setting up authentication, publishing, and the like. Overall, it’s therefore a rather complex process to go through.

To combat this complexity, we are now excited to announce our new “Types Package”, which is an automatically generated package containing TypeScript code that defines your RONIN schemas, which can be imported from anywhere in your Git repositories by simply running this command:

npx ronin init

The command, which is exposed by the command-line interface included in our TypeScript client, will automatically authenticate you for accessing the private Types Package of your space, install the types package for you, and even update your tsconfig.json file to load it. The package also exports a TypeScript interface for each one of your schemas, in the case that you need to pass it around your app.

Our mission at RONIN is to ensure your application loads as fast as possible, and without any loading animations (spinners, skeletons, etc). To accomplish this, we provide the fastest data platform in the industry, focused on building modern web applications.

However, ensuring the most minimal latency possible between your app and your data is only half of the story, since your app might depend on other resources that must be loaded, and if those aren’t all fast, our job isn’t done.

That’s why, today, we are announcing our brand-new Image Optimization feature, which reduces the byte size of every image loaded in your app (if those images are stored in RONIN Blob Storage) by optimizing the format of the image, pixel size, quality, aspect ratio, and other properties that contribute to ideal loading times. All without the need for a third-party tool.

Additionally, even before the image is loaded, RONIN provides a pre-generated base64 BlurHash, which you can display as the src of an <img> element when the initial markup is delivered to the browser. It ensures that no whitespace will be shown while the image is being loaded. Instead, the BlurHash provides a placeholder that looks almost exactly like the final image in a blurred form, until the final image progressively loads in and replaces it.

If you are building a React app, check out our new Image Component as well, which handles all of the above for you, so you only need to write a single line of code per image, with approximately 20 characters. It doesn’t get any simpler than that.

With the recent launch of the RONIN TypeScript Client, we thrived to make retrieving and inserting data into your RONIN space as intuitive as possible by mimicking the patterns of the human language (English) and avoiding any configuration overhead by default.

To ensure our TypeScript Client remains as straightforward to use as possible, regardless of your application architecture, we are now introducing an additional library built on top of the aforementioned piece of software: The RONIN Hono Client.

Thanks to the Hono middleware included in the client, you can initialize RONIN a single time, after which it will read the RONIN_TOKEN variable (this is where you can define an app token of your space) from your Hono context and let you easily query RONIN throughout your app.

This is particularly useful because edge workers like Vercel Edge Functions or Cloudflare Workers, which are the ideal runtime environment for Hono apps, don’t provide a concept of global variables, as all variables must be scoped to the request context (Hono context).

In preparation for the upcoming release of RONIN 2.0, which focuses on improving the developer experience and performance of the platform even further in significant ways, we are now excited to announce the official RONIN database client, written in TypeScript.

Previously, querying your database from your application required setting up complicated connection URLs, “init” functions, sometimes even hostnames, usernames, passwords, and often times the database client of your choosing would not even work on your desired runtime (e.g. edge workers).

The RONIN TypeScript Client, which is also available on GitHub, provides a completely zero-config experience in code, and only requires a RONIN_TOKEN environment variable containing an app token of your space in order to function. No need to “initialize a client”, pass complicated credentials or similar annoying requirements.

As it is optimized for the edge workers, the client is extremely lightweight and, in fact, bundles 0 additional dependencies into your code. No native Node.js modules are required either. Instead, the client mimics the behavior of fetch, making it the most portable, easy-to-use, and lightweight database client in the industry.

• It is now possible to copy the value of a field by hovering the field and pressing the button that is revealed as a result. This is especially useful for the Blob field type.

• RONIN CLI can now be used in CI to authenticate private types packages.

Thanks to our recently released Image Optimization feature, changing the size, format, quality, and aspect ratio of your image is only a matter of passing search parameters as part of the image URL, which instructs RONIN to automatically apply those changes for you on the fly.

While this solution is very flexible and can be used with any software stack and language, our goal at RONIN is to help you build the fastest web application possible, and since the best web apps out there are built with TypeScript and a framework like React on the frontend, we are now launching the RONIN React Client, which allows for easily interacting with RONIN from React apps.

In addition to providing the same easy-to-use querying interface as the TypeScript client, the React client also exposes two different components that make it a lot easier for you to render the values of your fields stored in RONIN:

• The Image component is capable of rendering Blob fields containing images, and automatically optimizes them for you for ideal loading performance. It even automatically provides a placeholder that is loaded as part of the initial markup of your app and reserves space in the layout until the final image is loaded. This placeholder mimics the final image so that any form of visual interruption is avoided.

• The RichText component can render Rich Text fields by converting all elements (e.g. paragraphs, headings, bullet lists, and so on) defined in the Rich Text editor on the RONIN dashboard into actual React elements, so you can easily render a lot of formatted text without any additional configuration or third-party packages. It is also possible to provide it with custom React components, which will then be used instead of default HTML tags.

Because RONIN considers React to be the future of modern web apps (the application you are looking at is built with React, too), we will continue adding more helper functions and components to this package over time. Please feel free to let us know on Discord if you have any suggestions for how you would like to see us improve our client libraries further.

While most database fields of web applications usually hold rather lightweight data types (such as strings, integers, booleans, and similar), certain kinds of fields (such as the avatar of an account or the preview image of a blog post) might hold larger values and therefore require a storage that is separate from the database.

Due to the “heavy” nature of large binary objects (they require more space), different considerations than those of a database are required to ensure durability, consistency, and ideal performance when accessing those objects. This often leads to setting up additional services and having to make use of different programmatic interfaces.

After all, however, binary objects, just like strings, integers, and booleans, are binary representations of a value, so why should you have to use different tools, just because the value is longer? The answer is that, with RONIN, you don’t have to:

When creating or updating records on RONIN, you can pass binary values in the form of any JavaScript object that can hold those values: Whether it is a Blob, File, ReadableStream, ArrayBuffer, or Buffer doesn’t matter. As long as you provide the binary object as the value of a field, RONIN will automatically shard the underlying data into a dedicated blob storage separate from your database and reference it from your field.

This allows you to use the same fully typed syntax you use for mutating other fields and thereby simplify your application code, while still retaining all the benefits of a dedicated blob storage.

As the amount of features increases in your application, it is essential to ensure every additional change is thoroughly tested automatically, in order to prevent the increasing levels of complexity from affecting your app’s reliability and thereby the end-user experience.

Nevertheless, in addition to preventing any kind of regression from making its way into production, it is indispensable to also prepare for the worst case in which a regression does find its way into production and ensure that such a case does not affect the operations of your business. In other words: In the rare case that something does go south, you need to be able to recover as quickly as possible, to affecting your customers.

As your database provider, it is our duty to make such a recovery affecting your data as fast and frictionless as possible, which is why you can now easily revert to a previous iteration of your data with just a single click on the “Revert” button in the new “Snapshots” section available on the Advanced tab in your Space Settings.

Snapshots are full copies of your entire database, which are taken every 10 minutes, encrypted in transit, and ultimately stored up to 6 months (at the time of writing, these thresholds may change) on our secure cloud storage, with fault tolerance across multiple regions, to ensure that, even in the case that an entire datacenter becomes unavailable, you will still be able to access your snapshots.