denofn / denofn-selfhosted Goto Github PK

Might be best to use CRA / nodejs for development for this. Serving will still happen in Deno land.

• use Auth0 to lock behind one user
• start with only allowing to upload an index.ts (or inline text editor? like webtask?)
• set/update registry config in app
• registry API functions written in registry, exported in mod.ts, imported as endpoints in execution
• serve in execution
• disallow reserved filenames
• serve static

At least the following names should be reserved for usage within Execution:

• api
• static

• start with adding snapshots for style consistency
• add workflow for UI tests

• Investigate whether we're using Opine/Opine HTTP Proxy correctly
• Either contribute to the project or abandon for custom implementation (preferably we want to contribute)

Move crappy built-in logging to std's logger, would be nice to still have [Registry] and [Execution] prefixes but it's a nice to have.

Ditch the crap formatting, it looks fine in Papertrail

Prerequisites

• create route at /helloWorld

Expectations

1. navigate to /helloWorld [this should work]
2. navigate to /helloWorld?vcokjabfasdl [this should work]
3. navigate to /helloWorldvcokjabfasdl [this should NOT work]

Reality

1. this works
2. this works
3. this works

Description

Routing should be more strict in resolving URLS

Not sure if this is applicable to templates, but since micro is highly likely to be subject to change, it's more interesting to create a shim instead of having to copy the new module after every change.

prettier and code editors shouldn't be loaded in immediately, and neither should the same resource be loaded in every time.
Thus the solution is two fold:

• add a caching strategy with the CRA added service worker (also provide a pop-up to update!)
• use dynamic imports on hungry dependencies like prettier, react code editor, react selectable

Add a Readme for packages/micro and improve documentation

• Also allow delete option in Registry UI

Visibility of functions will still be ALL, but more people can manage the functions.
Make usr a csv store and add endpoint in API / mgmt in UI

Might be best to cherrypick implementations of routers and gradually introduce them to the application.
#23 has shown that small - but breaking - changes can halt the process incredibly (instead of patching things myself I'm now dependent on others) and this might not break something that quick but it's still nice to safely reside on the current version of Deno.

Something like lerna version but for Deno would be nice. But I see it the following way:

• register files that indicate denoFn versions (execution/deps.ts, registry/deps.ts, templates/bundle.ts)

• bump these files
  no longer needing, not pinning to a specific CDN anymore.

• simple git wrapper that commits release version + tag and pushes all to origin no that much work to do manually for now. Skipping

Pretty sure this will scale better once moving to a swarm or load balanced instances.

• check incoming request that's not api/static and check if it's a registered script
• if not, decline request or pass through (on static files you want to pass through)
• if it is, enter scriptHandler

References to jeroenptrs/denoFn should become denofn/denofn-selfhosted

https://deno.land/manual/runtime/compiler_apis#denobundle

These files need testing:

Execution

• handleProxy.ts obsolete with new library
• index.ts split attachHandlers in separate file to make testable, the rest doesn't need any tests
• registerScriptHandler.ts (do this in #20)
• spawn.ts

Registry

• index.ts split checkRegistry into sizable chunks [done in #12]

Micro

• the whole library :)

Shared

• none

Registry UI

• test API with something like superagent

Edit registry and execution dockerfiles to pull deno-alpine from github registry

It's a mess right now, I'm already adding several todo's as issues instead of in the Readme.
I prefer keeping it as .md files in a docs folder, but I'm partial to something like Docusaurus as well.