dotland
dotland copied to clipboard
feat(registry): Add on the fly compilation
fixes #1728
I'll do some performance check for this change on Deploy. deno.land/x/swc
has 5+MB wasm dependency and that would impact the performance of the start up time of the worker
Regarding the design aspect, this change responds with javascript context for the path/to/foo.ts
. That would work for the browsers, but might be confusing to the users.
Regarding the design aspect, this change responds with javascript context for the
path/to/foo.ts
. That would work for the browsers, but might be confusing to the users.
IMO as long as import { bold } from "https://deno.land/[email protected]/fmt/colors.ts"
works then it doesn't matter that much to the user. If they're in an environment where TypeScript is important (like deno) then it will do all the background magic of adding types, but in theory it shouldn't change the behavior of the code.
This seems to slow down the start up time of the isolate from about 1.5 sec to 5.0 sec from my location (my location already has 1.0 sec penalty on start up BTW).
I'm not sure how much impact it does have to the service. Can't predict for sure whether it's safe to merge this or not (should be merged very carefully anyway)
Some numbers to share: deno.land has about 66,000 reqs/hour at the peak today. It's 18.3 reqs/sec. 3.5 sec penalty means additional 64.2 reqs are on hold during deployment (if I understand the deployment process correctly). These numbers are for the entire regions, not a single region. (Deno Deploy has 25 regions, but I guess loads wouldn't be distributed evenly)
Regarding the functional aspect, I was able to use some of std/collections functions in the browser. The compilation itself seems working! 👍
An example I was able to run on a browser:
<script type="module">
import { sortBy } from "https://dry-horse-89.deno.dev/[email protected]/collections/mod.ts";
const people = [
{ name: "Anna", age: 34 },
{ name: "Kim", age: 42 },
{ name: "John", age: 23 },
];
const sortedByAge = sortBy(people, (it) => it.age);
console.log(sortedByAge);
</script>
(I deployed this branch at https://dry-horse-89.deno.dev)
I really would like this feature, is there something I can do to help?
Ideally this would not be on the fly, but rather when a tag is created
It's a part of the roadmap on the backend. So you should look in that repo first, then we can either change this PR to use that saved stripped version or make a new PR
@crowlKats Could/should this perhaps be done lazily? So we keep this pull request, but then add another which optimises it by saving the transpiled JS code to $NAME/versions/$VERSION/stripped/$FILEPATH.json
, and of course tries to serve from there before transpilation?
I tried deploying this and it looks like the isolate start time has improved to 3.10ms. Since there are no performance issues anymore, isn't it okay to merge this?
To store the lazily transpiled JS code, I think the cache layer suggested by https://github.com/denoland/deploy_feedback/issues/74 is useful.
closing because stale