The Lucky philosophy
Lucky was designed to solve a few core problems that teams often see. Lucky strives to:
- Catch bugs at compile time, rather than finding them in production.
- Spend less time writing tests, because the compiler catches many errors for you.
- Minimize guesswork with conventions for the most common types of objects.
- Help developers break things into discrete pieces so things are easy to share and maintain in the future.
- Minimize boilerplate code so it’s easy to focus on what your app does better than everyone else.
We do that by using Crystal’s type system to the fullest. You won’t see strings or symbols passed around. Instead you’ll see method calls with types that make sure bugs are caught early.
We have conventions that help you break your app into smaller pieces that are easier to understand. Things like single class per action, and form objects.
We have helpful code generation so that you don’t need to repeat boilerplate.
Lucky was designed for developers that love making reliable products. We think you’ll love it.
File structure overview
A new Lucky app is a slightly modified version of a Crystal app.
The src folder holds most of your application code. This includes actions for handling requests, queries for database access, pages for rendering HTML, and a few other things.
Here are all the files for configuring your application. A new app comes with a few configuration files, but you can add more as you see fit.
This folder houses all the database migrations for your app.
You can put custom tasks here that can be run by the
lucky command line tool.
This folder is never written to by a developer. Instead the asset compiler will put files here automatically.
Procfile.dev is used when you run
lucky dev. By default there is a web and an assets process that are started. You can add more if you need them.
Procfile is often used in production. Companies like Heroku, use it to determine how it should run the app.
This is where classes go that handle incoming web requests.
Put anything that models your business. Database objects go here, but you could also put things like service objects.
Custom HTTP handlers. These can be used to do something for all HTTP requests. Great for things like loggers, setting up headers that apply to all requests, etc.
It’s more likely that you will use
pipes for most business logic because they can be used selectively on a per action basis.
Pipes are used to do things before or after an action is run. Great for authentication, authorization, or ensuring certain headers are set.
This is where your database queries go.
Forms for saving database records or interacting with HTTP forms.
Pages used for rendering HTML in response to web requests.
This requires all the files and folders that your app needs to run.
Require your third party dependencies (shards) here.
This file requires the app and starts an HTTP server.