loco-rs / loco Goto Github PK

It can't hurt adding a proper html/text view generation facility into views.
right now we're doing JSON but its almost free to add server generated HTML, for those who want to build both an API and a mini website.

Each view should embed the template file,
Some provisions could be made to compile-time include the Tera templates, and then just generate them with a given information struct.

On https://github.com/loco-rs/loco/issues/new/choose there is a button to Open a Question that leads to https://github.com/loco-rs/loco/discussions which is 404 for me.

In our library, we provide support for any environment specified by the user, requiring only a configuration file with a matching environment name. In this configuration file, the user must include all the expected settings. For example, in a YAML configuration file:

logger:
  enable: true
  level: info
  format: compact
  # filters:
  #   - sea_orm_migration=error
server:
  port: 3000
  middlewares:
    limit_payload:
      enable: true
...

To simplify configuration and not breaking the app when user upgrade our crate, we propose allowing users to specify only the mandatory settings, with the option to automatically inherit the remaining configurations from our defaults. Users can then override any specific settings as needed. For instance:

database:
  uri: postgres://root:12341234@localhost:5432/rr_app
redis:
  uri: redis://127.0.0.1/

Probably wise to also ask before installing it, and explain why it is needed.

first, need to develop an approach for testing tasks,
then take a clean sample test (located in tests/tasks/) and create a gen template from it.

generating a task already works, we only need to add another test template and inject it

Publish loco-rs to https://crates.io/crates/loco-rs

after publishing the crate we need to change the Cargo.toml in our template generator to pull the crate from rust crate instead of github

lc g scaffold post title:string content:text
lc db migrate
lc db entities (syncs entities code)
lc start (does actual compilation and running)

Will generate:

• model (migration, with fields and their schema types)
• controller CRUD routes fully working (list, put, post, delete) with each Args struct input into routes
• views (based on post type) with all fields serializing

currently start of each test in tests/ contains this pragma:

// TODO: see how to dedup / extract this to app-local test utils
// not to framework, because that would require a runtime dep on insta
macro_rules! configure_insta {
    ($($expr:expr),*) => {
        let mut settings = insta::Settings::clone_current();
        settings.set_prepend_module_to_snapshot(false);
        settings.set_snapshot_suffix("auth_request");
        let _guard = settings.bind_to_scope();
    };
}

