Updates

When developing software, choosing the right programming language for the job is the most critical decision, as, depending on your choice, the efficiency and reliability of your application (and also your engineering team) can vary drastically.

Once this decision has been made, the real work can begin, which, in addition to building out the application itself, also requires selecting potential tools and services to integrate. Since those often cater to many different programming languages at once (not just the one you’ve selected), you then end up adopting additional languages just for those purposes.

At RONIN, we strive to provide developers with the fastest and most intuitive database for web applications. As part of that, we consider it essential to align with your existing development stack, instead of imposing new syntaxes and language paradigms on you.

That’s why, for example, RONIN schemas can be defined as TypeScript interfaces, which is how you (and most web developers) define the schemas of objects in your application anyways.

Today, we are taking this idea even further, by renaming the native data types provided by RONIN such that they align best with the native data types provided by TypeScript. This ensures that you never need to look up which data type you need in the docs. Instead, you can just write TypeScript code like you are used to (e.g. title: string;), and it will work.

As your application grows in complexity, those native data types can then be augmented with additional attributes that change the behavior of the respective field.

Building trust with your customers is not only a matter of ensuring that your application behaves in a predictable, reliable, and secure manner, but also enforcing and upholding those same standards internally, within your team.

Even the most secure applications remain vulnerable if the team, which manages the application, isn’t secure as well. Specifically, if everyone on the team has access to all resources, even if they don’t actually need to access them, it becomes very hard to predict the worst-case vulnerability scenario and prepare against it.

At the same time, however, it is essential not to slow your team down and avoid imposing unnecessary restrictions that could affect your team’s velocity.

To marry both of the aforementioned requirements, which are naturally mutually exclusive, we have added a new Teams feature, which allows for defining groups of people that should have access to a particular kind of resource on RONIN, right on the dashboard.

While it was previously already possible to invite someone to your space and restrict their permissions by choosing between the roles Owner, Editor, and Viewer, it was not yet possible to assign specific resources to people. With Teams, that’s now possible:

1. Create a Team in your Space Settings and give it a name (this could be the name of the department in your company, for example)

2. On the “Views” tab in the Team Settings, decide which views your team should access

3. On the “Members” tab in the Team Settings, invite anyone to your team

4. Change the role of the aforementioned people to “No Space Access” in the Space Settings

Afterward, the people you invited to the team will only have access to the resources that the team has access to. At the moment, the only resources that can be assigned to a team are views, which are the collections of records you see in your left sidebar. We plan to offer more kinds of resources to be assigned to teams in the future.

For the majority of professional web projects, TypeScript has become the programming language of choice and is, at this point, no longer even considered a superset of JavaScript, but rather the only viable solution for building sophisticated applications.

That’s why, at RONIN, we thrive to build the best data platform for TypeScript developers, rather than TypeScript being an afterthought or additional augmentation. This allows us to re-imagine the entire experience of interacting with data from the ground up, with TypeScript as the primary focus of our programmatic interface.

Following this objective, we are thrilled to announce that it is now possible to resolve related records without defining any custom types:

import { get } from 'ronin';

const member = await get.member({
  with: { id: '...' },
  including: ['account']
});

// This is now fully automatically typed
console.log('Account Handle', member.account.handle);

Previously, relational fields would always have the type string, because the field value is the ID of the destination record.

With the new changes, the behavior above still applies by default, however defining fields in the including instruction will now automatically cause the type of the field to adapt and instead reflect the nested fields of the destination schema. For example, in the query above, the type of the member.account field would change from string to Account.

All it takes is installing the latest version of the ronin package:

bun install ronin@latest

As a result, it is no longer necessary to provide a custom type as a generic type argument to the query. The types are fully inferred automatically, without any manual intervention. Going forward, even more instructions will cause the types to adjust automatically.

A key aspect of our mission to provide the fastest and most intuitive data platform for developers is to ensure your codebase becomes as lean and easy to understand as possible once you begin to let RONIN take care of your data-related needs.

To ensure this, our programmatic interfaces (such as the TypeScript client) are built from the ground up to expose complexity incrementally, rather than all upfront, which ensures that the flexibility of your query syntax scales proportionally to the need for more advanced functionality. No unnecessary complexity is exposed upfront.

Today, we are taking this approach one step further by introducing a new Definition tab for schemas on the RONIN dashboard. On this tab, you can now swiftly configure how your schemas should react to the creation or modification of records, such that a lot of unnecessary validation, verification and formatting logic can be omitted from your application.

Additionally, the tab introduces a new “Default Value” attribute for fields, which makes it possible to define the value that a field should contain if none was explicitly provided. This can make creating certain kinds of records a lot faster and easier, because the most common value no longer needs to be provided explicitly. Instead, you can now define this value on the dashboard and watch all of your records get updated to return it.

In order to make it easier to understand what each field attribute does in detail, the new “Definition” tab for schemas also contains descriptions explaining the behavior of each one, allowing you to stay in the flow instead of reading unnecessary documentation.

• The record counts on the “Explore” page are now formatted with decimal separators, making large numbers easier to read.

• On the “Advanced” tab in the Account Settings, you will now find a “Language” option, which makes it possible to switch between two different variants of the English language (American and British English).

• When editing schemas, you can now use the Backspace or Delete keys on your keyboard to remove fields, or duplicate them using CMD + D on macOS or Ctrl + D on Windows.

• Code blocks in the documentation now display the language or tool that was used, and offer a button for copying their contents. Additionally, it is now possible to link others to a specific heading in the documentation.

• All logged-out pages now display a “Back to Dashboard” button on the bottom right while you are logged in, which allows for easily jumping back into the dashboard.

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.

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.

• The “Definition” tab in the schema editor now provides a new “Display As” option for choosing between different UI styles for your field. For example, the "String” field type now offers “Single Line” and “Multi Line” as options, which decide the size of the text field.

• It is no longer necessary to press “Filter” at the top of the record list to reveal the button for changing which columns should be shown. Instead, that button is now always visible. Additionally, the UI of the associated modal was revamped to no longer require scrolling if a lot of columns are available within the modal.

• New filtering options named “is empty” and “is not empty” were added on the record list, for considering fields with a value of null.

• The default fields “ID”, “Created At”, and “Updated At” are now available in the modal for selecting which columns should be displayed (and in which order) on the record list.

• It is now possible to pass an entire record directly within a query, allowing for more dynamic and flexible retrieval of related data. For example, you can retrieve posts associated with a specific author by passing the author record to the query:

  const author = await get.author.with.id("corny"); 
  const posts = await get.posts.with({ author });

• It is now possible to use the including instruction for queries when addressing a singular record, not just when addressing multiple records.

• Slugs of fields on the new “Definition” tab for schemas are now generated automatically, based on the name of the field.

• The “Copy Link” button for rows on the dashboard is now called “Highlight”, as its purpose is to allow for highlighting individual rows when sharing them. A dedicated button for copying the link of the row’s detail page will be added as well.

• The “Variants” tab in the Schema Settings is no longer available, as the feature has been removed.

• The right sidebar of the Record Editor no longer shows a “Reviewers” section. Additionally, the “Status” field was removed from the sidebar as well, as all records are now “published” by default.

Building sophisticated and reliable web apps requires ensuring a consistent underlying data architecture so that the application never enters an unexpected state. This constraint must be a natural property of the data layer rather than being ensured by the application itself.

In other words, you should never choose to increase the complexity of your codebase to handle or recover from an unexpected state caused by user input, as the application, in most cases, shouldn’t have been able to get into that state in the first place.

To ensure this, RONIN is now making it easier than ever before to set the most important validation constraints for your fields with a simple click right from the dashboard: When adding a new field or editing an existing one, you can now toggle whether the value of your field should be Unique across all records of the schema and also whether the value should be Required to be present.

Both options, as usual, instantly reflect across all global replicas when changed. Afterward, any queries that could lead to an inconsistency based on the aforementioned rules will be prevented from being executed, and a helpful suggestion message will be returned instead.

Together with our recently announced feature of Record Field Actions, the newly added field constraints automatically ensure that your data stays consistent and that you never need to run cleanups or migrations. Instead, RONIN handles them for you automatically.

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.

• 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.

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.