ตรรกะร่วมและเครื่องมืออรรถประโยชน์

When building applications for both Deno and Cloudflare Workers, you often encounter code that performs similar tasks. This is where shared logic comes in handy!

Shared logic refers to writing common functions or modules once and reusing them across different parts of your application, regardless of the runtime environment.

Reusing code between Deno and Worker environments offers several key benefits:

• Consistency: Ensures the same behavior and calculations everywhere.
• Maintainability: Updates to logic only need to be made in one place.
• Reduced Duplication: Avoids writing the same code multiple times, saving effort.
• Faster Development: Leverage existing functions instead of starting from scratch.

Many types of code are perfect candidates for sharing:

• Utility Functions: String formatting, date manipulation, mathematical helpers.
• Data Validation: Ensuring input data meets specific criteria.
• Business Logic: Core application rules or calculations.
• Type Definitions: TypeScript interfaces or types for consistent data structures.

The best candidates are usually pure functions that don't rely heavily on environment-specific globals.

Deno embraces standard JavaScript ES Modules (ECMAScript Modules) with a URL-based import system. This means you can import modules using relative paths (e.g., ./myModule.ts) or full URLs.

This adherence to web standards is crucial because Cloudflare Workers also primarily use ES Modules, making Deno modules naturally compatible.

Let's create a simple utility function. We'll define a function formatGreeting that takes a name and returns a personalized greeting. This function is pure and doesn't rely on any Deno or Worker-specific APIs.

Imagine this code lives in a file like sharedUtils.ts.

Here's how you would use our formatGreeting utility within a Deno application. In a real project, you'd import it from ./sharedUtils.ts, but for this runnable example, we'll include it directly.

Cloudflare Workers execute JavaScript and TypeScript at the edge. They support ES Modules, just like Deno.

This means a .ts or .js file containing shared utility functions can often be directly imported and used in your Worker code, assuming it doesn't contain Deno-specific runtime APIs.

Now, let's see our formatGreeting utility used inside a Cloudflare Worker. The Worker will respond with the formatted greeting, potentially using a name from the URL query parameters.

While many utilities can be shared directly, some logic might need to adapt to its environment.

• Environment Variables: Deno uses Deno.env.get(), Workers use the env object passed to fetch.
• File System Access: Available in Deno, not directly in Workers.
• Global Objects: Be mindful of differences in global APIs (though fetch is now widely available).

Use abstraction layers or conditional logic (e.g., if (typeof Deno !== 'undefined')) to manage these differences gracefully.

Which of the following are primary benefits of implementing shared logic between Deno and Cloudflare Worker environments?

Great job! In this lesson, we explored how to create and manage shared utility functions and business logic that can be reused across both Deno and Cloudflare Worker environments.

• We understood the benefits of code sharing, like consistency and maintainability.
• We saw how ES Modules enable seamless integration.
• We demonstrated a simple utility running in both Deno and a Cloudflare Worker.
• We discussed strategies for handling environment-specific differences.

This approach is key to building robust and efficient edge applications!