-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
any plans for supporting serverless support ? #258
Comments
The plans totally depend on users (and a bit on my enthusiasm for implementing specific things), so since you want to have it, it definitely won't be quick to support this, but I'll look into it and will try to do what's possible. The warning on your screenshot says "enable the "nodejs_compat" compatibility flag", add this to wrangler.toml (from docs): node_compat = true Of course, something else is going to fail then. |
I'd suggest Drizzle or Kysely for serverless because Drizzle is specially designed and optimized for serverless, and Kysely is lightweight by nature (not an ORM). For serveless, and for edge computing especially, it's important to use lightweight libraries, or even writing raw SQL, because it's very limited by memory and response ms. I expect this to take a lot of time to optimize OrchidORM bundle sizes, to make it more modular and to allow loading only those modules that you need. For example, there is a module for full text search, you probably don't need it, and for serverless it's important to load only what you're going to use. So, definitely, this isn't planned for the near future, I'd say that progress on this can be expected by the end of this year at best. |
I believe the very distant Version Next future should be using function composition instead of inheritance and chaining. Besides becoming tree-shakeable and better fit for serverless, it will supposedly solve more architectural problems, such as: |
// chaining
db.user.select(...).where(...).order(...).limit(...).offset(...)
// function composition
offset(limit(order(where(select(db.user, ...), ...), ...), ...), ...) There is a different and pretty popular way of single object param containing the whole query options: db.user({
select: ...,
where: ...,
order: ...,
limit: ...,
offset: ...,
}) But this object way also fails the purpose of tree-shakeability. Function composition in this case fails the purpose of a query builder: it should be more convenient to write and read than a raw SQL, not less. I'm not very familiar with serverless and may be getting it wrong, and as I know, they aren't meant for heavy apps, but for small lightweight ones, where you better off with raw SQL or something lightweight. And Drizzle already seems to cover well this niche. So to me, serverless support is of lowest priority, if someone's ready to contribute it - cool, but otherwise I think it's absolutely fine to not care much about bundle size yet and to focus on adding features, despite the fact that ORM gets heavier and heavier. |
It doesn't have to be that ugly, there is the pipe composition pattern: // still easy to write and read
const users = await query(db.user, select(...), where(...), order(...), limit(...), fullTextSearch(...)) I realize this is only theory, and it could be that Typescript doesn't have enough flexibility for the same strong typing as one can achieve with chaining. Also, it doesn't have to be fully decomposed; but even some parts may benefit. Such as that defining a table will not pull As for serverless, the key points in my (relatively small) experience were:
Ideally, a serverless app should be bundled into a single JS file that doesn't depend on anything other than Node runtime. Other than that, it doesn't have to be really small and lightweight. I do have a mid-size Knex/Objection web app running in AWS lambda without problems (it required building a custom Lambda Layer due to binary packages though). The non-minified bundle is around 4MB JS code, plus externally provided |
Your code example with a pipe way looks nice, but.
query(
db.user,
select({ profile: q => q.profile }), // selected profile
order('profile.name') // ordered by profile name
) Here the select changes query type to let TS know that you selected profile, and then It means that the query type should be passed in and out into every method, and it's possible with the current way of chaining, but I'm sure it's not possible in a case of such pipe way, because here So if query methods weren't dependant on each other than sure, but they are in various cases. Anyway, serverless isn't among my priorities. Currently the priority is to cope with new issues, later it will be to redesign some things to make DX better, and after that to add new cool and useful features. And it's even good to not support serverless, as it limits the surface for bugs. |
Let's accept that the serverless support isn't planned. Either the ORM will survive, gradually grow and improve only for postgres and "serverful" apps, or serverless won't help but consume. |
i am trying to deploy my backend API with orchid to cloudflare workers, but i am getting some error, because of some library,
are there any plans for providing serverless support?
if yes, would like to contribute!
error:
The text was updated successfully, but these errors were encountered: