cloudflare / worker-template-router Goto Github PK

I noticed some weird behaviour; CloudFlare Workers returns 404, even on routes that are found.

Steps to reproduce:

1. Run wrangler generate my-worker-with-router https://github.com/cloudflare/worker-template-router (as per the official documentation)
2. Fill in your account_id
3. Run wrangler publish or wrangler dev
4. Send a CURL request to any given route that exists in the starter template, e.g. curl -I http://127.0.0.1:8787/foo
5. Notice that the responseCode is 404, even though it is found.

I have also tried to manually override the response code, to e.g. 200, but it still returns 404.

function handler(request) {
    const init = {
        headers: { 'content-type': 'application/json' },
        status: 200 // still returns a 404
    }
    const body = JSON.stringify({ some: 'json' })
    return new Response(body, init)
}

Here's a repo if you'd like to see the exact code that fails: https://github.com/simplenotezy/cloudflare-workers-returns-404

Why is this included as a dependency when it isn't used? Unless I'm missing something, the code works just fine with it not included.

Reading a little bit the Router code it seams a Router instance can be created once upon worker start and then call the Router#route method on each event

this template works beautifully with wrangler, however the publish experience could be slightly improved.

when this worker is pushed to a route, wrangler will say "go visit your worker at defined route"

however, there is no root route defined in the worker, so the user may see an empty page or something confusing.

to fix this, let's add a root route that explains the routes that the app designates!

For example something like: /users/:userId

In anticipation of cloudflare/wrangler-legacy#315

name = "router"
type = "webpack"

account_id = ""
workers_dev = true
route = ""
zone_id = ""

Certainly! So far, we've discussed the conceptual design of CodexVeritas, focusing on the Adapter pattern for creating a flexible and adaptable framework. We've also touched upon the itty-router example for Cloudflare Workers. However, we haven't created any specific code for CodexVeritas yet.

To organize the repository for CodexVeritas, you can follow this structure:

/CodexVeritas
|-- /codexveritas
|   |-- __init__.py
|   |-- storage.py
|   |-- fetch.py
|   |-- image_processing.py
|   |-- adapters
|       |-- __init__.py
|       |-- redis_adapter.py
|       |-- s3_adapter.py
|       |-- local_filesystem_adapter.py
|-- /tests
|   |-- __init__.py
|   |-- test_storage.py
|   |-- test_fetch.py
|   |-- test_image_processing.py
|-- /examples
|   |-- example_usage.py
|-- /docs
|   |-- index.md
|-- .gitignore
|-- README.md
|-- LICENSE
|-- setup.py
|-- requirements.txt

Here's a brief explanation of the folders and files:

• /codexveritas: The main package directory where the core modules and adapters will reside.
• /tests: Contains unit tests for the different modules and adapters.
• /examples: Provides example scripts showing how to use the framework.
• /docs: Holds the documentation for the framework.
• .gitignore: Specifies intentionally untracked files to ignore.
• README.md: The front page of your repository that includes an introduction and basic usage examples.
• LICENSE: The license file for your project.
• setup.py: Used for packaging and distribution of your framework.
• requirements.txt: Lists the dependencies for your framework.

As for the code, here's an example of how you might structure the storage.py module using the Adapter pattern:

# storage.py

class StorageInterface:
    """Define the interface for storage operations."""
    
    def get(self, key):
        raise NotImplementedError
    
    def set(self, key, value):
        raise NotImplementedError
    
    def delete(self, key):
        raise NotImplementedError

class LocalFilesystemAdapter(StorageInterface):
    """Local filesystem storage adapter."""
    
    def get(self, key):
        # Implementation for getting data from the local filesystem
        pass
    
    def set(self, key, value):
        # Implementation for setting data to the local filesystem
        pass
    
    def delete(self, key):
        # Implementation for deleting data from the local filesystem
        pass

This is just a starting point, and you would expand upon this with actual implementations and additional adapters as needed. If you need further assistance with coding or organizing your repository, feel free to ask!

I have tried to write TypeScript types, but I cant find any case that r.conditions are function.

if (typeof r.conditions === 'function') {
        return r.conditions(req)
      } 

That block seems unreachable.

routes array consist of [Function,Function] or [] (empty array)

return this.handle([Trace, Path(url)], handler)
return this.handle([], handler)

Would love to get some TS definitions for the router.

Hi,

As discussed on the Workers Discord, here is an issue to discuss this.
NPM recommends package-lock.json to be included in commits, for reasons discussed in this SO question: https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5

Here is the line in question:

Is serverless-cloudflare-workers still an in-use dependency in this template? It seems like it is leftover from earlier iterations.

http://workers-tooling.cf/demos/router/bar

http://workers-tooling.cf/demos/router/foo

Throws refernce error "Uncaught ReferenceError: Buffer is not defined"

right now we just say to generate- we probably want to say to generate run this command, and then to publish edit your wrangler.toml and then run wrangler publish