Description
Describe the problem
Consider the following endpoint:
// src/routes/endpoint.ts
export async function get()
{
var date = new Date()
while(new Date().getTime() - date.getTime() <= 2000)
{
// Simulate some CPU intensive task for 2 seconds.
// During this time no other requests can be made to the app,
// because JS is single threaded.
}
return { body: { status: "completed" } }
}
This endpoint is intensive on the CPU and since JavaScript is single threaded it will block the entire application for all users. Note that async only helps when the work is IO bound.
This problem could be solved with Worker Threads, which would offload the CPU intensive work to other threads and thus not block the application. However, this is not trivial to implement manually.
Issues arise from the fact that Worker Threads take a path to a JavaScript file as input and not just pure code. This is especially problematic, since one can not rely on tsc src/routes/endpoint.ts to just work, at least without some extra configuration. This extra configuration is at least partially dependent on the internals of SvelteKit and recreating it would cause an unnecessary maintenance burden on developers.
Describe the proposed solution
SvelteKit should enable developers to easily address this problem by letting specified endpoints run on separate threads.
I see two relatively convenient ways to expose this to the developers:
- Special filenames for endpoints on separate threads, for example,
endpoint.worker.tsorendpoint.threaded.ts. - Exportable variables that declare this behavior, for example:
// src/routes/endpoint.ts
export const worker = true
export const worker = { enabled: true, reuse: false }
export async function get() { ... }
Option number 2 is probably better, especially if some additional options are also configurable. For example, it may be worthwhile to specify that a certain endpoint would always reuse its worker rather than generating a new on every request.
Endpoints that are specified should then be compiled so that a separate JS file is generated for the actual code. Additionally, code for endpoints that start these workers should also be generated.
Sticking solely with Worker Threads is probably not the best way to go forward as different frameworks may have different implementations of threads. Thus, SvelteKit could potentially define an interface and then just implement the framework specific solutions in accordance to it.
Alternatives considered
- Using a framework that enables multithreading by default. This would essentially mean that one would have to use a non-JS framework. For example, PHP, C#, Java, C++, etc.
- Using a separate server for endpoints that require this behavior and implement the worker logic manually.
- Somehow implement the worker logic manually into SvelteKit endpoints, but this is not trivial nor is it pretty.
- Could perhaps be implemented as a plugin.
Importance
would make my life easier
Additional Information
No response