Lucky 2.0 "wishlist"

[jwoertink]

I have no clue what Lucky 2.0 looks like just yet, but let's get a list going and see what happens...

[wout]

A feature I'd love to see for 2.0 is the logical separation of "apps". I first used it in Hanami (Ruby) and then in IHP (Haskell), and Marten also has it. I do it manually in my projects now, but having it as a framework feature would make it much more manageable.

[jwoertink]

I'm not familiar with this pattern, do you have any good examples of what that looks like?

[wout]

The idea is that distinctive parts of the app can be namespaced. Files are stored in their respective directories. For example:

- src
  - api
    - actions
  - web
    - actions
    - pages
    - components
    - css
    - js
  - admin
    - actions
    - pages
    - components
    - css
    - js
- components
- js
- css
- models
- queries
- operations

In such a structure, some parts are shared while others are not:

• actions/pages/components: are app-specific
• models/operations/queries: are generally project-wide, (queries and operations could be app-specific too in Lucky)
• js/css: both project-level as well as app-level

This can be made opt-in. It could be driven by a new cli task (e.g. lucky gen.app Web). That way, the project-level structure remains the same as it is now, with the app structure as an opt-in. Generating actions/pages/etc would then need to have an optional app parameter:

# without app
lucky gen.action.browser ActionName::Index
lucky gen.page ActionName::IndexPage

# with app
lucky gen.action.browser Web ActionName::Index
lucky gen.page Web ActionName::IndexPage

[robacarp]

I'd second this, so long as it's something that can grow with an app. Early on, or for smaller projects, it's a cognitive burden. Lucky already has quite a lot of required infrastructure to wrap your head around.

[wout]

Absolutely. Nothing changes by default. It's an opt-in structure but can be used without additional configuration. If you want to use it, just add the app's namespace to any of the existing CLI commands to use another target dir.

[notramo]

Marten solves this by having a default app called main, which is in the root of the src/ folder. If separation of apps are not needed, all logic goes into main (similarly how logic is written in a C program - if it's simple, it goes into main(), but if it's complex, then it's possible to put the logic into separate functions).

[watzon]

It would be cool if components could be rendered out as HTML 5 web components and loaded into the page via JS. This would be great for caching (since individual components could be cached), page load times (components could be lazy loaded), and potentially also for a Turbo type integration.

[zw963]

Consider good enough for now (compare to others web framework for Crystal which i tried), several lucky's ideas are quite advanced.

1. more detailed document(code comment)
2. refactor, i consider there are many part can be improve.
3. share, let more users(corp) know and use it.
4. performance (sure, improve crystal performance is one of important part)
5. find a way to give more accuracy error output for macro involves error.
6. create a great app use lucky!

[jwoertink]

• HTTP3 out of the box...
• background jobs in postgres
• full-text searching
• query builder
• faster compile times

[zw963]

It sounds pretty curious for background jobs in postgres.

full-text searching is good if can be support directly by lucky.

[robacarp]

postgres has some really quite effective full text search functions built in, though the query syntax is a bit obtuse at first.

[jkthorne]

• Documentation
• Improved build times

[wout]

How do you see the documentation part?

[jwoertink]

I'll be honest... I'd rather go pull weeds from my backyard than write inline docs 🤣 I know we should do it... but ugh 😩

[wout]

Ah, this is about inline docs? Not the guides?

[jwoertink]

That was my guess. We have all of the shards with autogenerated docs like https://luckyframework.github.io/avram/ but there's almost no info 😂 I do want to redesign the website though and make it easier to find docs.

[wout]

I see what you mean now 😏️. I think, if everyone who's in for it does like a file per day, it will be done faster than you think. Maybe have someone overview the changes for consistency.

As for the guides, sometimes it's hard to find things, and not everything is in there. But maybe an update to the look and feel wouldn't hurt either because it's starting to look dated now.

Those are also not really version 2 things; better sooner than later, I think. I'm down for it if we can move in chunks. All we need is a plan. 😄️

[notramo]

• Automatic migrations, much like in EdgeDB or Marten.
• GraphQL
• Socket.IO integration

[zw963]

• Automatic migrations, much like in EdgeDB or Marten.

Add Avram::Migrator::Runner.new.run_pending_migrations into your's db config.

GraphQL

There are a Crystal shard for this.

[notramo]

Add Avram::Migrator::Runner.new.run_pending_migrations into your's db config.

You clearly did not check out the linked projects.

There are a Crystal shard for this.

Is it easy to integrate into Lucky?

[zw963]

You clearly did not check out the linked projects.

Yes, you are right. anyway, i checked the document just now, it seem like a good idea to add a new genmigrations command for generate migration file automatically, though, I remain skeptical that this is really useful in a real project.
migration for production is complicated, however, migration for development is quite easy(just drop and recreate it in many cases)

Is it easy to integrate into Lucky?

Yes, in fact, almost all GraphQL client just need a very simple web server as entry, that enough.

---

EDIT: The auto-generated migrations mechanism is inspired by a similar mechanism within Django