#[tokio::test]
#[serial]
async fn can_get_current_user() {
    configure_insta!();

    testing::request::<App, Migrator, _, _>(|request, ctx| async move {
...
...

we need to somehow share this macro, or create a new macro that wraps configuring insta as well as booting an app (possibly).

also, making:

#[tokio::test]
#[serial]

into our own attribute loco::test which wraps these might make sense as well.

It seems the .cargo/config.toml file is missing from the examples/stateless folder.

I cloned the repo and cd-ed into loco/examples/stateless where I tried to run

cargo loco start

I got an error:

error: no such command: `loco`

	Did you mean `doc`?

	View all installed commands with `cargo --list`

Is there some other way I would need to start it?

context: #65

what can help is create a health check (similar to the _health endpoint), that:

• fails fast
• reports what is wrong (db connection missing, or redis missing)
• provides a next step inline (shows what's configured right now in the database, and recommends what to configure or what to run, eg. command to run postgres in a docker container)
• provides a link to docs for the relevant section (not a specific thing since docs might change and break, just to the top-level section)

Checks

[ ] postgres (connection ok)
[ ] redis (connection ok)
[ ] seaorm cli (for migration) -- this is a thinker. in development, we want seaorm cli for sure. in production, it's not so certain. on one hand, we might want to run migrations on production when starting up, or when issuing an external command, but on the other hand some teams would prefer to run migrations from a "blessed" workstation connecting to production postgres. @kaplanelad WDYT?

when no config given, include our known list of what to filter in and filter out.
current configuration includes, for example, this:

2023-11-26T18:26:12.037645Z  INFO sqlx::postgres::notice: relation "seaql_migrations" already exists, skipping

which is internal (migrator probably tries always to create a tracking table)

first, need to develop an approach for testing workers (we can only test perform, no need to hook up with Redis etc),
then take a clean sample test (located in tests/workers/) and create a gen template from it.

generating a worker already works, we only need to add another test template and inject it

Move the testing.rs file under a feature called testing, which is included only when running tests.
there is lib's that needs only for tests and we shouldn't including funding the release binary

We need to establish a scheduled CI task that performs the following:

1. Executes loco new to generate a new loco app.
2. Builds the app and verifies the generator sites are functioning correctly.

Implementing this CI task will enable us to identify and address potential errors proactively, preventing any impact on our users. Refer to the example issue #85 for more details.

If I understand correctly, currently if I make a change to any file I need to stop and start again the demo server to see the effect.
If would be nice if there was a mode that was monitoring all the files (or a subset of the files) and it automatically reloaded the development server.

Enhance the booting process logging for the application by including detailed information such as server IP, relevant context, server mode, etc. This includes printing:

Loaded middlewares.
Current environment details.
Available routes.
Additional relevant information.

These improvements aim to make the bootstrap logger more visually appealing and informative.

needs to verify the router framework by testing the health endpoints

To complete the password reset/recovery flow on the SaaS site demo, follow these steps:

1. Initiate Recovery: Trigger the mailer to commence the recovery process.
2. Token Generation: The mailer will automatically generate and send a unique token to the user's email.
3. Reset Password: Retrieve the token and proceed to reset the password, allowing the user to set a new password securely."

Once it is done and merge please add the logics also in https://github.com/loco-rs/saas-starter-template

create a prelude module for all the typically imported stuff, so that users can do:

use loco::prelude::*;

Things to include: Result, Error, AppContext,, etc
Update demo, templates, to remove extra imports and clean up.

Hi everyone,

I'm a strong proponent of WIX's "nothing to deploy" philosophy which states that the first thing you do is, well - deploy!:)

I'd love to see some common ways of creating a CI/CD around loco and even deploying it manually.

We can consider giving examples for popular tier 2 providers such as digital ocean, linode, heroku and others and perhaps even providing some common steps to automate deployments for aws/azure/gcp.

(putting a small pin here for openshift/rancher)

Since deploying is basically running your binary somewhere, it could be a great article / doc entry with actual examples showing how it's mostly the same for everything.

I'd also like to discuss whether a "deploy first" approach is something we wish to adopt and thus - start every tutorial with this step.

We need to expose better the configuration documentation.

we can add the documentation directly in the development/produciton/test.yaml files.

Don't forget to add this documentations in our templates

when an error occurs and we're doing the handling bit in controller,
we need to manually capture backtrace (only in development), and add it to the trace.

no-db, remove from code
needs a different starter template

Description

When following the tutorial, running cargo loco run I'm getting the following error:

$ cargo loco run
error: no such command: `loco`

        Did you mean `doc`?

        View all installed commands with `cargo --list`
(base)

Additional information:
Project was generated with loco new
cwd = generated folder

We should contemplate exposing the sea_orm library directly from the framework, ensuring that users of our crate do not need to import the library explicitly.

for example :
In lib.rs adding the following line:

pub mod sea_orm;

and in the demo app call the sea_orm like that:

use framework::sea_orm;

this allows us to control the sea_orm and avoid version conflicts

Add contribution guidelines, including explanation about labeling and steps for getting your first PR merged into the project.

Here's an example which isn't too "official" and properly helps with contributing.

https://github.com/zellij-org/zellij/blob/main/CONTRIBUTING.md

Today we have the following templates:

1. saas
2. stateless

We can add an empty template that generates a clean website started (without controllers, task, mailers etc...)

there are 2-3 missing (simple) generators to be completed

$ cargo install rustyrails
$ rr new
> name? my-app
> choose a database:
[ ] sqlite
[x] postgres
[]
Generating your app into `my-app`...
Done! 🎉

You can now run your app with:

    cd my-app
    rr db migrate && rr start

$ rr start
Starting up your app on port ...
...
...

CTRL-C^
$ rr generate model posts
Generating a model named "posts"
... <rest of seaorm-cli output> ...

$ rr db migrate
migrating ... found new table 'posts'...
$ rr generate controller posts
Generating a new controller "posts" 
... <generates a blank controller with a 'posts/' endpoint>...
$ rr generate task foobar
$ rr generate worker foobar
...
$ rr generate test --request
$ rr generate test --model
...
$ rr generate scaffold foobar
<generates a model, controller with CRUD, model test, request tests -- all passing and green>
since we're not doing fields, generate a model with just a:
id,
pid,
title,
content

What's going on behind the scenes?

• rr (rustyrails-cli) is the central point of interface. it may/may not use cargo-generate for generating the app
• when cd my-app happens, and then rr start, this may require process exec of cargo run with suitable parameters. the user can run cargo run themselves but we want the "pit of success", to do something they always go back to rr, while power users can just do what they do with cargo, rust and so on
• generate model calls seaorm-cli, but then injects the connect points for the model
• generate controller is a homebrewed controller generation code, injects the connect points for the routes
• all generators take a positional name parameter, and the name has to be carefully normalize to Rust struct name or functioncalls (symbols)
• test generation is important, it drives the user's momentum into building an app
• scaffold generation will drive most of developers. devs will start with a scaffold and then proceed to remove stuff they don't want. which is why generation should always indicate:
  • what files were added
  • what files were injected into

Thoughts

• This divides the project into 3:
  1. CLI (generation w/cargo-generate, migration, seaorm cli, snippet codegen, injection, running main tasks). the CLI project will feel dirty. it's a glue of glues, partly shelling out to seaorm, to rustyrails own project-specific bin (via cargo run), and then partly be able to generate and inject code
  2. framework (where the runtime bits are)
  3. new project template (a running, auto-testing, live template that can be used to generate a new project)
• a person can work without the CLI or without ever installing it (meaning, no critical operational logic should be there). it also puts some more strength into having a project-specific bin and that the framework will contain all the runtime CLI stuff (e.g. cargo run start)
• a person can work without generating from a template (meaning no hidden knowledge should be there)

Refs:

• seaorm's migration generator, adhoc regex and string wrangling: https://github.com/SeaQL/sea-orm/blob/master/sea-orm-cli/src/commands/migrate.rs#L227-L244

In some cases maybe some users don't want to use the Clap as a CLI.
we can move it under a feature (which will enable by default) and let the uses decided if he want to remove it

In calp if the user adding invalid command we show the following message:

$ cargo run invalid-command
Running `target/debug/main invalid-command`
error: unrecognized subcommand 'invalid-command'

Usage: main [OPTIONS] <COMMAND>

For more information, try '--help'.

I think we need to show the available command that he can use.

it means we now have

$ rustyrails new
1. saas starter
2. stateless service (no db)
3. empty project ("ping endpoint" , no auth)

in the tour doc,
add a "Authenticating your Blog" section.

add a step-by-step coding tutorial for "connecting" the posts to a currently authenticated user.

• Add a migration to add a user_id to posts, with a relation
• Modify controller to require current user for edit, add, delete actions on posts
• list displays posts from all users
• show how to curl register, login (get token)
• show how to curl add post (with bearer token)
• show how to get all posts unauthenticated

Explain about our off the shelf authentication module

• What are the configuration points (secret)
• What routes do we and their contract have: login, register, etc.
• The user model, and its fields
• How to add authentication manually if you don't have it
• How it works (how to require a user, claims, etc)

Description

/error[E0432]: unresolved import loco_rs::hash
--> src/models/users.rs:3:11
|
3 | auth, hash,
| ^^^^ no hash in the root
|
= help: consider importing one of these items instead:
std::hash
core::hash

and mode errors

To Reproduce

cargo loco start

We can enhance the Starters project by incorporating a GitHub Action.
This addition will provide users who initiate the Starters project with a seamless CI workflow right from the beginning.

first, need to develop an approach for testing mailers

caution: there are multiple ways to do this.

(1) Rails closes a loop and captures 'deliveries', which might mean we need to create a loopback Sender, which will globally store incoming messages (we need to hook into the test lifecycle and empty it) -- to create something similar to rails.

Going uncharted territory we can:

(2) test only the mail function: input and output, and make sure to expose / refactor bits in mailer so that it becomes easy. in this technique nothing even gets to a Sender
(3) create ad-hoc REAL smtp receiver, with an interface to it (Rust has quite a few smtp mailbox simulators and smtp servers that can be embedded) and operate it

I would be in favor of (1) with great caution about global storage of messages, and in favor of (2) because it should be the solution with least moving parts.

(3) makes sense only if its dead simple, and contains little moving parts that are convincingly stable.

then take a clean sample test (located in tests/tasks/) and create a gen template from it.

generating a task already works, we only need to add another test template and inject it

We can adding a cli commands which prints all the application routes.
for example

rr controllers

[Methos] [URI]

To enhance the application logger, consider the following optimizations:

1. Include the environment information in each log entry.
2. When dealing with authenticated endpoints, incorporate the user's pid

Implementing these enhancements will result in an improved application logger.

in the form:

lc g model post title:string content:text count:int user:references

• types are simplified db types, predefined type: string, text (bigger char storage), int, datetime, uuid, bool
• take user:references, create user_id field, make it a fk on users.id

A getting started:

• generating a new project
• getting to a working API for a blog
• API will be CRUD
• show adding, listing, removing blog posts via API
• (do not demo user auth)

emphasis

• no hard concepts (no user authentication), just a blog, everyone knows a blog
• all development driven from CLI -- maximize use of generators (depends on #29 )
• if possible go for CRUD generator, otherwise provide copy-paste snippets for walking the user through POST (adding) and list all posts (listing) depends on #30 for the full thing, if possible

We need to verify that when a task is added to the background using sidekiq-rs, the message is successfully pulled, and the corresponding job is executed.

In the CLI, we generate the Cargo.toml with the following dependency:

loco-rs = { version = "*" }

Replacing the asterisk (*) with the currently running version is advisable to mitigate potential breaking changes in the master branch.

Related issue: #85

We can add another middleware which already loading the user and return the controller the user model

The authentication middleware (auth.rs) in Loco validates the token and returns the user claim, which includes the user PID. You can find the implementation here.

I only found format::text and format::json. I could not find a built-in way to send HTML pages (with the content type text/html. I figured out a way using axum that I included in this article, but I guess there is an easier way to do this.

Is there an easier way to send HTML? If not, I'd like to ask for format::html or some other way to set the content-type.

I tried to run cargo loco start command in the examples/demo folder. It started to install crates and then failed with:

    Finished dev [unoptimized + debuginfo] target(s) in 56.60s
     Running `target/debug/demo start`
Error: Connection Error: pool timed out while waiting for an open connection

Caused by:
    pool timed out while waiting for an open connection

Location:
    /home/gabor/os/loco/src/cli.rs:228:31

I guess it failed to connect to the database (as I don't have one)

Maybe the examples need a README file to explain how to run it and what does it do.

Need to examine one of these routes of action (by order, prefer (1) or (2)):

1. DB settings to immediately return error when cannot connect (don't wait)
2. DB settings to cap connection waiting attempt time at the pool
3. Middleware timeout limit

If reasonable expose the setting to power users via config