English for Encore.ts Developers

Encore.ts discussions mix backend framework terms with infrastructure vocabulary, since the framework’s whole pitch is generating cloud infrastructure from code annotations rather than separate config files.

Key Vocabulary

Service — a top-level unit of Encore.ts code, declared with a special directory structure, that the framework treats as an independently deployable microservice with its own API surface. “Move the notifications logic into its own service instead of a folder inside the main API — that way it gets its own service boundary and can scale separately.”

Infrastructure from code — Encore.ts’s approach of provisioning databases, queues, and other cloud resources automatically based on how they’re declared in application code, rather than hand-written Terraform or CloudFormation. “We didn’t write any Terraform for this queue — infrastructure from code handled provisioning it based on the Topic declaration.”

Pub/sub topic — a named message channel declared in code that services publish events to and subscribe to, with Encore.ts managing the underlying message broker. “Publish the OrderPlaced event to the topic instead of calling the shipping service directly — it decouples the two and lets us add more subscribers later.”

Local development dashboard — Encore.ts’s built-in web UI that visualizes API calls, traces, and the service architecture while running locally, without extra tooling setup. “Check the local dev dashboard before adding more logging — it already traces the full request across services.”

API contract — the typed request and response shape for an endpoint, defined directly in code, that Encore.ts uses to generate documentation and client SDKs automatically. “Update the API contract first — the generated client and docs will follow automatically once the types change.”

Common Phrases

• “Should this live in its own service, or is it tightly enough coupled to stay where it is?”
• “Is this provisioned through infrastructure from code, or did someone set it up manually in the cloud console?”
• “Are we publishing this as an event on a topic, or calling the other service directly?”
• “Did you check the trace in the local dashboard before assuming it’s a network issue?”
• “Is the API contract already updated, or is the client SDK about to go stale?”

Example Sentences

Debugging a service boundary issue: “This shouldn’t be a direct function call across services — publish it to the topic so the coupling stays loose and other subscribers can react later.”

Explaining an architecture choice: “We let infrastructure from code provision the queue and database for this service instead of hand-writing IaC — it stays in sync with the code by construction.”

Reviewing a pull request: “The API contract changed here but the client callers weren’t updated — regenerate the SDK before merging.”

Professional Tips

• Say infrastructure from code specifically when explaining how a resource got provisioned — it’s the framework’s headline feature and signals you understand the deployment model.
• Use service deliberately to mean an Encore.ts top-level deployable unit, not just “a file” or “a folder” — the framework treats the boundary as meaningful.
• Reference the local development dashboard when debugging cross-service issues instead of reaching for external tracing tools first.
• Call changes to an API contract out explicitly in PR descriptions — it signals downstream consumers and generated clients may need updates.

Practice Exercise

1. Explain what “infrastructure from code” means and how it differs from writing Terraform by hand.
2. Describe the difference between calling a service directly and publishing to a pub/sub topic.
3. Write a sentence explaining what the local development dashboard is useful for during debugging.

Navigating Nuance: Common Phrasing in Encore.ts Discussions

As developers working with Encore.ts, you’ll quickly realize that technical communication isn’t just about conveying information; it’s about doing so clearly, concisely, and respectfully – especially when collaborating across teams and potentially different cultural backgrounds. Many of the core concepts – services, pub/sub topics, infrastructure-as-code – are readily translated, but their usage in professional settings often requires a specific register, one that prioritizes precision and avoids ambiguity. A casual “this service is broken” isn’t sufficient; you need to articulate why, suggesting potential solutions or the scope of the problem. Similarly, simply stating “fix this topic” lacks context. It’s about understanding the impact on the system and communicating that understanding effectively.

A frequent scenario involves code reviews. Receiving a comment like “This needs more error handling” can feel vague. A better response – and one demonstrating you’ve understood the reviewer’s concern – would be, “I appreciate the feedback regarding error handling. I’m adding a try/catch block to handle potential network errors during data retrieval, as outlined in the service documentation. This will log the specific error type for debugging purposes.” Notice how this expands on the original comment with actionable details and references to relevant resources. It’s not just about fixing an issue; it’s about demonstrating understanding and a proactive approach. Another common phrase is “Consider decoupling this” – suggesting a change that refactors components for better modularity, often driven by concerns around maintainability or scalability.

Furthermore, clear communication in Slack channels surrounding PR descriptions is crucial. A simple “Fixed bug” isn’t enough to justify a pull request. Instead, you’d want something like: “PR #1234 - Resolved an intermittent issue with user authentication due to race conditions during token refresh. Added comprehensive unit tests and updated the documentation accordingly. This change aligns with the service architecture outlined in the latest design document.” Again, detail is key – outlining the problem, the solution, testing procedures, and any related documentation updates. It’s about providing enough context for reviewers to quickly assess the impact of your changes.

# Example: Monitoring a Pub/Sub Topic using gcloud (Google Cloud SDK)
gcloud pubsub topics describe my-topic --project my-project

This command, when used in a Slack message or PR description, demonstrates familiarity with Google’s cloud infrastructure and the tools used to manage it. It’s a small example, but highlighting these technical skills through precise language builds confidence and facilitates smoother collaboration within the Encore.ts development team.