pksunkara

Jujutsu: Managing workspaces

2026-02-08T19:09:42+05:30

One of my favorite features in Jujutsu</a> is its native support for workspaces (similar to Git</a> worktrees). They let you have multiple working copies of the same repo, which is super handy for running tests in the background while you keep coding, or for juggling multiple features without constantly switching contexts.

While the built-in jj workspace</code> commands are great, they can be a bit verbose. I use a few simple conventions and aliases to speed things up and make my workflow smoother.

Your repository must have been initialized with Jujutsu</a> version 0.38.0</strong> or later. Older repositories will not have the necessary workspace metadata for the default</strong> workspace.1</a></sup></p>
</blockquote>

  This usually requires specifying a name and a path. I prefer a convention where my secondary workspaces are siblings of my default workspace directory, named with a suffix. Assuming your default</strong> workspace is at ~/project</code>, I prefer the new workspace named foo</code> to be at ~/project.foo</code>.</p>
#</span> Get the path of the default workspace</span></span>
repo_dir</span>=</span>$(</span>jj</span> workspace</span> root</span> -</span>-name</span> default</span>)</span></span>
#</span> Create the new workspace at the same level with a suffix</span></span>
jj</span> workspace</span> add</span> -</span>-name</span> foo</span> $</span>repo_dir</span>.foo</span></span></code></pre>
To simplify this, you can define a Jujutsu alias in ~/.config/jj/config.toml</code>:</p>
[</span>aliases</span>]</span></span>
wa</span> =</span> [</span></span>
  '</span>util</span>'</span>,</span> '</span>exec</span>'</span>,</span> '</span>--</span>'</span>,</span> '</span>bash</span>'</span>,</span> '</span>-c</span>'</span>,</span></span>
  '</span>jj workspace add --name $0 $(jj workspace root --name default).$0</span>'</span></span>
]</span></span></code></pre>
Then, you can simply run:</p>
jj</span> wa</span> foo</span></span></code></pre>
  If you have several active workspaces, it can be hard to remember their names or paths.</p>
#</span> List all workspaces to find the one you want to switch to</span></span>
jj</span> workspace</span> list</span></span>
#</span> Get the path of the workspace</span></span>
ws_dir</span>=</span>$(</span>jj</span> workspace</span> root</span> -</span>-name</span> foo</span>)</span></span>
#</span> Change directory to the workspace</span></span>
cd</span> $</span>ws_dir</span></span></code></pre>
You can combine the above with fzf</a> to interactively select a workspace from the list.</p>
To simplify this, you can define a Jujutsu alias in ~/.config/jj/config.toml</code>:</p>
[</span>aliases</span>]</span></span>
wo</span> =</span> [</span></span>
  '</span>util</span>'</span>,</span> '</span>exec</span>'</span>,</span> '</span>--</span>'</span>,</span> '</span>bash</span>'</span>,</span> '</span>-c</span>'</span>,</span></span>
  '</span>jj workspace root --name $(jj workspace list | fzf | cut -d":" -f1)</span>'</span></span>
]</span></span></code></pre>
Then, you can explore and switch workspaces with a single command:</p>
cd</span> $(</span>jj</span> wo</span>)</span></span></code></pre>
  When you're done with a workspace, jj workspace forget</code> stops tracking it in the repository. However, it leaves the files on disk. To clean up, you can combine it with rm -rf</code> to delete the workspace directory.</p>
#</span> Forget the workspace</span></span>
jj</span> workspace</span> forget</span> -</span>-name</span> foo</span></span>
#</span> Get the path of the default workspace</span></span>
repo_dir</span>=</span>$(</span>jj</span> workspace</span> root</span> -</span>-name</span> default</span>)</span></span>
#</span> Remove the workspace directory</span></span>
rm</span> -</span>rf</span> $</span>repo_dir</span>.foo</span></span></code></pre>
To simplify this, you can define a Jujutsu alias in ~/.config/jj/config.toml</code>:</p>
[</span>aliases</span>]</span></span>
wff</span> =</span> [</span></span>
  '</span>util</span>'</span>,</span> '</span>exec</span>'</span>,</span> '</span>--</span>'</span>,</span> '</span>bash</span>'</span>,</span> '</span>-c</span>'</span>,</span></span>
  '</span>jj workspace forget $0 && rm -rf $(jj workspace root --name default).$0</span>'</span></span>
]</span></span></code></pre>
Then, you can simply run:</p>
jj</span> wff</span> foo</span></span></code></pre>
  Using a simple naming convention coupled with these aliases makes workspaces feel like a natural part of my workflow, not a chore. It lets me switch tasks instantly, helping me stay focused while keeping my work organized.</p>
I've been using this approach with my jj aliases</a> for a while, and it works great!</p>

^1</sup>I am the one who contributed that to Jujutsu</a> in #6858</a></p>
</div>

Jujutsu: Keeping a file untracked

2026-01-25T17:46:03+05:30

Coming from Git</a>, I am used to a workflow where I can create a file in my repository (maybe a temporary script, or a local configuration file) and just never git add</code> it. It sits there, listed as untracked in git status</code>, invisible to my commits but available for my use. I never needed to add it to .gitignore</code> since I simply never staged it.
When I started using Jujutsu</a>, I ran into a small friction point with this habit. Jujutsu is designed to be more automatic than Git. By default, it automatically tracks all files in your working copy that aren't ignored by .gitignore</code>. This means as soon as I create that temporary file, it will be included in the next snapshot, and jj status</code> shows it as added.
This behavior is controlled by the snapshot.auto-track</code> configuration setting. You can customize this setting using file patterns</a> to exclude specific files. For example, to keep a file named foo.txt</code> untracked, you can run:
jj config set --repo snapshot.auto-track "all() & ~foo.txt" # Run the following if the file has already been snapshotted jj file untrack foo.txt</code></pre> You can still manually track it later if needed using jj file track foo.txt</code>. To untrack additional files later, you can append a new pattern to the existing configuration: jj config set --repo snapshot.auto-track "$(jj config get snapshot.auto-track) & ~bar.txt"</code></pre> If this is too much to type every time, you can define a Jujutsu alias in ~/.config/jj/config.toml</code>: [aliases] ignore = [ 'util', 'exec', '--', 'bash', '-c', 'jj config set --repo snapshot.auto-track "$(jj config get snapshot.auto-track) & ~$0" && jj file untrack $0' ]</code></pre> Then, simply run: jj ignore foo.txt jj ignore bar.txt</code></pre> I've been using this approach with my jj aliases</a> for a while, and it works great!

AI recruiters: faster, cheaper, and still clueless

2026-01-22T00:00:00+05:30

Remember the days when you'd open your inbox to find a thrilling opportunity for a Senior Java Developer role. You'd blink, look at your GitHub profile filled with Rust & JavaScript, and wonder if they even read your name, let alone your history. It was the classic "wrong stack" email. Or maybe you got the time-traveler special: a recruiter demanding 10 years of Kubernetes experience in 2018. We laughed about them, deleted them, and moved on.
Now? We've pivoted to hyper-personalized, AI-powered recruitment efficiency.1</a>
On the surface, sure, it looks different. The emails are shinier. They mention your experience at your last three jobs, reference a couple of obscure repos you pushed to years ago, and even summarize that one blog post you wrote. The tone is conversational, almost human. It feels personal.
But then you keep reading, and that familiar disconnect kicks in.
The AI might have correctly spotted that you know Rust, but it's pitching a role needing five years in some niche embedded framework you touched once for a weekend hack. Or it praises your "deep understanding of frontend architecture" because you have a few commits in a React project, only to suggest a backend-heavy position where you'll never touch the UI.
The tech has changed, but the problem hasn't. It's still spray-and-pray.
AI recruiting emails are really just "wrong stack" emails with a fresh coat of paint and better grammar. Instead of a recruiter manually (and badly) keyword-matching, we have an LLM doing "semantic matching." It's just as shallow because it still has zero clue what you actually enjoy or want to do next.
At least the old "wrong stack" emails were honest in their laziness. You knew where you stood. AI emails are trickier because they mimic genuine interest. They waste more of your time because you actually have to read a bit of them to realize they're still missing the point.
Handing this off to an LLM isn't optimizing talent acquisition.1</a> It's just automating the process of annoying us.
Real recruiting isn't a regex match. It's a relationship. You can't prompt-engineer a genuine connection. The best recruiters know that just because I can write Python doesn't mean I want to spend my next three years maintaining a legacy Django monolith. They get the vibe. They actually talk to you.
So yeah, the volume is up and the emails are politer. But until recruiters start acting like humans again, the signal is buried under a mountain of fake empathy.

^{1
Did that sound buzzworthy enough? I had an LLM generate this part for maximum engagement.
</div>}

Git experts should try Jujutsu

2025-07-03T00:00:00+01:00

I've been a Git command-line power user for a long time. For me, Git isn't just a tool for pulling and pushing code. It's a finely-tuned instrument for crafting history. I'm the person who will meticulously clean up my commit history before submitting a pull request. My toolkit is full of commands like git rebase -i</code>, git add -i</code>, git commit --fixup</code>, and git reset --hard</code>. I can reorder, squash, and reword commits in my sleep. If something goes wrong, I know how to use the reflog</code> to get myself out of any mess. I don't just use Git, I speak it fluently. I even have many many custom git aliases</a> to make my workflow faster.
So when I first heard about Jujutsu, I was skeptical. The main selling point I saw was that it was much simpler than Git. It felt like a tool designed to shield beginners from Git's sharp edges, not something for a seasoned expert like me.
I gave the tutorial</a> a quick look, but it didn't showcase any real benefits for my workflow. It confirmed my bias: this was for people who were afraid of Git's power, not for those who had already mastered it.
But the idea lingered. On a whim, I decided to install it on my work machine and used it on a complex project. That's when everything changed. I discovered that Jujutsu wasn't about avoiding history manipulation. It was about making it faster, easier, and more intuitive than I ever thought possible. It took the concepts I had mastered in Git and gave them a superior interface.
Here are a few examples of how Jujutsu streamlined tasks that were already second nature to me in Git. This is a classic scenario. You've spotted a typo or a small bug in a commit from five changes ago. In Git: You start an interactive rebase, find the commit, mark it for editing, make your changes, amend the commit, and finally, continue the rebase. # Start the interactive rebase git rebase -i HEAD~5 # And mark the commit you want to edit # Make your code changes vim lib/edit.ts # Amend the commit git add . git commit --amend # Finish the rebase git rebase --continue</code></pre> In Jujutsu: You simply tell it which change you want to edit. It checks it out, you make your changes, and you're done. Jujutsu handles the rebase automatically in the background. # Edit the change directly jj edit <change-id> # Make your code changes... vim lib/edit.ts</code></pre> There's no interactive editor, no --continue</code> step. It's direct and to the point. You've just realized you bundled two unrelated changes into a single commit. In Git: This requires another interactive rebase, mark it for editing, reset it to unstage the changes, and then carefully using git add -p</code> to rebuild the commits piece by piece. # Start the interactive rebase git rebase -i <commit>^ # And mark the commit you want to edit # Reset the commit but keep the changes in the working directory git reset HEAD^ # Interactively add the first set of changes git add -p git commit -m "First part" # Add the remaining changes git add . git commit -m "Second part" # Finish the rebase git rebase --continue</code></pre> In Jujutsu: A single command initiates an interactive diff editor, allowing you to decide what to keep in the original commit and what to move to a new one. jj split <change-id> # This creates two new commits. You can then use `jj describe` to edit the commit messages.</code></pre> This is far more intuitive and significantly faster. In Git: The standard procedure is to create a branch, commit your changes, push that branch, and then open a pull request on your hosting platform. # Create a new branch git checkout -b my-feature-branch # Make your changes vim lib/edit.ts # Stage and commit your changes git add . git commit -m "My feature" # Push the branch to the remote git push origin my-feature-branch # Create a pull request gh pr create</code></pre> In Jujutsu: You can push your current change directly to the remote, which Jujutsu will place on a new branch for you. No need to manage local branches. # Start a new change jj new -m "My feature" # Make your changes vim lib/edit.ts # Push the change to the remote jj git push --change @ # Create a pull request gh pr create --head <created-bookmark-name></code></pre> After years of honing my Git skills, I thought I had reached peak efficiency. Jujutsu proved me wrong. It's not a replacement for understanding how version control works. It's a force multiplier for those who already do. Jujutsu automates the tedious mechanics of history editing, letting you focus on the what instead of the how. If you're a Git expert who prides yourself on your ability to manipulate history, I urge you to give Jujutsu a serious try on a real project. You might just find that your favorite power tools have been upgraded. And yes, I've already started a new list of jj aliases</a> to make my workflow even faster.
3 types of coding in the AI era 2025-05-08T00:00:00+05:30 LLMs have landed, and "coding" has split. Here’s the lowdown: You've heard of it. Andrej Karpathy named it</a>, Simon Willison explained it</a>. Basically, you tell an AI what you want, it writes the code. Probably used by: Beginners & no-coders.</li> Anyone on quick or throwaway projects.</li> </ul> If a colleague reviews the code in a GitHub PR, is it still vibe-coded? I'd say no, it's moved beyond just a vibe at that point. What do you think? </blockquote> The old-school way: writing code by hand. Maybe with help from deterministic tools like LSP</a>s, linters or generators. It's you meticulously building it. Probably used by: Beginners learning the ropes.</li> Coding purists and enthusiasts who love the craft.</li> Projects needing high precision or security.</li> </ul> The sweet spot. You code, but LLMs help with autocompletions and generation via chat or local agents. You're still designing, reviewing, and debugging, but faster. Think a carpenter with a nail gun: still skilled, still in charge, just way more efficient. You're using AI as a power tool, not handing over the reins. Would this be the new "coding"? </blockquote> State of routing in Rust 2020-05-17T00:00:00+02:00 There are many micro frameworks in Rust. Some famous examples are Actix</a>, Gotham</a>, Tide</a>, Warp</a>, etc. We have seen many blog posts comparing their performances and middleware capabilities. But what we haven't seen is an article comparing their routing functionality and capabilities. I hoped to fill that gap and make this post the most up to date guide for the state of routing in Rust. NOTE: I will not be comparing Rocket</a> because it does not run on Stable yet. We have a lot of mature web frameworks like Rails</a>, Django</a>, Laravel</a>, etc.. that have been working on solving the routing problem and dealing with the typical use cases from web developers. Let us define the baseline using these frameworks and compare the Rust web micro frameworks to this baseline. Rails v6.0</code>, Django v3.0</code>, Laravel v7.6</code></li> Actix v3.0.0-alpha.2</code>, Gotham v0.5.0-rc.1</code>, Tide v0.8.1</code>, Warp v0.2.2</code></li> </ul> Let us start the comparison with trivial stuff. Simplest use case is to restrict some of the routes to only a few HTTP methods. There might be a shorthand syntax if only one HTTP method is allowed. The route should return 405 HTTP status code if the none of the allowed HTTP methods are used. match 'orgs', to: 'orgs#create', via: [:post, :put]</code></pre> path('orgs', views.orgs.create),</code></pre>@require_http_methods(["POST", "PUT"]) def create(request): pass</code></pre> <?php Route::match(['post', 'put'], 'orgs', 'OrgsController@create');</code></pre> app.service( resource("orgs") .route(post().to(orgs::create)) .route(put().to(orgs::create)) );</code></pre> Cons This does not return 405 but instead returns 404.</li> There is no shorter way to specify multiple allowed methods on the same route for the same handler.</li> </ul> app.at("orgs").post(orgs::create).put(orgs::create);</code></pre> Cons There is no shorter way to specify multiple allowed methods on the same route for the same handler.</li> </ul> path!("orgs").and(post().or(put()).unify()).and_then(orgs::create);</code></pre> route.request(vec![POST, PUT], "orgs").to(orgs::create);</code></pre> One of the first non-simplistic use case any web developer would look for is on how to use path parameters. The path params can be specified as either required or optional. They should also be able to be specified in the form of regex patterns. There might be a shorter syntax for glob (tail match) path param. # required get 'orgs/:id', to: 'orgs#show' # optional get 'repos(/:id)', to: 'repos#show' # regex get 'users/:id', to: 'users#show', id: /[a-z]+/ # optional regex get 'search(/:id)', to: 'search#show', id: /[a-z]+/ # glob get 'blob/*path', to: 'repo_blob#show' # optional glob get 'tree(/*path)', to: 'repo_tree#show' # glob in middle get 'blob/*path/commits', to: 'repo_blob#commits' # optional glob in middle get 'tree(/*path)/commits', to: 'repo_tree#commits'</code></pre> # required path('orgs/<id>', views.orgs.show), # optional re_path('^repos(/(?P<id>[^/]+))?$', views.repos.show), # regex re_path('^users/(?P<id>[a-z]+)$', views.users.show), # optional regex re_path('^search(/(?P<id>[a-z]+))?$', views.search.show), # glob re_path('^blob/(?P<path>.+)$', views.repo_blob.show), # optional glob re_path('^tree(/(?P<path>.+))?$', views.repo_tree.show), # glob in middle re_path('^blob/(?P<path>.+)/commits$', views.repo_blob.commits), # optional glob in middle re_path('^tree(/(?P<path>.+))?/commits$', views.repo_tree.commits),</code></pre> <?php # required Route::get('orgs/{id}', 'OrgsController@show'); # optional Route::get('repos/{id?}', 'ReposController@show'); # regex Route::get('users/{id}', 'UsersController@show')->where('id', '[a-z]+'); # optional regex Route::get('search/{id?}', 'SearchController@show')->where('id', '[a-z]+'); # glob Route::get('blob/{path}', 'RepoBlobController@show')->where('path', '.*'); # optional glob Route::get('tree/{path?}', 'RepoTreeController@show')->where('path', '.*'); # glob in middle Route::get('blob/{path}/commits', 'RepoBlobController@commits')->where('path', '.*'); # optional glob in middle Route::get('tree/{path?}/commits', 'RepoTreeController@commits')->where('path', '.*');</code></pre> // required app.route("orgs/{id}", get().to(orgs::show)); // optional app.route("repos", get().to(repos::show)) .route("repos/{id}", get().to(repos::show)); // regex app.route("users/{id:[a-z]+}", get().to(users::show)); // optional regex app.route("search", get().to(search::show)) .route("search/{id:[a-z]+}", get().to(search::show)); // glob app.route("blob/{path:.+}", get().to(repo_blob::show)); // optional glob app.route("tree", get().to(repo_tree::show)) .route("tree/{path:.+}", get().to(repo_tree::show)); // glob in middle app.route("blob/{path:.+}/commits", get().to(repo_blob::commits)); // optional glob in middle app.route("tree/commits", get().to(repo_tree::commits)) .route("tree/{path:.+}/commits", get().to(repo_tree::commits));</code></pre> Cons There is no shorter way to specify optionals. We could have used app.service(resource(..))</code> as mentioned in #1054</a> but app.service</code> stops matching anything else if the beginning of the URL matches the route given to it. All following routes which uses one of the specified routes here as a prefix (with or without /</code> after the prefix) doesn't work.</li> </ul> // required app.at("orgs/:id").get(orgs::show); // glob app.at("blob/*path").get(repo_blob::show); // glob in middle app.at("blob/*path/commits").get(repo_blob::commits);</code></pre> Cons MAJOR: Does not support optionals.</li> MAJOR: Does not support regex path param.</li> </ul> // required path!("orgs" / String).and(get()).and_then(orgs::show); // optional path!("repos").and(get()).and_then(|| repos::show(Default::default())); path!("repos" / String).and(get()).and_then(repos::show); // regex #[derive(Default)] struct Id(String); impl FromStr for Id { type Err = (); fn from_str(s: &str) -> Result<Id, ()> { match Regex::new("^[a-z]+$").unwrap().is_match(s) { true => Ok(Id(s.to_string())), _ => Err(()) } } } path!("users" / Id).and(get()).and_then(users::show); // optional regex path!("search").and(get()).and_then(|| search::show(Id::default())); path!("search" / Id).and(get()).and_then(search::show); // optional glob path("tree").and(tail()).and(end()).and(get()).and_then(repo_tree::show);</code></pre> Cons MINOR: Does not support required glob path param.</li> MINOR: Does not support anything after optional glob path param.</li> There is no shorter way to specify regex path params. Even though types that implement FromStr</code> are able to be used directly without the need for regex, it would be nice to have a regex filter.</li> There is not shorter way to specify optionals. They can be made a little bit shorter if not full if we implement dummy default filters for each param type. I think Warp</a> in general needs a few dummy filters.</li> </ul> // required #[derive(Deserialize, StateData, StaticResponseExtender)] struct IdExtractor { id: String, } route.get("orgs/:id").with_path_extractor::<IdExtractor>().to(orgs::show); // optional #[derive(Deserialize, StateData, StaticResponseExtender)] struct OptIdExtractor { id: Opt<String>, } route.get("repos").with_path_extractor::<OptIdExtractor>().to(repos::show); route.get("repos/:id").with_path_extractor::<OptIdExtractor>().to(repos::show); // regex route.get("users/:id:[a-z]+").with_path_extractor::<IdExtractor>().to(users::show); // optional regex route.get("search").with_path_extractor::<OptIdExtractor>().to(users::show); route.get("search/:id:[a-z]+").with_path_extractor::<OptIdExtractor>().to(users::show); // glob #[derive(Deserialize, StateData, StaticResponseExtender)] struct PathExtractor { path: Vec<String>, } route.get("blob/*").with_path_extractor::<PathExtractor>().to(repo_blob::show); // optional glob #[derive(Deserialize, StateData, StaticResponseExtender)] struct OptPathExtractor { path: Option<Vec<String>>, } route.get("tree").with_path_extractor::<OptPathExtractor>().to(repo_tree::show); route.get("tree/*").with_path_extractor::<OptPathExtractor>().to(repo_tree::show); // glob in middle route.get("blob/*/commits").with_path_extractor::<PathExtractor>().to(repo_blob::commits); // optional glob in middle route.get("tree/commits").with_path_extractor::<OptPathExtractor>().to(repo_tree::commits); route.get("tree/*/commits").with_path_extractor::<OptPathExtractor>().to(repo_tree::commits);</code></pre> Cons There is no shorter way to specify optionals.</li> The usage of path params is a little bit more verbose and is thus not easy to use.</li> </ul> As the developers start to build more features into their web app, they will be wanting to use scopes (also known as prefixes). Most common use case should be supported, a static scope where the prefix is just a string without any path params. In addition to that, scopes with params anywhere in the prefix should be supported. NOTE: I have reduced the number of code examples shown below because they can be inferred from the param examples above and the scope examples shown here. But I have manually tested all the possible scenarios related to this section. # static scope scope 'pages' do get 'about', to: 'pages#about' end # optional regex scope scope 'search(/:id)', id: /[a-z]+/ do get 'advanced', to: 'search#advanced' end # glob in middle scope scope 'blob/*path/commits' do get 'graph', to: 'repo_blob#graph' end</code></pre> // static scope app.service(scope("pages") .route("/about", get().to(pages::about)) ); // optional regex scope app.service(scope("search") .route("/advanced", get().to(search::advanced)) .service(scope("{id}") .route("/advanced", get().to(search::advanced)) ) ); // glob in middle scope app.service(scope("blob/{path:.+}/commits") .route("/graph", get().to(repo_blob::graph)) );</code></pre> Cons There is no shorter way to specify scopes with optionals needing to duplicate the routes nested inside them.</li> MINOR: Non-empty routes in scopes with globs at the end do not work.</li> </ul> // static scope app.at("pages").nest({ let mut app = tide::new(); app.at("about").get(pages::about); app }); // glob in middle scope app.at("blob/*path/commits").nest({ let mut app = tide::new(); app.at("graph").get(repo_blob::graph); app });</code></pre> Cons MAJOR: Does not support scopes with optionals.</li> MAJOR: Does not support scopes with regex path param.</li> </ul> // static scope let scope = path("pages"); scope.and(path!("about")).and(get()).and_then(pages::about); // optional regex scope let scope = path("search"); scope.and(path!("advanced")).and(get()).and_then(|| pages::about(Id::default())); scope.and(path!(Id / "advanced")).and(get()).and_then(pages::about);</code></pre> Cons MINOR: Does not support scopes with required glob path param.</li> MINOR: Does not support scopes with anything after optional glob path param.</li> There is no shorter way to specify scopes with optionals needing to duplicate the routes nested inside them.</li> </ul> // static scope route.scope("pages", |route| { route.get("about").to(pages::about); }); // optional regex scope route.scope("search", |route| { route.get("advanced").with_path_extractor::<OptIdExtractor>().to(search::advanced); }); route.scope("search/:id:[0-9]+", |route| { route.get("advanced").with_path_extractor::<OptIdExtractor>().to(search::advanced); }); // glob in middle scope route.scope("blob/*/commits", |route| { route.get("graph").with_path_extractor::<PathExtractor>().to(repo_blob::graph); });</code></pre> Cons There is no shorter way to specify scopes with optionals needing to duplicate the routes nested inside them.</li> The verbosity of defining params we saw in the above sections really starts to get in the way here. Scopes do not accept path extractors which means all the routes inside them need to define their own extractors. And if the routes themselves have params, you would need to define more custom extractors.</li> </ul> For the next use case we will be talking about is nested scopes. Most web applications would have complicated relationships between their data resources and end up using nested scopes to convey them. NOTE: We have already seen most of the relevant code for this in the above section. All the frameworks worked as expected except for the problems already described in the above sections. Now, let us talk about the final but important use case, Sibling Scopes. When there are two scopes side by side and they each have a route inside them that resolve to the same uri, the framework should resolve the ambiguity by giving priority to the routes defined in either ascending or descending order. NOTE: The code example given below might seem nonsensical but I chose it because it conveys the above mentioned ambiguity in a simpler perspective. scope 'foo/higher' do get '', to: 'photos#foo_higher' end scope 'foo' do get 'higher', to: 'photos#foo_common_higher' get 'lower', to: 'photos#foo_common_lower' end scope 'foo/lower' do get '', to: 'photos#foo_lower' end</code></pre> When /foo/higher</code> and /foo/lower</code> is called in the below scenario, Rails</a> responds with the action foo_higher</code> and foo_common_lower</code> respectively. As you can see, the routes defined at the top have higher priority. Django</a> follows the same behaviour while Laravel</a> gives priority to the routes defined at the bottom. Actix</a>, Warp</a> and Gotham</a> follow the rule by giving priority to the routes defined at the top app.at("foo/higher").nest({ let mut app = tide::new(); app.at("").get(foo::higher); app }); app.at("foo").nest({ let mut app = tide::new(); app.at("higher").get(foo::common_higher); app.at("lower").get(foo::common_lower); app }); app.at("foo/lower").nest({ let mut app = tide::new(); app.at("").get(foo::lower); app });</code></pre> Cons MINOR: It seems to always go into the scope which matches the highest number of path segments. It responds with foo::higher</code> for /foo/higher</code> and foo::lower</code> for /foo/lower</code> here.</li> </ul> Based on the comparison results above, we can rank Gotham</a> as the most mature web micro framework in Rust based on the routing capabilities. Next, we have a tie between Actix</a> and Warp</a> while Tide</a> occupies the last spot by having the most deficiencies. I initially wanted to rank Warp</a> above Actix</a> but decided not to. I have tested more complicated use cases but they all fall into one of the above compared sections. I did this comparison because I suspected some scoping issues in Actix</a>. I also got disillusioned with Gotham</a> since it looks like nobody is maintaning it anymore and I wanted to rule it out of the contention for the best web micro framework race. The results actually reaffirmed my opinion that Gotham</a> is the best out of them all and I will keep using it and contributing to it. Complex Vue.js App Structure 2017-01-25T03:23:55+05:30 I have always liked it whenever a framework provides it's own generators and/or boilerplates. It's what I liked about Ruby on Rails</a> the most after the MVC</a> concept. Developers can understand a lot about the framework and the way it's intended to be used from the official boilerplates. I am sad that the recent javascript frameworks has left this important job of generating code to the community and tools like yeoman instead of having something official. When I started looking into Vue.js</a>, I was happy to discover that they have a small generator tool called vue-cli which can be used with official boilerplates provided at vuejs-templates</a>. Unfortunately, the happiness didn't last long because the boilerplates are simple applications meant to get you started with Vue.js</a>. They don't deal with all the other necessary packages such as vuex</a>, vue-router</a>, etc.. which are needed for a complex Vue.js</a> application. (EDIT: At the time of writing this post, vue-router wasn't present in the boilerplate). They did allow the tool to use third party boilerplates which resulted in me creating spoiler</a> built upon the official webpack boilerplate. I would like to describe below about what I think should be the directory and file structure of a complex Vue.js</a> application and it's conventions. The following example assumes that you will be using webpack build config from vuejs-templates/webpack</a> boilerplate. Let's also assume that you want to have a page named Hello, it will need a vue.js</a> component named Hello and a vuex</a> module named Hello. . ├─ src │ ├─ assets # module assets (processed by webpack) │ │ └─ ... │ ├─ components │ │ └─ Hello.vue # Hello component │ │ └─ ... │ ├─ store │ │ └─ Hello.js # Hello module │ │ └─ index.js # assemble vuex store │ │ └─ ... │ ├─ router │ │ └─ index.js # app route configuration │ │ └─ ... │ ├─ App.vue # main app component │ └─ main.js # app entry file ├─ public # static assets (directly copied) │ └─ ... ├─ index.html # index.html template └─ package.json # build scripts and dependencies</code></pre> This is the main HTML template for your application. You can link your static assets inside the head tag while your processed assets will be auto injected in body. <!DOCTYPE html> <html> <head> <link rel="shortcut icon" type="image/png" href="/assets/images/favicon.png"/> </head> <body> <div id="app"></div> </body> </html></code></pre> This is the file which initiates vue-router</a> with the given components. import Vue from 'vue'; import VueRouter from 'vue-router'; import Hello from '@/components/Hello'; Vue.use(VueRouter); const routes = [ { path: '/', name: 'Hello', component: Hello }, ]; /* eslint-disable no-new */ export default new VueRouter({ routes, mode: 'history', });</code></pre> This is the file which initiates vuex</a> store with the given modules. import Vue from 'vue'; import Vuex from 'vuex'; import Hello from '@/store/Hello'; Vue.use(Vuex); /* eslint-disable no-new */ const store = new Vuex.Store({ modules: { Hello, }, }); export default store;</code></pre> This is the application's main Vue.js</a> component which is basically just a wrapper for vue-router</a>. <template> <div id="app"> <router-view></router-view> </div> </template> <script> export default {}; </script></code></pre> This is the application entry file where you initiate your Vue.js</a> application with a router, store and the main App.vue component. import Vue from 'vue'; import router from '@/router'; import store from '@/store'; import App from '@/App'; /* eslint-disable no-new */ new Vue({ el: '#app', router, store, render: h => h(App), });</code></pre> This file represents a sample vuex</a> module. export default { namespaced: true, state: { message: 'Hello Vue!', }, };</code></pre> This file represents a sample Vue.js</a> component which will be used by the vue-router</a>. Please note that Hello module's state is being used in here. <template> <div class="hello"> <h1>{{ message }}</h1> </div> </template> <script> import { mapState } from 'vuex'; export default { data() { return {}; }, computed: mapState({ message: state => state.Hello.message, }), }; </script></code></pre> When applications grow, the number of routes grow. They might contain beforeEnter hooks and so on and sometimes you might want to put all that in a separate file, or files. With a subdirectory you can keep this all in one place without bloating one router.js file. In large applications, almost everything should be as independent of each other for better maintainability and readability of the codebase. Having root actions and mutations will hamper that and thus is not recommended. I wish the official webpack template supports vue-router</a>, vuex</a>, etc.. and hopefully guide lot of developers to the correct way of using Vue.js</a>. I also wish it contains some subcommands which can be used when creating a new component or module so that the official conventions are encouraged. Cloudant: CouchDB as Backend 2016-10-01T15:25:32+02:00 There have been a lot</a> of</a> guides</a> on how to use CouchDB</a> as a database for the web while restricting users to write only the data they own. I have been recently experimenting with how to use Cloudant</a>'s CouchDB as a backend directly for one of my Single Page Applications [SPA]. This blog post gives a little perspective on the limitations of the idea and how to achieve it. The number one major limitation of CouchDB-as-a-backend is that every user can read all the data. This makes it not suitable for some kind of applications (finance etc..) but really well suited for other kinds of things. One famous example of this would be NPM</a>, Node.js package manager. The other major limitation is that there's no password recovery. You can't just say "give your email, we’ll send you a new one". Fortunately, you can bypass this by using Single sign-on</a>. I have personally decided to use Auth0</a> in my SPA. I have listed below the steps on how to achieve this Cloudant</a>. I am going to assume that you have an account ready to go with username name and password pass. Let's use the NPM</a> service as an example. You need to create an _users database which will be used for user authentication and authorization. curl -X PUT -u name:pass https://name.cloudant.com/_users</code></pre> You need to turn off Cloudant</a>'s security for this database so that you can allow anyone to register themselves as user. Create the security document which needs to be uploaded as security.json. { "couchdb_auth_only": true, "members": { "names": [], "roles": [] }, "admins": { "names": [], "roles": [] } }</code></pre> Upload it. curl -X PUT -u name:pass https://name.cloudant.com/_users/_security \ -H "Content-Type: application/json" \ -d @security.json</code></pre> You need to create a database which will be used as backend of your application. Let's create one called npm. curl -X PUT -u name:pass https://name.cloudant.com/npm</code></pre> You need to turn off Cloudant</a>'s security for this database so that you can allow all users to read and write. curl -X PUT -u name:pass https://name.cloudant.com/npm/_security \ -H "Content-Type: application/json" \ -d @security.json</code></pre> You need to add a validation function which runs whenever someone's trying to write to the application database. Create the validation function as validation.json. { "_id": "_design/_auth", "language": "javascript", "validate_doc_update": "function(newDoc, oldDoc, userCtx) {\n\n function require(beTrue, key, message) {\n var err = {};\n err[key] = message;\n\n if (!beTrue) throw(err);\n }\n\n require(userCtx.name, 'unauthorized', 'You need to login');\n\n if (oldDoc) {\n require((userCtx.roles.indexOf('_admin') != -1 || userCtx.name == oldDoc.user), 'forbidden', 'You are not allowed to update it');\n }\n}\n" }</code></pre> Upload it as a design document. curl -X POST -u name:pass https://name.cloudant.com/npm -H "Content-Type: application/json" \ -d @validation.json</code></pre> This validation function is explained below</a> You need to secure the authentication database data for users. Create the validation function as authentication.json. { "_id": "_design/_auth", "language": "javascript", "validate_doc_update": "function(newDoc, oldDoc, userCtx) {\n if (newDoc._deleted === true) {\n if (userCtx.roles.indexOf('_admin') == -1 && userCtx.name != oldDoc.name) {\n throw({forbidden: 'Only admins may delete other user docs.'});\n }\n\n return;\n }\n\n if ((oldDoc && oldDoc.type !== 'user') || newDoc.type !== 'user') {\n throw({forbidden : 'doc.type must be user'});\n }\n\n if (!newDoc.name) {\n throw({forbidden: 'doc.name is required'});\n }\n\n if (!newDoc.roles) {\n throw({forbidden: 'doc.roles must exist'});\n }\n\n if (!isArray(newDoc.roles)) {\n throw({forbidden: 'doc.roles must be an array'});\n }\n\n for (var idx = 0; idx < newDoc.roles.length; idx++) {\n if (typeof newDoc.roles[idx] !== 'string') {\n throw({forbidden: 'doc.roles can only contain strings'});\n }\n }\n\n if (newDoc._id !== ('org.couchdb.user:' + newDoc.name)) {\n throw({forbidden: 'Doc ID must be of the form org.couchdb.user:name'});\n }\n\n if (oldDoc) {\n if (oldDoc.name !== newDoc.name) {\n throw({forbidden: 'Usernames can not be changed.'});\n }\n }\n\n if (newDoc.password_sha && !newDoc.salt) {\n throw({forbidden: 'Users with password_sha must have a salt. See /_utils/script/couch.js for example code.'});\n }\n\n if (newDoc.password_scheme === \"pbkdf2\") {\n if (typeof(newDoc.iterations) !== \"number\") {\n throw({forbidden: \"iterations must be a number.\"});\n }\n\n if (typeof(newDoc.derived_key) !== \"string\") {\n throw({forbidden: \"derived_key must be a string.\"});\n }\n }\n\n if (userCtx.roles.indexOf('_admin') == -1) {\n if (oldDoc) {\n if (userCtx.name !== newDoc.name) {\n throw({forbidden: 'You may only update your own user document.'});\n }\n\n var oldRoles = oldDoc.roles.sort();\n var newRoles = newDoc.roles.sort();\n\n if (oldRoles.length !== newRoles.length) {\n throw({forbidden: 'Only _admin may edit roles'});\n }\n\n for (var i = 0; i < oldRoles.length; i++) {\n if (oldRoles[i] !== newRoles[i]) {\n throw({forbidden: 'Only _admin may edit roles'});\n }\n }\n } else if (newDoc.roles.length > 0) {\n throw({forbidden: 'Only _admin may set roles'});\n }\n }\n\n for (var i = 0; i < newDoc.roles.length; i++) {\n if (newDoc.roles[i][0] === '_') {\n throw({forbidden: 'No system roles (starting with underscore) in users db.'});\n }\n }\n\n if (newDoc.name[0] === '_') {\n throw({forbidden: 'Username may not start with underscore.'});\n }\n\n var badUserNameChars = [':'];\n\n for (var i = 0; i < badUserNameChars.length; i++) {\n if (newDoc.name.indexOf(badUserNameChars[i]) >= 0) {\n throw({forbidden: 'Character `' + badUserNameChars[i] + '` is not allowed in usernames.'});\n }\n }\n}" }</code></pre> Upload it as a design document. curl -X POST -u name:pass https://name.cloudant.com/_users -H "Content-Type: application/json" \ -d @authentication.json</code></pre> This validation function is explained below</a>. This section explains how the validation functions work. function(newDoc, oldDoc, userCtx) { function require(beTrue, key, message) { var err = {}; err[key] = message; if (!beTrue) throw(err); } // You need the user to be logged in require(userCtx.name, 'unauthorized', 'You need to login'); // If the user is updating a document, you need to make sure he owns it if (oldDoc) { require((userCtx.roles.indexOf('_admin') != -1 || userCtx.name == oldDoc.user), 'forbidden', 'You are not allowed to update it'); } }</code></pre> </a> function(newDoc, oldDoc, userCtx) { if (newDoc._deleted === true) { // Allow deletes by admins and matching users without checking the other fields if (userCtx.roles.indexOf('_admin') == -1 && userCtx.name != oldDoc.name) { throw({forbidden: 'Only admins may delete other user docs.'}); } return; } // We only allow user docs for now if ((oldDoc && oldDoc.type !== 'user') || newDoc.type !== 'user') { throw({forbidden : 'doc.type must be user'}); } if (!newDoc.name) { throw({forbidden: 'doc.name is required'}); } if (!newDoc.roles) { throw({forbidden: 'doc.roles must exist'}); } if (!isArray(newDoc.roles)) { throw({forbidden: 'doc.roles must be an array'}); } for (var idx = 0; idx < newDoc.roles.length; idx++) { if (typeof newDoc.roles[idx] !== 'string') { throw({forbidden: 'doc.roles can only contain strings'}); } } if (newDoc._id !== ('org.couchdb.user:' + newDoc.name)) { throw({forbidden: 'Doc ID must be of the form org.couchdb.user:name'}); } // Don't allow usernames to be changed if (oldDoc) { if (oldDoc.name !== newDoc.name) { throw({forbidden: 'Usernames can not be changed.'}); } } // Password logic if (newDoc.password_sha && !newDoc.salt) { throw({forbidden: 'Users with password_sha must have a salt. See /_utils/script/couch.js for example code.'}); } if (newDoc.password_scheme === "pbkdf2") { if (typeof(newDoc.iterations) !== "number") { throw({forbidden: "iterations must be a number."}); } if (typeof(newDoc.derived_key) !== "string") { throw({forbidden: "derived_key must be a string."}); } } // If user is not server admin if (userCtx.roles.indexOf('_admin') == -1) { if (oldDoc) { // Allow user to update only their documents if (userCtx.name !== newDoc.name) { throw({forbidden: 'You may only update your own user document.'}); } // Validate role updates var oldRoles = oldDoc.roles.sort(); var newRoles = newDoc.roles.sort(); if (oldRoles.length !== newRoles.length) { throw({forbidden: 'Only _admin may edit roles'}); } for (var i = 0; i < oldRoles.length; i++) { if (oldRoles[i] !== newRoles[i]) { throw({forbidden: 'Only _admin may edit roles'}); } } } else if (newDoc.roles.length > 0) { throw({forbidden: 'Only _admin may set roles'}); } } // Character validations for (var i = 0; i < newDoc.roles.length; i++) { if (newDoc.roles[i][0] === '_') { throw({forbidden: 'No system roles (starting with underscore) in users db.'}); } } if (newDoc.name[0] === '_') { throw({forbidden: 'Username may not start with underscore.'}); } var badUserNameChars = [':']; for (var i = 0; i < badUserNameChars.length; i++) { if (newDoc.name.indexOf(badUserNameChars[i]) >= 0) { throw({forbidden: 'Character `' + badUserNameChars[i] + '` is not allowed in usernames.'}); } } }</code></pre> You need to make sure that every data document you create in the application database needs to have an user field which need to be filled with the username of the user. Otherwise the validation function will keep throwing up forbidden errors. You are now ready to use CouchDB-as-a-backend on Cloudant</a>. Enjoy! About 2016-09-27T17:55:24+02:00 I am Pavan Sunkara, Founder & CEO at Jujubi</a>. I am also a core-maintainer of: clap</a>, diesel</a>, eyre</a>.