Intro

Modern engineering teams often ask: “Should we use a mono-repo?” But this question usually hides deeper ones: How are our applications and teams structured? How are responsibilities and dependencies managed?

Let’s build a mental model for thinking about mono-repos and dependencies beyond just tools. I’ll demystify terms like “monolith” and “mono-repo” through real examples and practical stories.

Definitions: Same Thing, Different Names

In purely technical terms, there’s no difference between mono-repos and monoliths. They both refer to a single source repository that contains multiple applications with related code, but multiple separate “outputs”

The biggest difference lies in how these “outputs” are structured:

• The monolith: Multiple APIs and web pages exposed, but the entire repository is deployed together
• Modern mono-repos: Different parts can potentially be deployed independently

Think of a monolith like monolithic architecture in buildings carved from a single piece of material. It may have multiple uses, but it’s fundamentally one thing.

Let’s start with something familiar — our oldest mono-repo. The monolith has:

• One shared database (MongoDB)
• Multiple JSON APIs
• Multiple HTML UIs (some forms, settings, admin)
• Separate “engines” for different functionalities

The key insight: these outputs share the same database, so they also need to share the same model logic. If you change anything in MongoDB, you’ll often need to update multiple engines.

This shared dependency is exactly what mono-repos help us manage.

From Simple to Complex

Every application starts simple (maybe just one file). As you add features, you naturally create dependencies:

// Feature 1 imports shared utilities
import { sharedFunction } from './utils';

// Feature 2 also uses the same utilities
import { sharedFunction } from './utils';

This creates a dependency tree where both features depend on shared utilities. It’s the DRY principle (Don’t Repeat Yourself) in action.

The Russian Nesting Dolls Paradigm 🪆

1. What happens when our application needs to become more than one single application?
2. What happens when two parts of the application need to be in different repositories/languages?
3. How does that relate to dependencies?

As applications grow, we extend this paradigm from file-level to application-level dependencies. Just like Matryoshka dolls, it’s the same concept at a larger scale.

Dependency Classification: Strict vs. Loose

Understanding dependency types is crucial for mono-repo decisions:

Strict Dependencies

• Internal imports/includes: Breaking changes are manageable because you control all the code
• Dependent tasks: If one fails, dependent tasks will fail quickly
• Database structure changes: You can see all affected areas immediately

Loose Dependencies

• HTTP APIs: Should be robust and handle changes gracefully
• External packages: Versioned and can be updated at your pace

Key insight: If you’re working with mostly strict dependencies, you’ll benefit from a mono-repo. If working with mostly loose dependencies, separate repositories might be better.

Separation of Concerns

Mono-repos allow us to create hard boundaries and explicit dependencies in our codebase. Common reasons include:

1. Shared Dependencies (Tightly Coupled)

Example: Monolith engines sharing MongoDB access

2. Ordered Task Execution

Example: Integration tests needing the application running successfully first. Or building a Typescript application requires type-checking to pass.

3. Package Boundaries

Example: Exposing part of an application as a package while preventing internal dependencies from bleeding out

4. Team Ownership

Example: Different squads responsible for different engines, but all sharing core infrastructure

Decision Framework: Mono-repo vs. Separate Repos

Here’s a practical guide for making the choice:

Remember: Synchronized deployments between separate repos are always painful and should be avoided if possible.

“It Depends”

There’s no universal best practice for mono-repos. You need to understand that mono-repos exist to manage dependencies and separation of concerns.

Key principles:

• Understand your dependency types (strict vs. loose)
• Identify shared code and utilities
• Consider team structure and ownership
• Evaluate deployment requirements
• Choose consistent development processes

TLDR;

• Mono-repos and monoliths are technically the same thing
• The decision hinges on dependency management and separation of concerns
• Strict dependencies favor mono-repos; loose dependencies favor separate repos
• There are no universal best practices — it depends on your specific context
• Understanding these concepts becomes crucial as AI changes how we write code

The goal isn’t to follow trends or use the latest tools. It’s to build maintainable systems that serve your team and users effectively. Whether that’s a mono-repo, multiple repositories, or something in between depends entirely on your specific dependencies and constraints.

Why mono-repos? Mono-repos, Monoliths and Dependencies. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the fast-paced world of blockchain development, Solana stands out as a high-performance platform for decentralized applications (dApps). Yet, a persistent challenge complicates the experience for developers and security researchers alike: many Solana programs are closed-source and do not publish their Interface Definition Language (IDL). This article delves into why IDLs matter, the problems their absence creates, and how tools like getIDL.xyz are stepping in to address the issue, fostering greater transparency in the Solana ecosystem.

What is an IDL and Why Does It Matter?

An Interface Definition Language (IDL) in Solana is a JSON file that acts as a blueprint for interacting with a Solana program. It outlines the program’s public interface, detailing account structures, instructions, and error codes. Think of it as an instruction manual akin to an Application Binary Interface (ABI) in Ethereum that tells developers how to call functions, pass parameters, and interpret responses.

IDLs are invaluable for several reasons:

• Simplified Integration: They allow developers to generate client-side code quickly, streamlining the process of building dApps that communicate with Solana programs.
• Consistency: By standardizing program interactions, IDLs reduce errors and ensure reliable communication between dApps and on-chain programs.
• Security Analysis: For researchers, IDLs provide critical insights into a program’s structure, making it easier to audit for vulnerabilities.

Without an IDL, interacting with a Solana program becomes a guessing game, requiring developers to reverse-engineer the interface – a task that’s both time-intensive and prone to mistakes.

The Problem: A Lack of Transparency

The Solana ecosystem faces a notable transparency gap. Recent data reveals that only about 50% of the top 100 Solana programs and a mere 20% of the top 1,000 publish their IDLs. This scarcity poses significant hurdles:

• For Developers: Integrating with a closed-source program without an IDL means painstakingly deciphering its bytecode or transaction data. This extra work slows down development and increases the risk of errors.
• For Security Researchers: Analyzing a program’s security without an IDL is like assembling a puzzle with missing pieces. It hampers efforts to identify vulnerabilities, raising the stakes for the entire ecosystem.

As one researcher put it, “Every integration and every meaningful security analysis starts with a fundamental question: how do I even talk to that program?” Without an IDL, answering that question demands unnecessary effort and introduces opacity where clarity is needed most.

Enter getIDL: Recovering the Missing Manual

To tackle this issue, I created a tool called getIDL.xyz that has emerged as a practical solution. Designed to recover IDLs from closed-source Solana programs (particularly those built with the Anchor framework) getIDL uses clever analysis to reconstruct the instruction manual that developers and researchers crave.

How getIDL Works (for Anchor-based programs)

getIDL leverages the structure of Anchor, a widely used framework for Solana development that embeds specific markers into program bytecode. Here’s a high-level look at its process:

1. Instruction Detection: Anchor inserts a function at the start of each instruction handler. getIDL scans the bytecode to identify these entry points and uncover the program’s instructions.
2. Account Analysis: Using Anchor’s try_account function, the tool follows the control flow to determine the accounts required for each instruction, along with constraints like mutability or signer status.
3. Parameter Inference: Parameters are trickier, lacking clear patterns. getIDL employs a mix of simulation, trial-and-error, and educated guesses to infer parameter types and lengths.

The result? A reconstructed IDL that, while not flawless, captures critical details like instruction names, account requirements, and basic parameters. It may miss nuances like structural account relationships or bump seeds, but it provides a solid foundation for further exploration.

Limitations and Strengths

getIDL shines with Anchor-based programs, where its accuracy is impressive, but right now it’s less effective for programs built without Anchor or with heavy customization. Still, its ability to save hours of manual reverse-engineering makes it a game-changer for many use cases, from dApp integration to transaction decoding.

Moving Forward: Transparency as a Goal

While getIDL is a powerful aid, it’s not a full substitute for published IDLs. The ideal solution remains for developers to share their programs’ IDLs openly, reducing reliance on recovery tools. Transparency benefits everyone: speeding up development, enhancing security, and fostering collaboration.

For now, tools like getIDL serve as a bridge, illuminating the workings of closed-source programs and easing the burden on the community. Available open-source on GitHub, alongside a detailed technical breakdown on sec3.dev, it invites contributions and exploration from anyone interested in advancing Solana’s ecosystem.

In a blockchain world where openness drives progress, the push for accessible IDLs and the tools that support it, remains a vital step forward.

The Transparency Problem in Solana and how getIDL is helping to solve it was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

(Just a bit of native ads) TLDR: just use https://opencryptolist.xyz and find your first issue literally in 3 clicks.

(I) Preamble for oldfags: 💀 Juniors RIP (soon) 💀

I’ve been reading Hacker News comments and noticing that the barrier to entry into IT is rising. Junior developers are being laid off en masse and replaced by LLMs.

Remember how people used to enter the profession? You’d get hired by a company, be given small tasks, and learn the job that way. Well, AI is disrupting that process now. A lot of basic operations: from debugging code to handling documents can easily be done by language models.

These kinds of tasks used to be a sort of “playground” for newcomers. Through small assignments, people would get familiar with the specifics of the work and gain experience to grow further. But now, thanks to AI, that stepping stone on the career ladder is disappearing. Beginners are being forced to learn and master skills on the fly, essentially skipping the traditional “start from the basics.”

At the same time, according to Indeed, in two thirds of all job positions, more than half of the required skills can already be performed by generative AI, which only makes the situation worse.

For now, the demand for junior staff hasn’t vanished, although it has clearly become much harder for graduates to find a job. Companies expect junior specialists to already possess advanced skills: a basic understanding of how to work with AI, the ability to learn independently, and so on.

(II) Why Contribute to Open Source?

There are two main reasons to contribute to open source:

1. Give Back:
   If you’ve benefited from software written and freely shared by others, you might want to pay it forward. Contributing is a great way to say thanks to the community.
2. Advance Your Career:
   Especially if you’re new to coding, contributing to open source gives you real-world experience. It boosts your resume and helps you network with other developers. Many opportunities come through open-source visibility.

Whatever your motivation, most open-source projects are happy to have contributors, as long as you follow the guidelines and make meaningful contributions.

(III) So, Why Now?

Let’s say you’re a college student who just started learning blockchain development.

Or maybe you’re already a software engineer, but you’ve never touched blockchain before. You want to get experience by contributing to a real open-source repository.

So, what should juniors do?
Want to grow as a developer and land a great job? Start building real experience. Work on real projects. Do it now – before it’s too late. And of course, do it with your Cursor-bro (but be careful with Opus 4, it can get expensive).

Don’t waste your time just sitting around — get involved in open source projects.
It’s the easiest way to get into top-tier dev teams and add real projects to your resume, instead of showing off some random code snippets.

But let’s be honest: finding the right project to contribute to is hard. That’s when laziness and excuses start creeping in – and with them comes a lack of professional growth, no meaningful feedback from experienced devs, burnout, and stagnation.

(IV) My Personal Experience

What separates us from LLMs?

When we see repetitive code, we abstract it into functions, classes, libraries.
When a DB is hard to work with, we build a framework or ORM.
We define responsibilities, test in isolation, reuse code. That’s DRY.
If LLMs take away that pain, DRY might disappear altogether. Code will turn into unreadable spaghetti. Projects will bloat to the point where no human and no LLM can manage them.

Open source is the ultimate form of DRY.

OSS has helped me get jobs, more than once:

• I skipped live coding interviews because hiring managers were impressed by my open-source libs
• I got invited to interviews because people were using my tiny library (only 15 stars!)
• An interviewer had read my article about ActionCable and was using my code snippet — our whole interview went in a different, better direction
• HR bots scan GitHub activity for keywords and contributions, which triggers interview invites
• A public repo means you never have to provide “a sample of your code” again. It’s already out there

Take this example.
If someone adds support for authenticated proxies in gocolly, I can instantly tell four things:

• He writes in Go
• He works with proxies
• He ran into a non-trivial problem
• He spent time analyzing the lib and didn’t just smash two buttons: “vibe-code” + “apply”

That’s what OSS signals: proactive problem solving. Not just a quick monkeypatch in your codebase, but sharing a fix with the community.

(V) Sold. Let’s start contributing

There are tons and tons of open source projects on GitHub that need help from contributors. Sometimes, the GitHub search bar is not the best for trying to find issues and projects. I cannot tell you how many times I have stumbled upon a random repository trying to understand whether I want to contribute there or not.

So, contributors. Here’s the issue — it’s issues. Issues are important for tracking development and progress in a project. There’s a wide range of issues from fixing mere spelling mistakes to figuring out how to build a space-time continuum in your backyard (okay, maybe not that crazy) but you get what I mean.

There’s so many projects and issues out there, but trying to find the right one for you is another story. So I went on the hunt to find other resources that made finding projects and good first issues on GitHub easier, but haven’t found any related to blockchain industry. Soooo I created my own.

Say hi to this little boy – OpenCryptoList.xyz. Find your first issue literally in 3 clicks.

This is a non-commercial project, therefore I don’t have any guilt in advertising it. BUT!

It would not be honest not to mention alternatives. What are they?

1. goodfirstissue.dev: You can find several good first issues with the option to choose your preferred language through a friendly user interface. While limited to filtering only by a given programming language, it generally inspired me to make goodfirstissue for web3.

2. Up-for-grabs.net is one of the most popular websites to find good open-source projects

3. https://firstcontributions.github.io/ is a website where you can search projects from a pre-defined list using your preferred language as a filter.

4. https://github.com/trending — trending repositories

(V) Extra: Pro Tips for First-Time Contributors

• Start small: You don’t have to jump into solving a critical issue right away. Start by fixing typos, improving documentation, or working on small bugs to familiarize yourself with the codebase.
• Ask for help: The open-source community is welcoming. Don’t hesitate to ask questions on GitHub or community forums.
• Learn as you go: Every contribution is a learning opportunity. You’ll improve your blockchain knowledge and coding skills by diving into real-world problems

Thanks for reading this article! Drop your PRs in the comments section :)

Follow me on the internet:

• https://github.com/wowinter13
• https://x.com/not_wowinter13

2025: Open Source as the Only Way to Enter the Job Market was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

My second favourite thing in an interview — right after the classic “A user browses to X in their browser; describe the request lifecycle in detail” — is the section of high-level database questions. This is where everything depends on the interviewer’s level of meticulousness. A profound, detailed response can either impress or paint you as that guy — you know, the stuffy one who knows too much and overcomplicates everything. But here’s the thing: database transactions are a minefield of misconceptions, especially when you’re expected to give short, snappy answers in an interview. Today, I want to dive into ten common myths about database transactions, exploring why they’re oversimplified half-truths in interview contexts, and why, in reality, they’re often complete nonsense.

Myth 1: A Transaction Always Completes Successfully

Short answer: “Sure, transactions are designed to succeed!”

Why it’s true in general: In an ideal spherical vacuum, a transaction commits all changes when done.

Reality check: Nope, not even close.

Transactions can fail due to crashes, timeouts, or deadlocks. If the server dies mid-transaction, rollback isn’t guaranteed, and data can end up inconsistent.

Imagine you’re transferring $100 between bank accounts — database says “debit account A,” but the server dies before “credit account B” happens. Transaction fails, and you’re left cursing the gods of ACID.

While WAL (Write-Ahead Logging) is designed to prevent partial transactions from being committed during recovery, real-world implementations can have edge cases. Database crash recovery depends on log integrity and proper fsync operations. If the transaction log itself becomes corrupted or truncated during the failure, the database might fail to identify and roll back the partial transaction. However, in well-configured systems (e.g., with fsync enabled), this risk is minimized.

def transfer_money(from_account, to_account, amount)
  ActiveRecord::Base.transaction do
    from_account.update!(balance: from_account.balance - amount)
    to_account.update!(balance: to_account.balance + amount)
  end
end

If the database connection drops after from_account updates but before to_account, the transaction should roll back — ActiveRecord relies on the database’s rollback mechanism. But if the server crashes hard (e.g., power loss) right after the first update hits the transaction log but before the second, the log might be incomplete.

Myth 2: A Transaction Locks Data Until It Completes

Short answer: “Yes, transactions lock data to ensure consistency.”

Why it’s true in general: Locking ensures isolation — a safe, solid answer.

Reality check: Not always. It depends on the isolation level. With READ COMMITTED, locks might drop after a read, letting others check the data before the transaction’s done. SERIALIZABLE keeps locks tight until the end. So, no, data isn’t always locked until the end — sometimes it’s a free-for-all.

BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance + 100 WHERE id = 1;
COMMIT;

FOR UPDATE grabs a write lock. In READ COMMITTED, another session can read id=1’s committed value before this transaction ends — say, post-SELECT but pre-UPDATE. If the server dies mid-UPDATE, the lock vanishes on crash, and nothing commits unless the log’s written. SERIALIZABLE would block that read — stricter rules apply.

Myth 3: Transactions Are Always Atomic

Short answer: “Yep, atomicity is a pillar of ACID!”

Why it’s true in general: Atomicity — everything happens or nothing does — is a defining trait of transactions.

Reality check: They’re supposed to be atomic, but reality’s messier. Atomicity fails in crashes or distributed systems if commit/rollback doesn’t fully execute.

Atomicity relies on the transaction log’s integrity. In a crash, the database uses the log to ensure either all changes are applied or none are. However, if the log is incomplete or corrupted, recovery might leave partial changes.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

If the server crashes after the first UPDATE logs but before the second, and the log’s incomplete, recovery might leave id=1 down 100 with no change to id=2. This happens if the crash hits post-log-write for the first but pre-log-write for the second. Atomicity lives or dies by the log’s integrity.

Myth 4: If an Operation Completes Successfully, All Data Has Been Updated

Short answer: “Yes, success means all changes are done.”

Why it’s true in general: In a simple world, a successful transaction implies all intended updates are locked in.

Reality check: Define “operation.” If we mean the whole transaction, a commit should mean all data’s updated — but “should” isn’t “does.” If “operation” is one query in a transaction, others could still fail, triggering a rollback. Plus, even after a commit, data might stay in memory before hitting disk (dirty pages). Success isn’t as final as it sounds. Committed data might stay in memory, not disk. A crash post-commit can lose it if the WAL isn’t durable yet. In databases like PostgreSQL, with asynchronous commit, there’s a small window where committed data hasn’t been flushed to disk. Proper configuration (synchronous_commit=on) minimizes this risk, ensuring durability at the cost of performance.

BEGIN;
UPDATE users SET name = 'Alice' WHERE id = 1;
COMMIT;

COMMIT succeeds, but the data might sit in the buffer. If the server dies post-COMMIT but pre-flush (no fsync), and the WAL isn’t durable yet, the update’s gone on restart. This window’s small — milliseconds — but real.

Myth 5: Atomicity Always Guarantees No Conflicts

Short answer: “Atomicity keeps everything conflict-free!”

Why it’s true in general: Atomicity’s about indivisibility, so it’s easy to assume it avoids conflicts.

