DEV Community: Matan Shidlov

How to Fix the “Record to Delete Does Not Exist” Error in Prisma

Matan Shidlov — Tue, 14 Jan 2025 11:26:52 +0000

When you use Prisma to interact with your database, you might run into an error that says:

An operation failed because it depends on one or more records that were required but not found. Record to delete does not exist.

In plain English, this means Prisma can’t find the record you’re trying to delete because your where clause does not match a unique key. Below, we’ll walk through how this happens and the steps to fix it, using a blog post example model.

Why This Error Occurs

In Prisma, when you delete a record like so:

await prisma.post.delete({
  where: { /* Some criteria */ },
});

the where clause must reference a unique key—e.g., a primary key (@id), a field marked with @unique, or a group of fields defined with @@unique([...]) or @@id([...]) (a composite key).

If you include fields that aren’t guaranteed to be unique, Prisma won’t find (or won’t allow) the record because it doesn’t match the unique constraint, triggering the “Record to delete does not exist” error.

Example Scenario

Let’s say you have this model in your schema.prisma file:

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String
  published Boolean   @default(false)
}

Here, id is the only uniquely identified field by default (the primary key).

1. Deleting by Primary Key Alone

Because id is unique, you can safely delete by id alone:

async function deletePost(id: number) {
  return prisma.post.delete({
    where: { id },
  });
}

This works perfectly if all you need is the id to identify which Post to delete.

2. Checking Other Fields Before Deleting

What if you need to ensure that the post’s title matches before deleting it? Since title is not unique in the schema, you can’t just do:

// This might fail because (id, title) isn't a unique combination in the schema
await prisma.post.delete({
  where: {
    id,       // valid unique field
    title,    // not unique
  },
});

Instead, you can:

Find the record first by id and title (without requiring it to be unique).
Throw an error if it doesn’t match.
Delete it by the primary key (id).

async function deletePostByIdAndTitle(id: number, title: string) {
  // 1. Find the post by `id` and `title`
  const post = await prisma.post.findFirst({
    where: { id, title },
  });
  if (!post) {
    throw new Error('No post found with that ID and title');
  }

  // 2. Delete by the primary key
  return prisma.post.delete({
    where: { id: post.id },
  });
}

This sequence ensures that you only delete a post if both id and title match the record you expect.

3. Using a Composite Unique Key

If your business logic requires (id, title) to be a unique pair, you can define a composite constraint in the schema:

model Post {
  id        Int      @default(autoincrement())
  title     String
  content   String
  published Boolean   @default(false)

  @@unique([id, title]) // or @@id([id, title]) if you want them as a composite primary key
}

Now, Prisma recognizes (id, title) as a unique combination. You can then do:

await prisma.post.delete({
  where: {
    id_title: {
      id,
      title,
    },
  },
});

(The exact syntax—id_title: { id, title }—comes from how Prisma interprets composite keys in your schema.)

Conclusion

To avoid the “Record to delete does not exist” error:

Delete by a unique field (e.g., id) if that’s sufficient.
Check first, then delete if you need to match non-unique fields.
Define composite unique keys if multiple fields must uniquely identify your record.

By aligning your where clause with a valid unique or primary key—either by using existing unique fields or by creating a composite constraint—you’ll ensure your Prisma .delete() operations work without error.

SSO Gone Wrong: Insights from a Real Breach

Matan Shidlov — Thu, 09 Jan 2025 13:36:10 +0000

In one of my past projects, we experienced a critical security breach when a white-hat security researcher reported a vulnerability that allowed unauthorized access to one of our root system admin accounts. This superuser account was designed to facilitate support operations, granting access to other accounts for internal use only. While the situation could have been catastrophic, we were fortunate for two key reasons:

The Researcher’s Intentions Were Ethical: The security researcher acted with goodwill and a bounty incentive. They demonstrated that they could log in without exploiting the access to harm or compromise client data. Notably, the researcher did not realize that the compromised superuser account could access other user accounts, limiting potential damage.
Limited Exposure to the Vulnerability: The vulnerability, known as "nOAuth," was rooted in Microsoft Azure Active Directory’s Single Sign-On (SSO) feature. This feature had been deployed in our application only 2-3 days prior to the breach. Once notified, we acted quickly, disabling the Microsoft Azure AD SSO login feature to close the vulnerability until a proper fix could be implemented.

