Avram Optional?

[mdwagner]

Intro
Has there been any thought to making Avram optional? Currently, on the version of Lucky I'm running, I need to have Avram loaded and have a database url in order for the app to compile.

Some background
We're making an app where we use all the features of Lucky, except Avram, because the way we query/manipulate data is through other means. We started out with Kemal, but wanted some more structure, and so we chose Lucky (which is awesome!). But we just dont need anything to do with using the Avram ORM.

If this question is against some of the goals of Lucky, like whether Lucky should be a complete framework full-stop or if you can chose which parts you want to use and move on, then maybe some suggestions to use instead would be helpful?

-thanks

[jwoertink]

Avram itself technically can be removed, however, things get a little funky. Now, with that said, you don't have to have a database. Case in point the Lucky website which doesn't use a database. Also check out the bottom of this page for more information.

The DB connection happens at query time, and not compile time, so if you never attempt to make a query, then it won't affect anything. This also allows you to use Avram::Operation which can be good for running data mutation stuff that might not be backed by a database.

[mdwagner]

Darn, I must of missed that on the website lol. Funnily enough, I was already doing exactly what the Lucky website does.
Thanks, I'll close this issue.

[jwoertink]

No worries. There's a ton of info on the site, and it could probably be organized a bit better. Also feel free to hop in the gitter chat.

[jubishop]

I think it would be good to disentangle the strong dependency between these two. My guess is @mdwagner isn't the only person out there that is probably looking at Lucky and thinking: "well that's too much for me because i don't want an ORM". This opinion is expressed in this blog article too (in the comments) https://dev.to/yujiri8/frustrations-with-crystal-orms-1hk2 .

There is a reasonable concern that breaking them up fully will lead to less elegance in the full implementation but I think with the right interface design and testing we should be able to keep it just as pretty when they're used together (we shouldn't do it if we can't), and I think reflecting on exactly how they interface and what that looks like will just lead to better design decisions anyway...just my 0.02c