Reality check: Ha, nope. Atomicity ensures a transaction’s all-or-nothing, but it doesn’t stop concurrent transactions from clashing. Deadlocks, lost updates — those are isolation problems, not atomicity’s job. Two atomic transactions can still fight over the same row. Atomicity is per-transaction, while isolation governs how transactions interact. Even with atomic transactions, poor isolation can lead to anomalies like dirty reads or lost updates.

BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
SELECT * FROM accounts WHERE id = 2 FOR UPDATE;
UPDATE accounts SET balance = balance + 100 WHERE id = 1;
UPDATE accounts SET balance = balance - 100 WHERE id = 2;
COMMIT;

If another transaction locks id=2 first, then tries id=1, we’re deadlocked. If the server dies mid-deadlock, one might commit partially if the log’s written up to an UPDATE — timing matters. Atomicity’s per-transaction, not system-wide.

Myth 6: Write Operations to Caches or File Systems Are Also Atomic

Short answer: “Uh, yeah, atomicity extends everywhere (and covers everything)”

Why it’s true in general: You might assume transaction atomicity covers related systems.

Reality check: Depends entirely on the system. Database transactions might be atomic, but caches and file systems? Some caches (like Redis with transactions) can pull it off, but most don’t worry. File systems vary — some support atomic writes, others leave you with half-written files if power cuts out. Atomicity stops at the database entrance unless explicitly built elsewhere. Redis, for example, offers command-level atomicity, but multi-command scripts aren’t transactional unless wrapped in a MULTI/EXEC block. Even then, if the server crashes mid-script, partial updates can stick.

If Redis crashes mid-SET, the write might truncate or corrupt — say, after writing half the value. No rollback here; Redis’s atomicity is command-level, not transaction-level. If the server dies during a multi-command script, partial updates stick.

Myth 7: Rollback Is Always Possible

Interview short answer: “You can always roll back a transaction”

Why it’s true in general: Rollback’s a cornerstone of ACID’s “abort” option.

Reality check: Not in every universe. NoSQL systems? Many don’t even offer it. Commit’s final, or failures leave you with manual cleanup. Physical failures (disk crash mid-transaction) can also make rollback a fantasy. MongoDB, for instance, only supports rollbacks in replica sets (post-4.0). In standalone mode, there’s no rollback — writes stick. Even in relational databases, if the server crashes mid-transaction and the log is partial, recovery might commit partial changes.

Mongoid::Session.default.with_transaction do
  User.create!(name: "Alice")
end

MongoDB only rolls back in replica sets. If the server dies mid-transaction and the session drops — say, after create!(), but before commit — writes might stick. Standalone mode? No rollback.

BEGIN;
INSERT INTO users (name) VALUES ('Alice');
COMMIT;

Rollback works pre-COMMIT in PostgreSQL. But if the server dies mid-INSERT and the log’s partial — say, after writing the row but before transaction end — recovery might leave it committed. NoSQL like MongoDB might not even offer rollback; writes stick post-failure.

Myth 8: Atomic Operations Are Always Fast

Short answer: “Yes! ”

Why it’s true in general: It’s a feel-good assumption. Golang creators wouldn’t call a package containing fast sync primitives — atomic.

Reality check:

Atomicity can slow down with big data or contention. Atomic doesn’t mean fast. Big data or slow resources (disks, networks) can drag it out. Speed’s not part of the deal. An atomic operation locking a million rows or syncing across a slow network can crawl. Atomicity’s about correctness, not performance. A complex transaction can be atomic and still take ages. In databases, atomic operations often require locks, which can block other transactions and degrade performance, especially with large datasets or high contention. For example, updating a million rows in a single transaction will hold locks for the duration, potentially causing bottlenecks.

BEGIN;
UPDATE users SET last_login = NOW();
COMMIT;

This locks the table atomically. With millions of rows, it crawls — locks block reads/writes until done. If the server dies mid-UPDATE, partial writes might commit if the log’s written up to that point.

Conclusion: