DEV Community: Sanatel Consulting

How I Built a High-Performance Backend for a Viral Content App with Fastify

Sanatel Consulting — Fri, 27 Mar 2026 21:40:43 +0000

We developed an app where users can swipe through images, and based on their likes, we generate new ones. Below is a story about the interesting challenges we faced during the development of this application.

Choosing the ID

The hardest part of development is naming variables and functions. Even harder is coming up with an ID format for entities.

In this project, there will be many images and many users, so IDs in GUID or UUID format are too taxing for table indexing and expensive in terms of backend load. We needed an ID that is "incremental" — meaning a new ID is added to the end of the table index — while remaining unique at the same time.

We settled on an ID like 19bc19e00ab-eh5kkeh99q7, where the first half is the time converted to HEX, and the second half is a random set of characters. The hyphen between these two halves doesn't serve a functional purpose, but it makes the ID more visual and easier to read.

function generateID(): string {
   const timestamp = Date.now().toString(16);
   const randomPart = generateRandomSequence( 11 );
   return timestamp + '-' + randomPart; 
}

This ID is conditionally incremental, as it changes every millisecond, and it's sufficiently unique.

Should we use a "created" field in tables?

The chosen ID format has a small perk: you don't need a "Creation Date" field in the table because the date can be decoded directly from the ID. Yes, it’s slightly inconvenient to build filters for selecting by creation date, but the absence of an extra field outweighs the selection inconveniences.

Bloom Filters

The app is expected to work under high load: thousands of simultaneous sessions and tens of thousands of images to build user feeds. At the same time, the backend must be very "cheap" in terms of CPU and memory consumption. The most resource-intensive task is keeping track of which images a user has already seen and selecting the next ones for them. Obviously, a "traditional" solution via SQL queries to the database is too heavy, slow, and inapplicable here. So, we use a Bloom filter.

If you're not in the loop, a Bloom filter is a very fast filter that says with 99.9999% probability that a specific ID is NOT in an array of tens of thousands of IDs. In terms of CPU and memory load, the savings are colossal.

App Authorization

We don’t want to force users to authorize because users hate authorization. Besides, apps without authorization pass store moderation more easily.

But we still need to identify users. So, upon installation, we generate an ID and save it in the app.

What if some enthusiasts start generating these IDs and sending them to the backend? We add a limitRate and validate new IDs for correctness. I’ll mention limitRate below, but here is the logic for checking new users:

At backend startup, we load all existing user IDs into a Bloom filter.
For a user addition request, we first check the new ID's correctness at the Fastify level by declaring a JSON schema for the request:

fastify.post( '/backend', {
    schema: {
      body: {
        type: 'object',
        required: [ 'device_id' ],
        properties: {
          device_id: {
            type: 'string',
            minLength: 23,
            maxLength: 23,
            pattern: '^[a-z0-9]{11}-[a-z0-9]{11}$'
          }
        }
      }
    }

If the new ID passes the Fastify check, we check it against the user Bloom filter. If the ID is not in the array, it’s a new user.
We verify the new user's ID for correctness.

The first half of the ID is the encoded date; this date must fall within the period between our project's launch date and today.

How to check the second half, which is a random set of characters? What if enthusiasts generate IDs like 19bc19e00ab-aaaaaaaaaaaa? We check the second half for entropy; it must be greater than 2.

function getEntropyString( str: string ): number {
   const frequencies = new Map();
   for (const char of str) {
     frequencies.set(char, (frequencies.get(char) || 0) + 1);
   }
   return [...frequencies.values()].reduce((acc, count) => {
     const p = count / str.length;
     return acc - p * Math.log2(p);
   }, 0); 
}

If the new ID is valid, we add it to the user Bloom filter and send an INSERT to the user table without waiting for the INSERT to finish. Yes, there's a problem: something could go wrong with the insert, and ideally, we should complete the insert and handle errors first. But that's taxing for the backend. Мы accept the risk of losing a user after a restart. By "losing a user," we mean that after a restart, this user will be treated as new, and their swipe history won't be saved.

Static Content via Nginx

The backend collects like stats, generates new images, and puts them in folders with a Year — Month — Day structure. In the app, images are loaded via URL. But how to serve static content with minimal server load? Fastify can do it well, but it’s even better to run Nginx on the server under a separate domain to serve content directly from the folder where the backend app stores the images.

Image Series for the User

We generate a new series of image URLs for the user in batches of 10. We add these IDs to a "Seen Images" Bloom filter for each user. When generating a new series, we check if the image was in previous batches using that filter.

Thus, the backend and mobile app communicate in series of 10 images.

At app startup, two series of 10 are loaded.
Every 10 likes, the app sends reactions to the backend and receives a new series of 10 images.

While the user is liking a series of 10 images, the app sends reactions for the previous 10 and fetches the next 10 images.

Rate Limiting

Fastify has a rateLimit plugin. It can be configured to use Redis, but if you have only one backend server for now, you can do without Redis and store everything in Node.js memory.

Validating Image Likes

The mobile app collects reactions and sends them to the backend in batches of 10. One reaction is an Image ID and a like/dislike. Again, how to solve the problem with enthusiasts who might flood the backend with fake reactions? We add a limitRate and validate reactions with the following logic:

User ID and Image ID must pass Fastify schema validation. Reactions (like/dislike) can also be validated as an enum in the schema.
User ID must pass the "Existing Users" Bloom filter check.
Image ID must pass the "Seen Images" Bloom filter check for that user.
Just in case, we check likes for "alternation." If a user just swipes everything in one direction or alternates left-right-left-right, the batch is untrustworthy and ignored:

function trustLikeInBatch10( batch: string[] ): boolean {
   if( batch.length != feedLimit ) return false;
   const likes = batch.filter( v => v === 'like' ).length;
   if( likes === 0 || likes === feedLimit ) return false;
   const switches = batch.slice(1).reduce( ( acc, val, i ) => acc + ( val !== batch[ i ] ? 1 : 0 ), 0 );
   if( switches >= 8 ) return false;
   return true;
}

If all checks pass, we send an INSERT to the reactions table without awaiting completion. Furthermore, we don't use CONSTRAINT FOREIGN KEY for User ID or Image ID in the reactions table to reduce DB load during inserts. Although the lack of FOREIGN KEYs feels very unusual.

Masking Fastify Validation Errors

To make life a bit harder for "curious" enthusiasts, we mask Fastify validation errors. By default, Fastify tells you exactly what went wrong (length, pattern, etc.). To avoid giving hints, we override the error handler:

fastify.setErrorHandler((
  error: FastifyError,
  request: FastifyRequest,
  reply: FastifyReply
) => {
  console.error( 'setErrorHandler', error );
countErrorStatistics();
  reply.code(200).send( 'Hello World!' );
});

The mobile app must be ready to receive this masked error instead of a standard one from the backend.

Creating a Type from a String Array

A small problem with an elegant solution. Let's say you have an array of strings (e.g., image states: new, broken, ready, etc.). You also need a TypeScript type that only allows these values. You can do both at once:

// Usually it's like this:
 const imageStateArray1 = [ 'new', 'broken', 'gpt', 'ready', 'download', 'done', 'bad' ];
 type tpImageState1 = 'new' | 'broken' | 'gpt' | 'ready' | 'download' | 'done' | 'bad';

// or better yet:
 const imageStateArray2 = [ 'new', 'broken', 'gpt', 'ready', 'download', 'done', 'bad' ] as const;
 type tpImageState2 = ( typeof imageStateArray2 )[ number ];

Project Summary

Essentially, the app can live almost without a database. After startup and loading IDs into memory, the only DB tasks are INSERTs without await. Inside the controller, it’s just math and Bloom filters.

Current Status and Roadmap

Phase 1: The Foundation (Current)
The current build focuses on infrastructure stability. We are testing the Bloom filters’ efficiency and the non-blocking insert logic under real-world traffic. Note: AI-feed adaptation based on likes is currently disabled.

Phase 2: Intelligence
The next stage involves enabling the real-time feedback loop. We will be connecting our AI generation models to the live data stream, allowing the feed to “evolve” based on global and individual user preferences.

https://youtube.com/shorts/zW__OFDpHOM?feature=share

Check out aura8 here: https://play.google.com/store/apps/details?id=kz.crm.aura8

What’s next?

We plan to add other categories of images besides cute kittens and puppies, such as Nature, Fantasy, and so on. Please let me know in the comments which category of AI images would make sense to add to the app:

Nature.
Fantasy.
Stylized Portraits (Girls/Characters).
Other (what?)

By “Stylized Portraits (Girls/Characters)” I mean something like:

PrimeNG + NestJS + STT API = Speech Analytics

Sanatel Consulting — Wed, 03 Sep 2025 17:26:11 +0000

We developed speech analytics for a contact center. Speech recognition is handled via the Yandex Speechkit service, while the analysis of the resulting text is performed within our own solution. During development, we encountered some interesting aspects that I will try to describe.

1. Audio player in the transcript card.

The transcript card looks like all other transcript cards in analytics: information about the audio recording and a player slider at the top, and the dialogue replicas at the bottom.

When clicking on a replica, the player should jump to the corresponding fragment of the audio. This turned out to be simple: we read the audio element from the document, and this element already has the necessary methods. We added a start_time field to replicas, measured in seconds from the beginning of the audio recording. When clicking on a replica, we call the method of the audio element and pass the required seconds:

this.audio = document.querySelector('audio');

playAudioOnClickOnItem(time: number) {
this.audio.currentTime = time; // В секундах
this.audio.play();
}

2. Highlighting words in replicas and tags.

In replicas, we need to underline or highlight with color the words found in dictionaries. Also, in replicas, there is a column where dictionary tags are placed. The question arose: where should we prepare this HTML markup of replicas? On the one hand, it seems like a frontend task. On the other hand, since the backend analytics already parses the replicas and counts the words, why not also prepare the tags there? Moreover, if we generate the HTML markup on the frontend, the backend would still need to send data about where and how many words were found for each replica. In the end, we settled on preparing it on the backend. For each replica, the backend sends a ready-made HTML string with the necessary styles, and the frontend simply displays them.

3. Editing words in a fragment.

Fragments are needed to compose a conversation script to control adherence to scripts during dialogue. A fragment consists of a set of words. The frontend receives from the backend a fragment entity, and inside it is an array of words included in this fragment. On the frontend, we created a form in which the user can change the set of words, correct words, etc. When the “Save” button is pressed, the fragment with the new word array is sent back to the backend.

4. Selecting columns in the records registry.

Usually, the registry of records does not contain many columns, so the set of columns is static. But in the case of audio transcripts, the entity can have a lot of fields, ranging from “Incoming” or “Outgoing” call to department, city, call score, number of words from one side, and so on. Therefore, in the call registry in analytics, there should be a choice of columns that the user considers necessary. The only static (mandatory) column is the clickable column with the call ID, which links to the call card.

The selected set of columns in the registry is saved in cookies in the browser, and when the user re-enters the section, the selected columns are restored.

5. JWT and user account.

There are many articles and videos on the Internet about authorization and roles in NestJs, but the topic is often not fully covered. Typically, the author explains how to create a JWT token, declares strategies and guards, and shows that authorization works — and stops there. But that’s only about 5–10% of the topic of authorization and user roles. First, the backend needs to understand which user is making the request, and then work with that.

To achieve this, we declare a simple decorator. In this example, the user account is equal to their email. The decorator selects the fields available in the payload of the JWT token. If our JWT token contains:

async login(user: any) {

const payload = {
email: user.email,
username: user.username,
role: user.role
};

return {
access_token: this.jwtService.sign(payload),
};
}

Then in the decorator, we can extract any field from the payload, for example, the email:

export const User = createParamDecorator(
(data: any, ctx: ExecutionContext): string => {
const request = ctx.switchToHttp().getRequest();

if(
request.user !== undefined
&&
request.user.email !== undefined
)
{
return request.user.email;
}
else {
return 'unknown_user'
}
});

Then in the controller, we receive the user data and can do something with it, for example, check access rights to read records:

import { User } from '../user/user.decorator';

@Get()
@ApiOperation({ summary: 'Get coversation list' })
@ApiOkResponse({ description: 'Coversation list', type: SpeechEntity, isArray: true })
findAll(@User() userMail: string): Promise<SpeechEntity[]> {
return this.speechService.findAll( userMail );
}

6. Roles and access rights — the most controversial topic.

Several questions arise:

Where in the NestJs project architecture is it correct to check access rights? In the controller or already in the service?

It seems logical to check access rights in the controller and pass conditions to the service for search. For example, a user has rights to read only the records where they are responsible.

Then:

@Get()
@ApiOperation({ summary: 'Get contact list' })
@ApiOkResponse({ description: 'Contact list', type: ContactEntity, isArray: true })
findAll( @User() userMail: string ): Promise<ContactEntity[]> {
const userAccessWhereOptions = this.userService.getUserAccessWhereOptions( userMail, controllerName );
return this.contactService.findAll( userAccessWhereOptions);
}

But inside the findAll service, there may be its own conditions for search, for example, category = new, which will need to be attached to the conditions of responsibility. And there might also be cases where “own” records are those where the user is either responsible or the author. Then the findAll service would receive two OR conditions, and we would have to add the category = new condition to both of them.

Additionally, there’s the issue of deleting records, which in reality is not deletion but setting deleted = yes. A regular user sees “own” records under the condition deleted = no, while an admin sees all records.

So far, we’ve settled on this: the access rights service returns the condition for find, already considering access rights, and also with the condition for deleted records.

where = [
{
'owner': userEmail, // Responsible for record
'deleted': 'no'
}, // OR
{
'father': userEmail, // Creator of record
'deleted': 'no'
}
];

And inside findAll, there’s a function that iterates through all conditions and adds its own conditions to them:

async findAll( userAccessWhereOptions: {}[] ): Promise<ContactEntity[]> {
const options: FindManyOptions = {
where: UtilWhereAssign(
userAccessWhereOptions,
{
'category': 'new'
}
),
order: { updated: 'DESC' },
};
const result = await this.contactRepository.find( options );
return result;
}

From UtilWhereAssign, for a “regular user,” a new search condition will be returned:

where = [
{
'owner': userEmail,
'deleted': 'no',
'category': 'new'
}, // ИЛИ
{
'father': userEmail,
'deleted': 'no',
'category': 'new'
}
];

7. On the frontend, we consider user rights.

But we also need to inform the user on the frontend that they don’t have rights for the requested operation. The backend has a method that returns the user’s role. Accordingly, if a user doesn’t have rights to add records, the frontend should disable the “Add record” or “Delete record” button, etc.

8. Change history.

Since we need to keep a log of who made what changes to entities, we create a historyService, and in all create, update, and remove methods in various services, we pass to the historyService data about the ID of the modified record and the user.

To avoid implementing change history creation for each entity, we created a universal method calcChangeAndCreate in historyService, to which we pass the old entity instance, the new entity instance, and the username. Example of update for a contact:

async update(recordId: string, updateDto: ContactUpdateDTO, userMail: string): Promise<ContactEntity> {
const options = {
where: [{ 'id': recordId }]
}
const oldResult = await this.contactRepository.findOne( options );
await this.contactRepository.update( { "id": recordId }, updateDto);
const newResult = await this.contactRepository.findOne( options );

await this.historyService.calcChangeAndCreate( 'contact', newResult, oldResult, userMail, recordId );

return newResult;
}

Inside the calcChangeAndCreate method, we compare the fields of the old and new objects, and if there are changes, we create a record in the change history:

calcChange( newEntity: object, oldEntity: object ): HistoryRecordChange {
let result = {} as HistoryRecordChange;
result.fieldChangeList = [];
result.haveChange = false;
result.user = 'no_user';
result.table = 'no_table';
result.record = 'no_record';

for( let key of Object.keys( newEntity) ) {
if( key != 'created' && key != 'updated' ) {

let newValue: string;
if(
typeof newEntity[key] == 'object'
&&
newEntity[key] != null
) {
newValue = newEntity[key].toISOString() + ' (UTC)';
}
else {
newValue = newEntity[key];
}

let oldValue: string;
if(
typeof oldEntity[key] == 'object'
&&
oldEntity[key] != null
) {
oldValue = oldEntity[key].toISOString() + ' (UTC)';
}
else {
oldValue = oldEntity[key];
}

if( newValue != oldValue ) { // Field changed
result.haveChange = true;
let fieldChange = {} as HistoryFieldChange;
fieldChange.field = key;
fieldChange.oldValue = oldValue;
fieldChange.newValue = newValue;
result.fieldChangeList.push( fieldChange );
}
}

return result;
}

The same applies to creating and deleting entities. There are also child entities, for example, a phone number in the contact’s phone list. Changes to child entities are recorded in the history of the parent entity.

Accordingly, we add the section “Change History”.

PrimeNG + NestJS = CRM — part 1

Sanatel Consulting — Tue, 12 Aug 2025 17:01:51 +0000

We decided to develop a CRM system in-house. During the development process, there were some interesting moments that I will try to describe in several articles. In the articles, I will try to avoid banalities like: downloaded, unpacked, launched, and look, swagger out of the box. There are already a lot of such articles, as well as videos on YouTube. I will try to share just interesting details that I came across during the development process. I will get ahead of myself - the system was configured and launched.

Why development, and not buying a ready-made system

For two reasons. Secondly, because purchased systems over time become so overgrown with additional settings that there is little left from the "box". And firstly, because frameworks have rapidly developed into some kind of platforms in which you have to code little.

Choosing a framework

I wanted to find a framework that already had all the Boiler code needed for a business application: menus, sections, graphs, users, etc. While searching for such a framework, we noticed the .Net frameworks https://aspnetboilerplate.com and https://abp.io, which already have a lot of things "out of the box". As far as I understand, both frameworks are being developed either by related teams, or even by one team. And the teams are from Turkey. The ASP.NET Boilerplate framework has legacy code from older versions of the .Net Framework. The newer ABP framework does not have legacy, it is on .Net Core. Both frameworks have a decent number of stars on github.

Then I came across an interesting library for the front - PrimeNG, it has three branches, for Angular, for React, for Vue. Each branch has a store with design themes, there are paid themes, there are free themes. Everything looks very beautiful, "out of the box" has everything you need for the front, menu, tabs, buttons, pop-up notifications. PrimeNG is again backed by a team from Turkey, PrimeTek.

As a result, we decided to develop on a bundle of PrimeNG (Angular) + NestJs. Because the front really wants to be on Angular, then there is a desire to save on the expertise of developers, and therefore let both the front and the backend be TypeScript.

The disadvantages of Node.js are known:

TypeScript is still an add-on, I consider the lack of data types in JavaScript a disadvantage.
The node_modules folder will contain several tens (hundreds) of thousands of files written by no one knows who.

1. Logging TypeORM queries

To work with the database, the NestJs framework uses TypeORM. The TypeORM library surprised, it handles changes made to the table structure well, replacing column types, even with data in tables. And in order to view the logs of SQL queries generated by TypeORM, you need to add logging parameter:

TypeOrmModule.forRoot({ type: 'mysql', // ... entities: [ ContactEntity, ], logging: true, // For logging SQL queries to the console }),

2. Generating UUID primary key in TypeORM

Boiler columns in tables that should be in each table by default are the primary key, creation date, update date. If you declare in TypeORM:

export class ContactEntity {
@ApiProperty({description: 'Primary key'})
@PrimaryGeneratedColumn()
id: string;

@ApiProperty({description: 'Creation date'})
@CreateDateColumn()
created: Date;

@ApiProperty({description: 'Update date'})
@UpdateDateColumn()
updated: Date;
}

Then in MySQL database it will turn into in:

CREATE TABLE contacts ( id int(11) NOT NULL AUTO_INCREMENT, created datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), updated datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6), PRIMARY KEY (id) );

Everything is fine. But for a business application, you want a UUID primary key, not an integer.

And if you declare in TypeORM:

export class ContactEntity {
@ApiProperty({description: 'Primary key'})
@PrimaryGeneratedColumn('uuid')
id: string;

@ApiProperty({description: 'Creation date'})
@CreateDateColumn()
created: Date;

@ApiProperty({description: 'Update date'})
@UpdateDateColumn()
updated: Date;
}

Then in the SQL database it will turn into:

CREATE TABLE contacts ( id varchar(36) NOT NULL, created datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), updated datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6), PRIMARY KEY (id) );

That is, the primary key is just a string, without auto-generation of the UUID value! At first it seemed strange. But it turned out that in TypeORM it is done this way deliberately, the UUID is generated in the TypeORM code and the insertion of records occurs with the UUID key field already filled. Because in the case of an auto-generated UUID column, for some types of insertion, TypeORM would then have to read the inserted records and update them again. This would ultimately work slower than generating UUID on the TypeORM side.

3. Notifications in the main menu

In the main menu, near the section names, you can display an indicator of the number of records in the section. For example, on the menu item "Orders", you need to display an indicator of orders in the "New" status so that the employee immediately pays attention to the fact that new orders have dropped into the system from the site, and these new orders need to be processed faster. For this, PrimeNG has a badge parameter.

In the AppMenuComponent module, in the menu and sections model, for the "Orders" item, specify the badge and an integer value:

this.model = [ { label: 'Разделы', items:[ {label: 'Contacts', icon: 'pi pi-fw pi-user', routerLink: ['/contact']}, {label: 'Orders', icon: 'pi pi-fw pi-table', routerLink: ['/order'], badge: 0}, ] }, ]

The value will have to be updated by the absolute address of the menu item in the model:

this.model[ 0 ].items[ 1 ].badge = countNewOrder;

System Roadmap

a) It is necessary to transfer the generation of reports in Excel from the front to the backend. Generate Excel files on the backend, and send the finished files to the front to the user. Why this seems preferable, I will explain in the next article.

b) You need to attach a task queue. Obviously, some tasks can be performed indefinitely, accordingly, such tasks need to be put in a queue, and then the results can be collected.

c) You need a workflow, for example, document processing, at least in an elementary form, for example, in the form of a reference book with stages of document approval.

d) You need to attach chats and a chat bot.

We will show some pieces of what we get on the demo stand - PrimeNG demo.

PrimeNG + NestJS = CRM — part 1

Sanatel Consulting — Tue, 12 Aug 2025 16:35:25 +0000

1. Why development, and not buying a ready-made system

2. Choosing a framework

The disadvantages of Node.js are known:

TypeScript is still an add-on, I consider the lack of data types in JavaScript a disadvantage.
The node_modules folder will contain several tens (hundreds) of thousands of files written by no one knows who.

Logging TypeORM queries

TypeOrmModule.forRoot({
type: 'mysql', // ...
entities: [ ContactEntity, ],
logging: true, // For logging SQL queries to the console
}),

Generating UUID primary key in TypeORM

Boiler columns in tables that should be in each table by default are the primary key, creation date, update date. If you declare in TypeORM:

export class ContactEntity {
@ApiProperty({description: 'Primary key'})
@PrimaryGeneratedColumn()
id: string;

@ApiProperty({description: 'Creation date'})
@CreateDateColumn()
created: Date;

@ApiProperty({description: 'Update date'})
@UpdateDateColumn()
updated: Date;
}

Then in MySQL database it will turn into in:

CREATE TABLE contacts (
id int(11) NOT NULL AUTO_INCREMENT,
created datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (id)
);

Everything is fine. But for a business application, you want a UUID primary key, not an integer.

And if you declare in TypeORM:

export class ContactEntity {
@ApiProperty({description: 'Primary key'})
@PrimaryGeneratedColumn('uuid')
id: string;

@ApiProperty({description: 'Creation date'})
@CreateDateColumn()
created: Date;

@ApiProperty({description: 'Update date'})
@UpdateDateColumn()
updated: Date;
}

Then in the SQL database it will turn into:

CREATE TABLE contacts (
id varchar(36) NOT NULL,
created datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (id)
);

That is, the primary key is just a string, without auto-generation of the UUID value! At first it seemed strange. But it turned out that in TypeORM it is done this way deliberately, the UUID is generated in the TypeORM code and the insertion of records occurs with the UUID field of the key already filled in. Because in the case of an auto-generated UUID column, for some types of insertion TypeORM would then have to read the insert