lagonapp / lagon Goto Github PK

Currently, there is no way to inject environment variables with lagon dev, even if it's implemented in the Runtime. Ideally, we should add a --env option to specify a path to a .env file, which defaults to the local directory.

Now that the runtime is in Rust, we need to export the same statistics as with the Node.js runtime:

• Requests
• CPU time
• Bytes IN/OUT

Instead of storing them in Postgres, we can maybe use Prometheus to scrape an exporter from serverless. But we also need a way to display these graphs on the website.

Add a new page to create an organization and a modal to delete one (if we are the owner).

We should also be able to switch between organizations using the dropdown in the top-right corner.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. mkdir test-lagon && cd test-lagon
2. pnpm init && pnpm add @lagon/cli
3. pnpm lagon dev
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

The command can be executed successfully.

Information:

• OS: macOS
• Node.js Version: v16.15.1

It seems related to esbuild external dependencies with esm format(evanw/esbuild#1958).

lagon CLI to deploy easily from the command line.

Create a .lagon folder in each deploy with a file to save the function id.

• lagon --help
• lagon --version
• lagon login
• lagon logout
• lagon [path] / lagon deploy [path]
• lagon rm [path] / lagon remove [path]
• Auto updating

Describe the bug
https://www.serverless.com/
Been around for years. Originally seemed like it was supposed to be an agnostic abstraction, but last 2 years was gobbled up by AWS, who have better lawyers than you ;)

Add back response streaming, now that the Rust runtime has been implemented. We can look at #85 which was the streaming implementation with the Node.js runtime.

Currently, environment variables are accessible with process.env, similar to Node.js. I came across an issue today with Lyra: to check if we are running in Node.js or an Edge runtime, they check if process !== undefined and then use an API that is available only on Node.js, but not on Lagon.

Using process.env to hold environment variables might be more challenging for external libraries to know in which environment they are running. Feel free to discuss your thoughts about this below.

For reference:

• Deno Deploy uses Deno.env: https://doc.deno.land/deno/stable/~/Deno.env
• Cloudflare Workers uses global variables: https://developers.cloudflare.com/workers/platform/environment-variables/

Support .env files to inject environment variables while developing locally.

We need strong integration tests along with the existing unit tests, to make sure nothing broke when changing code.

One example of a bug that should be covered by tests is #86

Currently, the fetch API doesn't care about the input, and always performs a GET on the given URL. Now that we got it working async within the event loop, we can support every HTTP method, headers, ...

Now that the Rust runtime & CLI are working, we can add lagon dev subcommand to launch a local dev server, using the real Lagon Rust runtime.

Arguments:

• file: path to the function

Options:

• --client, -c: path to a client file to bundle
• --public, -p: path to a custom public folder
• --port: change the default port (1234)
• --host: change the default hostname (127.0.01)

in #40 @QuiiBz you refactored to trpc. we can also use trpc-swr (https://github.com/sachinraja/trpc-swr) where all useSwr was used before to get the continue getting caching benefits of useSwr.

$ pnpm run docker:start:nginx
error: nginx: [emerg] host not found in upstream "serverless" in /etc/nginx/nginx.conf:34

When an error text is too long, the worker crashes with this error:

To support more static file type in public directory, could we use mrtime to get the file's MIME type instead of extensionToContentType map.

If it's okay, I'm happy to send a pr.

We should be able to customize the API URL because we can self-host it.

@lagon/serverless already has a LAGON_ROOT_DOMAIN environment variable, but the CLI uses a hardcoded domain:

Update tRPC from v9 to v10.

Organizations:

• 3-64 chars for organization name
• 256 chars for organization description
• 20 functions/organization

Functions:

• 3-64 chars for Function name
• X active deployments/function
• 10 custom domains/function
• 100 environment variables/function
• 10MB function size
• 10MB asset size
• 100 assets/function
• 128MB function memory limit
• 50ms function CPU timeout
• 200ms function CPU startup timeout

Environment variables:

• 64 chars environment variable key length
• 5KB environment variables value size

Support HatTip router. It should already work out-of-the-box, but it's a good idea to verify and add an example.

Issue on HatTip's repo to track the progress:

• hattipjs/hattip#32

Right now, we don't handle any fetch error that might occur. In case of an error, the JS promise should reject with the error.

Now that the runtime is in Rust, we need to see again live logs from console.* calls.

To prevent malicious code from being executed inside an Isolate, we need to disable some JavaScript features:

• eval()
• new Function()
• Date.now() / any time-related API

Cron functions are currently not working. A single edge location should run a cron function, so maybe an environment variable inside @lagon/serverless can be used to do this distinction.

Add stack trace in errors logs, coming from the runtime.

Currently, we only have TextEncoder, TextDecoder (#9) and atob/btoa (#10)
We need support for all the web crypto APIs:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API

You said:

They are deployed on baremetal servers all around the world.

Curious about what provider you plan to use.

Support Remix SSR.

You can follow the roadmap using the GitHub project: https://github.com/orgs/lagonapp/projects/1

There are currently two milestones, Alpha and Beta. You can register for email updates to be emailed automatically when we release updates.

Current status:

• Dev
• Alpha
• Beta
• General Availability

I vaguely remember (I could be wrong) that CF mentioned that, because of Spectre attacks and the likes, they had to harden the V8 isolate security model. What's your take on this?

Add a lagon dev command in CLI to be able to launch a local HTTP server using @lagon/runtime.

Need support for console.*

Support HTTP/2 in Nginx config.

Deploy functions on push, similar to Vercel/Netlify in a GH Action.

Now that #102 has been merged, we can add a button to switch the locale. The default one should be en.

Following the documentation at https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder and https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder

TextEncoder needs support for:

• encoding
• encode(string)

TextDecoder needs support for:

• encoding
• encode(buffer, options)

Files in public folder (or the one specified with --public-folder) should be uploaded from the website through the CLI, then downloaded from @lagon/serverless.

Then we can have an API to read those files.

First idea, similar to Node.js fs:

• fs.readFile(file: string): Promise<string>
• fs.fileExists(file: string): Promise<boolean>

Second idea, check in @lagon/serverless if URL match an asset, and if so return it.

Is your feature request related to a problem? Please describe.

Currently, if port 1234 is occupied, an error is thrown directly, but there is no way to change the port.

Describe the solution you'd like

• There should be a way to specify the port when dev, for example lagon dev --port 8000
• Ability to automatically get available port(get-port-please)

Describe alternatives you've considered
I wonder if there will be any security and performance issues using this in a production environment?

atob / btoa functions following the documentation at https://developer.mozilla.org/en-US/docs/Web/API/atob and https://developer.mozilla.org/en-US/docs/Web/API/btoa

• atob
• btoa

Support Next.js SSR with the new Edge Runtime.

• pages directory
• app directory with React Server Components & streaming
• Integration in the CLI to bundle all the edge functions in a single one

Currently, the deployments page is kinda ugly, so we need to make it prettier.

We can also anticipate space for the git commit.

Support Astro SSR.

Now that #102 has been merged, we can convert each page step by step to next-international.

• /
• /settings
• /profile
• /cli
• /new
• /playground/:id
• /functions/:id

If so, might want to join WinterCG.

I was fairly hot on CFW ~2 years ago, but got spooked with vendor lock-in, Google tie-ins, & politically vocal engineers.

This might be a better route than Just-JS & Unikernal/MicroVM. I'm not sure if this could help my Puppeteer/Playwright project, but otherwise this looks promising.

Support Hono router. It should already work out-of-the-box, but it's a good idea to verify and add an example.

See https://github.com/honojs/hono

Update: created an issue on Hono's repo to discuss more about it: honojs/hono#734

Following the documentation at: https://developer.mozilla.org/en-US/docs/Web/API/URL

URL needs support for:

• Constructor with base
• hash
• host
• hostname
• href
• origin
• password
• pathname
• port
• protocol
• search
• searchParams (which implies URLSearchParams)
• username
• toString()

URLSearchParams needs support for:

• append(name, value)
• delete(name)
• entries()
• forEach(callback)
• get(name)
• getAll(name)
• has(name)
• keys()
• set(name, value)
• sort()
• toString()
• values()

Currently, the CLI uploads files to website, which then uploads them to S3. We can speed things up and reduce load on website by using presigned URLs.

Needs support for TransformStream, ReadableStream, WritableStream

Following the docs at https://developer.mozilla.org/en-US/docs/Web/API/Headers, also needs to update Request, Response and maybe fetch() APIs to use Headers.

Headers needs support for:

• append(name, value)
• delete(name)
• entries()
• get(name)
• has(name)
• keys()
• set(name, value)
• values()

Update from clap v3 to clap v4, which provides an easier API and changes the output of help, among others. See https://epage.github.io/blog/2022/09/clap4/