Skip to content
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

Closed
KMJ-007 opened this issue Apr 26, 2024 · 7 comments
Closed

any plans for supporting serverless support ? #258

KMJ-007 opened this issue Apr 26, 2024 · 7 comments
Labels
wontfix This will not be worked on

Comments

@KMJ-007
Copy link

KMJ-007 commented Apr 26, 2024

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:

image
@romeerez
Copy link
Owner

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.

@romeerez
Copy link
Owner

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.

@IlyaSemenov
Copy link
Contributor

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:

@romeerez
Copy link
Owner

// 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.

@IlyaSemenov
Copy link
Contributor

offset(limit(order(where(select(db.user, ...), ...), ...), ...), ...)

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 pg; or defining column types won't be needing an ad-hoc table definition callback.

As for serverless, the key points in my (relatively small) experience were:

  • avoid binary packages
  • avoid "non-standard" packages that e.g. try to read their own source code with file system API
  • reduce startup time (i.e. avoid module-level code)
  • simplify pg pool management (on demand connect and fast release)

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 pg-native and pg-query-stream.

@romeerez
Copy link
Owner

Your code example with a pipe way looks nice, but.

Typescript doesn't have enough flexibility

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 order can use it.

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 order doesn't clearly depend on select and cannot access its return type.

So if query methods weren't dependant on each other than sure, but they are in various cases. select depends on join and with applied prior to it, create and update depend on select and on where, etc.

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.

@romeerez romeerez added the wontfix This will not be worked on label Aug 17, 2024
@romeerez
Copy link
Owner

romeerez commented Aug 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants