The base application is working and can be started.
Is Jet ready for non-development use? No, many things are missing, but progress is happening with a steady pace.
Download Jet and take care of dependencies:
git clone https://github.com/jetcommerce/jet
crystal deps build amber
crystal deps build micrate
Jet uses two database users - admin user for management functions and password verification, and app user for runtime access to tables.
createuser -dlPrS jet_admin(run this as user "postgres")
config/environments/development_admin.ymlunder "database_url" (the default is user "jet_admin", password "jet_admin")
createuser -DlPRS jet_www(run this as user "postgres")
config/environments/development.ymlunder "database_url" (the default is user "jet_www", password "jet_www")
Create database, run all migrations:
AMBER_ENV=development_admin ./bin/amber db create
AMBER_ENV=development_admin ./bin/amber db migrate
Load seeds and samples:
AMBER_ENV=development_admin crystal db/seeds.cr(you could also run
AMBER_ENV=development_admin ./bin/amber db seed, but it won't print any debug output and so will appear as taking a long time to complete)
AMBER_ENV=development_admin crystal db/samples.cr
After the above has been executed without errors, please run:
Here follow various additional usage / design notes so that developers and users can get a quick sense of the application:
Everything related to Amber is already grouped under the module
Everything related to Jet is grouped under the module
Things that Jet needs to initialize only once (things like logger, embedded file system, precompiled template cache, and everything else that is constant and doesn't get re-created for every request) are kept in uppercase-named constants directly under
Jet. Then, there are methods defined using the same name in lowercase to access them.
Typical example of e.g.
module Jet class Logger ... end LOGGER = Logger.new def self.logger LOGGER end end
Database migrations are in
db/migrations/ as expected. Database is created and migrations are run with
./bin/amber db create migrate.
"Seeds" (good data usually required for operation) is loaded using
AMBER_ENV=development_admin crystal db/seeds.cr. If you do not want to pre-seed the database with all seeds, simply edit the mentioned
seeds.cr file and remove some of the lines, or edit the actual seed files in
db/seeds/ to add or remove entries that will be loaded into the database.
"Samples" (example data which makes the shop work out of the box, but which is typically not wanted in production environment) is loaded using
AMBER_ENV=development_admin crystal db/samples.cr. The same note for adding/removing samples applies as said above for seeds.
If you would like to initialize a production database without loading seeds and/or samples in bulk, the correct approach is to simply go through files
db/samples.cr and load your own database content in the order shown there. Most probably you can go a long way by re-using the existing setup for loading the data — you just remove the seeds and samples that you do not need and add any additional ones that are needed.
There are two user accounts used by Jet:
It is envisioned that there would be a total of 3 logger-like objects in the application:
Amber.settings.logger(Amber also aliases it as Amber.logger` for convenience). This is the main logger which needs to be configured to select options, format, etc. In the logs, log lines coming from this logger are identified with name "Amber".
Jet.loggerwhich simply forwards all its calls to
Amber.logger, but automatically identifies itself as "Jet" in the logs. This is used by Jet's code.
Amber.logger, but automatically identifies itself as "App-*" in the logs. This should be used by end user / app code.
grep -rP 'TODO|XXX' config db src spec
That will produce a list of entry-level, simple TODOs for new contributors.