2 Matching Annotations
- Apr 2025
-
-
Why not a library? We've found it extremely hard to develop a library that: Supports the many database libraries, ORMs, frameworks, runtimes, and deployment options available in the ecosystem. Provides enough flexibility for the majority of use cases. Does not add significant complexity to projects.
-
- Mar 2025
-
github.com github.com
-
The goal of Lucia v3 was to be the easiest and cleanest way to implement database-backed sessions in your projects. It didn't have to be a library. I just assumed that a library will be the answer. But I ultimately came to conclusion that my assumption was wrong. I don't see this change as me abandoning the project. In fact, I think it's a step forward. If implementing sessions wasn't easy, I wouldn't be deprecating the package. But why wouldn't a library be the answer? It seems like a such an obvious answer. One word - database. I talked about how database adapters were a significant complexity tax to the library. I think a lot of people interpreted that as maintenance burden on myself. That's not wrong, but the bigger issue is how the adapters limit the API. Adapters always felt like a black box to me as both an end user and a maintainer. It's very hard to design something clean around it and makes everything clunky and fragile, especially when you need to deal with TypeScript shenanigans.
Tags
- creating/using library vs. copying code
- when not to create a library: too hard to support/maintain the many ways it would need to be flexible
- when not to create a library
- too easy/simple/trivial for end-developers to write from scratch to expect (don't need library to do it for them; don't need to provide feature)
Annotators
URL
-