Understanding the "nOAuth" Vulnerability

The "nOAuth" vulnerability was a critical flaw in Microsoft Azure Active Directory (Azure AD) applications utilizing the "Log in with Microsoft" feature. This security gap allowed attackers to impersonate users by modifying the email attribute in their Azure AD profile to match the target victim’s email. If an application relied solely on the email claim for user identification, it could inadvertently grant unauthorized access to attackers.

Attack Flow:

Preparation: With administrative privileges in their Azure AD account, the attacker altered their "Email" attribute to mimic the target victim’s email address.
Exploitation: Using the "Log in with Microsoft" feature on a vulnerable application, the attacker could successfully log in. The application identified users based solely on the email claim without additional verification.

Why It Happened:

The vulnerability exploited a design flaw in applications that depended on mutable and unverified claims, such as the email attribute, for user identification or authorization.

We aimed to give existing users the option to log in with different authentication methods to the same account. For example, a user signing up with a Google account could access their account using another method, provided the same email address was used. However, prioritizing the user email address received in the OAuth2 callback to identify user identity exposed our application to this vulnerability.

Mitigation

Immediate Actions Taken:

Once the vulnerability was reported, we acted according to a pre-determined protocol designed to handle severe security risks:

Disabled the Microsoft Azure AD SSO feature, effectively eliminating the risk.
Informed all client-facing representatives and company executives about the incident.
Held an all-hands meeting with the development team to decide on a course of action.
Analyzed login data to gauge the severity and scope of the incident.
Sent targeted notifications to users affected by the Microsoft SSO feature, offering guidance and points of contact for support.

Lessons Learned

To prevent similar vulnerabilities, applications must implement robust security practices and use Immutable Identifiers Instead of relying on mutable claims like the email attribute, use immutable identifiers such as the sub and iss ID Token claims to uniquely identify users and their identity providers.

Example Code:

// Extracting immutable 'sub' claim for user identification  
const jwt = require('jsonwebtoken');

function verifyToken(token) {  
   const decoded = jwt.decode(token, { complete: true });  
   const userId = decoded.payload.sub; // Immutable user identifier

   if (!userId) {  
       throw new Error('Invalid token: Missing subject claim');  
   }

   return userId;  
}

Product Options

When a user logs in with different methods, there are several ways a product can address associated security and usability challenges:

Restrict Cross-Provider Logins: Require users to be uniquely identified by an immutable identifier, such as the oid, ensuring email addresses do not overlap or lead to account hijacking.
Separate Accounts per Provider: Create distinct accounts for each authentication provider. This ties accounts to their unique identifiers (oid) rather than emails, avoiding issues with email duplication.
Account Merging Based on Email: Automatically merge user accounts across SSO providers if they share the same email address. However, relying solely on email for identification is insufficient; additional verification methods are necessary during the merge process to mitigate risks.

Key Security Enhancements:

User Notifications: Notify users whenever a new login method or additional SSO provider is linked to their account. Real-time alerts enable prompt responses to unauthorized changes.
Multi-Factor Authentication (MFA): Require multiple verification steps, such as email confirmations, SMS codes, or app-based authenticators. MFA is particularly crucial when merging accounts or adding new authentication methods.
Monitoring and Auditing: Continuously monitor login flows to detect anomalies. Regularly audit authentication logs to ensure adherence to security protocols and identify potential vulnerabilities. These logs are invaluable for analyzing the impact of security incidents and improving future response strategies.

Conclusion

The "nOAuth" vulnerability underscored the importance of robust security measures and proactive responses to emerging threats. Team education and pre-established security protocols played a pivotal role in our ability to respond effectively. Combining multiple measures—such as immutable identifiers, enhanced user verification, and continuous monitoring—proved essential in mitigating risks. Additionally, it is critical to approach third-party information and integrations with a grain of salt, as these can introduce unforeseen vulnerabilities. By maintaining vigilance, investing in ongoing education, and adapting to the evolving threat landscape, organizations can secure their systems and safeguard user data effectively.

How Closures Can Cause Memory Leaks and What You Can Do About It

Matan Shidlov — Tue, 07 Jan 2025 13:44:01 +0000

Introduction

Memory leaks are a developer’s nightmare, especially when they occur in production. Despite our best efforts to write clean, efficient code, subtle issues like improper use of closures can lead to memory leaks that are difficult to detect and resolve. This article focuses on understanding closures and their interaction with the garbage collector (GC), recounting my experience with an accidental memory leak caused by closures. We’ll explore how closures hold references to memory, why this can prevent the GC from reclaiming it, and the lessons learned along the way.

The Problem: A Gradual Memory Increase in Production

Everything seemed fine during development and testing. However, a few days after deploying our application to production, our monitoring system flagged an unusual memory usage pattern. The memory consumption of our Node.js application was steadily increasing over time, eventually causing performance degradation and even crashes.

Initially, I suspected external factors, such as database connection issues or unoptimized third-party libraries. But after isolating the application and reproducing the issue locally, I realized the problem was within our codebase.

The Investigation: A Challenging Path

1. Understanding Closures and the Garbage Collector

Closures are functions that "close over" their lexical scope, retaining references to variables defined in their outer scope. While this behavior is incredibly powerful, it can lead to memory leaks if developers are unaware of what variables the closure is holding onto. The garbage collector cannot release memory for variables referenced by closures, even if those variables are no longer needed elsewhere in the application.

2. Analyzing the Symptoms

Memory leaks often manifest as memory that is no longer needed but is not released. In this case, the garbage collector was unable to reclaim memory, indicating that something in our code was retaining references to unused objects. The challenge was identifying what.

3. Analyzing the Heap

I turned to Node.js Heap Snapshots to capture and analyze memory usage. By taking snapshots of the heap at different intervals, I observed:

A growing number of retained objects.
Certain closures holding references to variables long after their usefulness had ended.

4. The Culprit: A Closure Holding Large Data

After meticulously going through the heap analysis, I discovered that a closure unintentionally held onto references to variables in its outer scope, preventing them from being garbage collected. This closure was inadvertently kept alive, preventing the garbage collector from reclaiming the memory associated with the large object.

Here’s a concrete example:

function createLeak() {
    const largeObject = new Array(1000000).fill('leaky data'); // Simulating a large object.

    // The closure retains a reference to `largeObject`.
    return function leakyFunction() {
        console.log(largeObject[0]); // Accessing `largeObject` in the closure.
    };
}

const leakyClosure = createLeak();
// Even if `createLeak` is no longer called, `largeObject` remains in memory due to the closure.

What Happens in the Code:

Creation of largeObject:
Inside createLeak, a large array largeObject is created. This array uses a significant amount of memory.
Closure Retains Reference:
The inner function leakyFunction forms a closure over the outer function’s scope, which includes the largeObject variable.
Return of the Closure:
The closure leakyFunction is returned and assigned to leakyClosure.
Memory Leak:
Even if createLeak completes execution, the largeObject is not garbage collected because the closure leakyFunction still holds a reference to it.

This prevents the largeObject from being freed from memory.

The Resolution: Fixing the Leak

To resolve the issue, I redesigned the code to ensure closures do not retain unnecessary references to large objects. The solution ensures closures only retain references to necessary variables. Here’s the revised example:

function createFixed() {
    const largeObject = new Array(1000000).fill('leaky data');

    // Use the required value, not the entire object.
    const importantValue = largeObject[0];

    // Only keep the necessary data in the closure.
    return function fixedFunction() {
        console.log(importantValue);
    };
}

const fixedClosure = createFixed();
// Now, `largeObject` can be garbage collected since the closure does not retain it.

What Changed:

Only the necessary part of the largeObject (importantValue) is retained in the closure.
The large array largeObject is no longer referenced by the closure, allowing the garbage collector to free its memory once createFixed finishes execution.

Lessons Learned

This experience taught me several valuable lessons about closures and memory management:

Understand Closures and the Garbage Collector:
- Closures retain references to variables in their outer scope. If those references are no longer needed but not explicitly released, the garbage collector cannot reclaim the associated memory, leading to leaks.
Monitor Production Applications:
- Set up robust monitoring to detect memory anomalies early. Memory leaks often manifest gradually, so monitoring trends can help catch issues before they become critical.
Minimize Captured Variables:
- Design closures to capture only the variables they truly need, reducing the likelihood of retaining unnecessary data.

Conclusion

Memory leaks can be elusive, especially when they’re caused by subtle issues like closures. Understanding how closures interact with the garbage collector is crucial to writing efficient and leak-free code. With the right tools and practices, such leaks can be identified and resolved effectively. By being vigilant about cleaning up resources and mindful of what closures are capturing, you can avoid similar pitfalls and ensure your applications run smoothly in production.

Using Apache Parquet to Optimize Data Handling in a Real-Time Ad Exchange Platform

Matan Shidlov — Tue, 07 Jan 2025 12:48:12 +0000

A few years back, while working at cignal.io, I led the development of a real-time bidding platform for ad opportunities. This smart ad exchange managed a process called Real-Time Bidding (RTB). RTB is an automated system where advertisers bid in real time for the chance to display their ads to specific users visiting websites. When a partner sent an ad opportunity, our platform processed it through a series of real-time machine learning (ML) models to predict which advertising partner should receive the opportunity to bid. These models performed tasks like fraud detection, auction-winning prediction, matching advertising partners based on buying patterns, and identifying repeating opportunities. Ultimately, this system ensured that the highest bidder's ad was displayed, optimizing efficiency and relevance for advertisers and users alike.

The scale of the platform was staggering, handling 100,000 to 150,000 ad opportunities per second. Each opportunity was represented as a large JSON object of up to 2-3 KB in size. Not every opportunity received a bid; in fact, around 40-50% were filtered out by predictive models and never sent forward. For the remaining opportunities, if a bid was placed and won the auction, a notification was generated. This activity resulted in over 1 TB of data every hour. The sheer volume of data posed significant challenges for training ML models, especially when more than 90% of the data consisted of opportunities without bids.

Initial Steps to Manage Data Volume

To address the data explosion, we implemented a selective data writing approach. Only a small percentage of the ad opportunities were written to storage, focusing primarily on those that resulted in bids. For these, we added a flag to indicate whether the opportunity was part of the reduced write set. This allowed us to maintain balanced statistical information—for example, the number of ad opportunities originating from New York—while significantly reducing the volume of stored data.

This strategy improved the preprocessing workflow for Spark, which was used to join data fragments and prepare it for ML tasks. However, as the platform scaled, the demands on Spark clusters grew, increasing processing time. Delays in updating the models with new data affected the quality of real-time predictions, and the rising resource costs reduced the platform’s return on investment (ROI).

Transitioning to Apache Parquet

To solve these issues, we transitioned to storing all our data in Apache Parquet. Parquet is an open-source, columnar storage file format optimized for large-scale data processing and analytics. Developed collaboratively by Twitter and Cloudera and inspired by Google’s Dremel paper, Parquet became a top-level Apache project in 2015. Its columnar structure and support for efficient compression and encoding schemes made it an ideal choice for our use case.

We chose Snappy as the compression algorithm for Parquet, which balanced speed and efficiency. Parquet’s columnar format allowed us to store similar data types together, significantly improving compression ratios and reducing storage requirements. Additionally, Snappy compression enabled the files to be split and processed in a distributed manner, allowing us to leverage our big Spark clusters effectively. The columnar design also enabled selective reading of relevant columns during query execution, drastically reducing I/O operations and speeding up data processing.

Benefits of Using Parquet

The switch to Parquet had a transformative impact on our platform:

Reduced Resource Usage: The improved storage efficiency and compression reduced the amount of hardware and computational resources required for data processing.
Faster Data Processing: By storing data in Parquet, we dramatically decreased the processing time for Spark jobs. This allowed us to update ML models more frequently, improving their real-time prediction accuracy.
Enhanced Scalability: As our data flow grew, Parquet’s efficient format allowed us to handle increased volumes without proportional increases in infrastructure costs.
Empowered Data Scientists: The ability to process larger volumes of data during research and testing enabled our data scientists to refine and enhance all our ML models. Parquet’s schema evolution feature also allowed for seamless updates to data structures without breaking existing workflows.

Conclusion

By adopting Apache Parquet and following its best practices, we not only overcame the challenges of scaling our ad exchange platform but also improved the overall efficiency and quality of our ML models. The shift to Parquet enhanced our ability to react to real-time changes in data, optimized resource usage, and provided our data science team with the tools to innovate further. This experience underscored the value of choosing the right data storage format for high-scale, data-intensive applications.

Optimizing Data Pipelines for Fiix Dating App

Matan Shidlov — Sun, 05 Jan 2025 14:07:50 +0000

Working for Fiix, formerly known as Jfiix, a mobile dating application, I took on the task of refining a crucial data pipeline. This pipeline served as the backbone of the app’s user engagement strategy. The pipeline analyzed user interactions—likes and messages—to generate match suggestions that would be delivered via push notifications. These suggestions aimed to reduce churn, boost active users, improve retention rates, increase conversion rates, and ultimately elevate the lifetime value (LTV) of the platform's user base.

Challenges Faced

The project presented two significant challenges:

Technical Challenge:
The process required over 15 hours to complete daily and exhibited a concerning trend of increased processing time as the user base grew. Preparing for user base growth to support further scaling became crucial.
Business Challenge:
Despite the intensive computations, the number of actual matches produced was limited, resulting in a poor return on investment (ROI). This inefficiency jeopardized the business goal of driving user re-engagement and retention.

Root Cause Analysis

At the core of the problem was the method used to identify potential matches. The logic involved a multi-step relationship analysis:

For example, if User A likes or messages User B, and User B then interacts with User C, this suggests User C might have interests similar to User A. This chain of interactions can help identify potential matches based on shared connections and interests. Building on this, if User C interacts with User D, there is a possibility that User D could also be a good match for User A.

The computational burden stemmed from a series of Cartesian product operations, which combine every row of one dataset with every row of another. This process exponentially increased the data volume being processed, leading to significant challenges in memory and computation. This led to excessive memory usage, data spills, high I/O operations, and intensive CPU demands.

The Solution: A Data-First Mindset

To address these challenges, I devised and implemented a new pipeline with a data-first approach, emphasizing efficiency at each stage. Here are the steps I took:

Database Optimization:

Configured the MySQL database for write optimization by fine-tuning database internals and optimizing the host server settings.

This ensured smoother data ingestion and retrieval processes.

Dedicated Interaction Tables:

Set up dedicated tables to store daily user interactions, isolating this data for streamlined processing.

Layered Processing Workflow:

Broke the pipeline into seven distinct processing steps. For example, the first step involved identifying unique user interactions and storing them in a dedicated temporary table. Subsequent steps layered additional insights, such as filtering for active users, mapping interaction chains, and prioritizing based on engagement metrics.

Each step added a new layer of processed data and wrote the results to temporary tables.

This layered approach reduced the need to hold large datasets in memory and allowed the database to perform efficient, incremental operations.

Indexing and Partitioning:

Leveraged indexing and partitioning to accelerate query performance and reduce I/O operations.

Incremental Data Processing:

Designed the pipeline to process only new data each day, minimizing redundant computations.

Results Achieved

The revamped pipeline delivered transformative results:

Performance Improvement:
- Reduced processing time from over 15 hours to under 2 hours.
- Enabled the system to handle significantly larger datasets without resource bottlenecks.
Increased Matches:
- Boosted the number of matches produced by approximately 600%, as measured by the total count of successful user connections each day compared to the previous pipeline. This increase led to a noticeable improvement in user engagement, with more users returning to the app after receiving match suggestions.
- Enhanced the relevance of match suggestions, leading to higher user satisfaction.
Business Impact:
- Achieved the primary goal of reducing churn and increasing user engagement.
- Contributed to improved retention rates, higher conversion rates, and greater LTV.

Reflections

This project provided several key insights that were instrumental in its success:

Incremental and Modular Design: Breaking down complex problems into smaller, manageable steps was critical for achieving both efficiency and scalability.
Effective Database Optimization: Leveraging features like indexing, partitioning, and write optimization resulted in substantial performance improvements.
Understanding User Interaction Patterns: A deep analysis of user relationships and interactions was central to building an effective match suggestion system.

These insights highlight the value of adopting a data-first mindset and engineering solutions that align technical efficiency with business objectives. By embracing a structured and incremental approach, we were able to overcome significant challenges and deliver measurable value to the Fiix platform and its users.

I'm Joining Amplication with a Vision to Democratize Engineering

Matan Shidlov — Thu, 07 Oct 2021 11:41:53 +0000

I've spent the last decade leading technology development, creating real-time low latency AI-based systems, processing billions of requests each day, and helping companies with their software architectures. Through the years, I've been working alongside highly talented software engineers and cloud architects. I've learned to appreciate the value of sound engineering that can make the difference in creating reliable, maintainable, flexible, and scalable software.
Now I'm excited to try and make software architecture and good engineering practices more accessible to all by joining Amplication as VP of engineering.

The Unicorns

In today's economy, what once was an unreachable title "unicorn", became another milestone in companies' way to success. Companies are experiencing hyper-growth, which leads to a severe shortage of talented developers. Any crisis in history (including COVID-19) accelerates evolution and creates new opportunities. The severe lack of gifted developers was a unique opportunity for new people to join the engineering community, and they've been integrated within both big and small organizations.

Good Engineering Is a Scarce Commodity

Unfortunately, tapping new sources of talent doesn't fill the shortage of experienced engineers who have extensive knowledge and understanding. Senior developers who can mentor inexperienced programmers and create intelligent, robust, scalable, maintainable, and flexible solutions are especially tough to find.

The Cost of Lack of Good Engineering

I've had the privilege of helping many companies with consulting on how to architect for scale. I noticed that, in many companies, low engineering standards and poor decisions were impacting business. So many developers today are writing code that "works" but doesn't stand the test of time. The main reason for this phenomenon is lack of knowledge and insufficient training. Writing code that only "works" will not withstand any of the following dynamics:
Logic Changes - adding, removing, and updating business logic
Data Changes - adding, removing, and updating fields and entities
Data Accumulates - what was once thousands of entries grows to hundreds of thousands, millions, and billions
Usage Changes - Getting more and more traffic as a result of growth and usage spikes that leads to uneven loads
Infrastructure Changes - Changes in API's of 3rd party services or products (for example, databases)
Staff changes - Original committers leave and which results in knowledge loss.

Democratization of Engineering Is the Need of the Hour

I have a vision that with Amplication, an open-source low-code platform, we can empower developers. Amplication can take care of those necessities of repetitive code and function as a developer private architect helping implement great software with a solid foundation. In my vision, senior developers will appreciate Amplication as an uncompromising shortcut, and developers at the beginning of their career will find it extremely useful as an enabler tool for quality engineering.

Amplication

Amplication is an open-source low-code platform for backend and full-stack developers. Amplication's goal is to help developers and empower their code generation. The application code owner is the developer, and Amplication supports the project by providing a robust base. When developing projects with Amplication, developers can create great applications without the nuisance of being "bogged down" with building and maintaining the application's infrastructure and architecture.

Open as a Policy

What a better way to democratize software engineering than open-sourcing it and building a community around the principles of open engineering.
I'm excited to start this journey with Amplication. I will use this platform to share our architecture decisions, best practices, and coding standards along the way and publicly build Amplication with this great community.

Please share your experience using Amplication and your vision of how Amplication can help you in your next project.

I'm always available along with the rest of the team at our Discord channel. So please join, to talk to me about anything.

DEV Community: Matan Shidlov

How to Fix the “Record to Delete Does Not Exist” Error in Prisma

Why This Error Occurs

Example Scenario

1. Deleting by Primary Key Alone

2. Checking Other Fields Before Deleting

3. Using a Composite Unique Key

Conclusion

SSO Gone Wrong: Insights from a Real Breach

Understanding the "nOAuth" Vulnerability

Attack Flow:

Why It Happened:

Mitigation

Immediate Actions Taken:

Lessons Learned

Example Code:

Product Options

Key Security Enhancements:

Conclusion

How Closures Can Cause Memory Leaks and What You Can Do About It

Introduction

The Problem: A Gradual Memory Increase in Production

The Investigation: A Challenging Path

1. Understanding Closures and the Garbage Collector

2. Analyzing the Symptoms

3. Analyzing the Heap

4. The Culprit: A Closure Holding Large Data

The Resolution: Fixing the Leak

Lessons Learned

Conclusion

Using Apache Parquet to Optimize Data Handling in a Real-Time Ad Exchange Platform

Initial Steps to Manage Data Volume

Transitioning to Apache Parquet

Benefits of Using Parquet

Conclusion

Optimizing Data Pipelines for Fiix Dating App

Challenges Faced

Root Cause Analysis

The Solution: A Data-First Mindset

Results Achieved

Reflections

I'm Joining Amplication with a Vision to Democratize Engineering

The Unicorns

Good Engineering Is a Scarce Commodity

The Cost of Lack of Good Engineering

Democratization of Engineering Is the Need of the Hour

Amplication

Open as a Policy

github, discord