Thor VS Nest

Ruby has always been a great general-purpose scripting language and is often used to create command-line utilities. Many of these use the excellent Thor gem to parse command-line options, but there's no escaping one fact: command-line utilities just aren't interesting. Never have been, never will be.

All public methods in the generator will be called one after the other. Private methods will not be called but are available in your public methods like regular Ruby classes.

ruby: http://whatisthor.com

I will add that if you want to develop a CLI tool that gives you various commands that you can run, I would have a look at something like thor to keep it organised and documented. But this is completely unnecessary as a first step - you can simply create a Ruby file that does a thing you want and invoke it directly.

Not to be confused with generator functions (which you might be familiar with from Python or Javascript), Rails generators are custom Thor commands that focus on, well, generating things.

I wanted to provide a command-line interface for the user that was easy to use, and I also wanted to provide the flexibility with the options used to render the animation. After looking around online I found that Thor was a good tool to utilize. It allowed me to easily create a number of options that make this program much more versatile. An example below shows how a user can select which folder the source images are in, as well as what the background and foreground colors should be:

I've used Thor a lot, but it's kind of terrible. It uses a custom non-POSIX-compliant option parser (ex: method_option :list, type: :array -> --list one two three, where as the POSIX way is --list one,two,three or --item one -- item two --item three) and will not error on unknown options or exit with -1 when not enough args are given. If you want a better CLI library, checkout dry-rb, command_kit, or cmdparse.

And Thor might be worth looking at if you have complex scripts: https://github.com/erikhuda/thor

When using the NestJS framework, sometimes you may need to change some default timeout. You can define them just like you'd do in a plain Node.js HTTP server like so:

Back: a graphQL server built with Nestjs

NestJS - opinionated more scalable, but harder to learn docs

Pragmatically, we can apply this to a Nest application by creating an Interface for our services, separating the Presenter layer (Controller) from the Use Case (Services):

It’s a text document that contains all the commands a user could call to assemble an image. Let’s check an example of a Dockerfile for a nodejs app in this case it will be a NestJS app and then explain each part.

describe('Create bookmarks', () => { const dto: CreateBookmarkDto = { title: 'NestJS', link: 'https://nestjs.com/', }; it('should create bookmark', () => { return pactum .spec() .post('/bookmarks') .withHeaders({ Authorization: 'Bearer $S{userAt}', }) .withBody(dto) .expectStatus(201) .stores('bookmarkId', 'id')//store the bookmark id in the variable bookmarkId .expectBodyContains(dto.title) .expectBodyContains(dto.link) }); });

In my usual NodeJS tech stack, which includes GraphQL, NestJS, SQL (predominantly PostgreSQL with MikroORM), I encountered these limitations. To overcome them, I've developed a new stack utilizing Rust, which still offers some ease of development:

The purpose of this article is to provide a step-by-step guide for implementing authentication system in a NestJS project using the Passport middleware module.

That's exactly where I am. My manager gave me these links, that cover a lot of those words the backend uses, so I can identify what they mean and how to use them. 1. For inspiration and concepts: https://github.com/Sairyss/domain-driven-hexagon 2. Suggested to read the documentation for nest.js. They apply such concepts I don't understand: https://nestjs.com/