English for AdonisJS Developers

AdonisJS conversations often need to justify choosing an opinionated, batteries-included framework over assembling smaller libraries, so the vocabulary covers its conventions, dependency injection model, and the trade-offs that come with structure versus flexibility.

Key Vocabulary

Batteries-included framework — AdonisJS’s design philosophy of shipping routing, ORM, validation, authentication, and testing tools together out of the box, rather than requiring teams to assemble them from separate packages. “Being a batteries-included framework is exactly why we chose AdonisJS — we didn’t want to evaluate and wire together five separate libraries just to get auth and validation working.”

IoC container — AdonisJS’s inversion-of-control container, which manages how classes and their dependencies are instantiated and bound, allowing services to be swapped or mocked without changing consuming code. “Because this service is resolved through the IoC container, we can swap in a mock implementation for tests without touching the controller that uses it.”

Service provider — a class responsible for registering bindings into the IoC container and bootstrapping a feature or package when the application starts, AdonisJS’s mechanism for wiring in new functionality. “We wrote a service provider to register our custom logging binding — now any part of the app can request it through the container.”

Lucid ORM — AdonisJS’s built-in ORM for interacting with relational databases, including model definitions, migrations, and query building, following Active Record-style conventions. “We didn’t need to add Prisma or another ORM — Lucid ORM handled the migrations and model relationships we needed out of the box.”

Convention over configuration — the design principle behind AdonisJS’s folder structure, naming rules, and defaults, meaning less explicit setup is required as long as you follow the framework’s expected patterns. “Convention over configuration is why this controller was picked up automatically — we didn’t have to manually register the route once the file followed the expected naming pattern.”

Common Phrases

• “Is being a batteries-included framework actually worth it here, or does this project need more flexibility than AdonisJS’s defaults provide?”
• “Is this dependency resolved through the IoC container, or is it being instantiated directly, which would make mocking it harder?”
• “Do we need a dedicated service provider for this, or can it just live inside an existing one?”
• “Should we use Lucid ORM’s built-in relationships here, or does this query need something more custom?”
• “Is this breaking because we’re not following convention over configuration, or is there an actual bug in the routing?”

Example Sentences

Justifying a framework choice to the team: “We picked AdonisJS specifically because it’s a batteries-included framework — auth, validation, and the ORM are already integrated, so we’re not maintaining glue code between separate libraries.”

Reviewing a dependency injection pattern: “Register this through the IoC container instead of instantiating it directly in the constructor — that’s what makes it swappable in tests.”

Onboarding a new developer: “A lot of this works automatically because of convention over configuration — as long as your controller follows the expected naming and folder structure, AdonisJS wires it up without extra registration.”

Professional Tips

• Justify batteries-included framework choices with a concrete list of what you’re not maintaining separately — it’s a stronger argument than a general preference for “less setup.”
• Explain the IoC container in terms of testability — it’s the reason a dependency can be mocked cleanly, which is a concrete benefit reviewers care about.
• Use service provider precisely when describing where new functionality gets registered — it helps new contributors find the right place to add bindings.
• Warn new team members about convention over configuration early — code that “just works” until a naming convention is violated is a common source of confusing early bugs.

Practice Exercise

1. Explain what a batteries-included framework is and why a team might choose it over assembling smaller libraries.
2. Describe how the IoC container makes a dependency easier to mock in tests.
3. Write a sentence explaining to a new hire why their controller wasn’t picked up automatically, in terms of convention over configuration.

In Practice: Navigating Feedback & Collaboration

Many of you are likely working on complex projects with multiple contributors, and that inevitably leads to discussions about code quality, potential improvements, and overall direction. As AdonisJS developers, you’ll need more than just technical vocabulary; you’ll need the ability to articulate your ideas clearly, understand feedback constructively, and effectively collaborate within a team. This is where nuanced English becomes crucial – not simply knowing what to do, but how to say it.

One common scenario is receiving a code review comment. Let’s imagine a colleague points out that a dependency injection binding in your IoC container feels overly specific. They might write: “This binding seems quite rigid; could we explore more flexible alternatives to accommodate potential future changes?” Simply responding with “Okay” isn’t sufficient. A better approach would be to acknowledge the concern, ask for clarification, and explain your reasoning. You could say something like, “That’s a good point – I was aiming for explicit control here to ensure [specific requirement], but I appreciate you highlighting the potential for future flexibility. Could we discuss what those potential changes might look like?” Notice the use of phrases like “that’s a good point,” “appreciate you highlighting,” and “could we discuss.” These demonstrate active listening and a willingness to consider alternative perspectives, key elements in professional communication.

Similarly, when writing Pull Request descriptions, clarity is paramount. Avoid vague statements like “Fixed bug” or “Updated code.” Instead, provide context: “Implemented a new retry mechanism for database connections to improve resilience against transient errors. This addresses the intermittent connection failures observed during peak load (see #42 in the issue tracker).” Using precise language – “resilience,” “intermittent failures,” “peak load” – demonstrates your understanding of the problem and provides valuable information to reviewers. It’s also vital to explain why you made a particular decision, even if it seems obvious to you. Don’t assume everyone shares your immediate intuition; articulate your thought process.

Finally, remember that English in this context isn’t just about technical accuracy; it’s about building trust and rapport within the team. Being proactive, polite, and willing to explain yourself goes a long way toward fostering a positive and productive development environment. It’s often more important how you communicate than what you say.

Here’s an example of using adonis-lucid to demonstrate a change in database configuration:

# Example command to update the database connection string in a PR description
adonis migrate:refresh --database=development