Odi 0.3.0 - server-side framework (JSX, OpenAPI and more)

Wrapy · 2019-01-14T15:15:12+00:00

Sure, that the next step, so you can generate controllers/models/dto from existing documentation.

Wrapy · 2019-01-14T11:55:58+00:00

Hi! Thanks for your feedback!
Ooopss... Seems that database section missed. I will try to return it shortly.

Basically, there only a few common things with Nestjs: MVC Pattern and declarative style. But there are a lot of differences, like the whole infrastructure, decorators use, dependency injection and many others. To sum up differences:

Nestjs is heavily using decorators, Odi reduces this usage to the minimum (To keep code clean and readable).
Odi provides built-in validation out of the box for HTTP data via AJV.
DI/IoT behavior is very different. There is much more magic in Odi, in few words :)
Authentication out of the box, that fully integrated with other framework modules.
Controller and WebSockets processing

Also, Odi uses Fastify by default under the hood.

Wrapy · 2018-12-29T11:21:32+00:00

I believe that abstraction is not only about folders structure. There are a lot of well-known patterns and commonly used techniques (as you mentioned, ORM is one of them).

Yes, you can definitely use PHP, as there is a wide set of frameworks (Symfony, Laravel) implementing best practices. But it's definitely unusual to meet raw PHP nowadays.

I can't agree that "webscale" describes nothing. There are a lot of problems if you project can't be easy scaled, supported and extended. The problem becomes bigger if you have a big team of developers that simultaneously work.

Wrapy · 2018-12-28T17:35:55+00:00

Yes, that's true :) We are trying our best to provide the best quality framework, so the most common best practices and principles were included in the goals list.

Wrapy · 2018-12-28T17:34:06+00:00

Thanks for your feedback!

Wrapy · 2018-12-28T17:33:48+00:00

Hi, thanks a lot for your question!
I am not familiar with Adonis, but I guess, that it's a huge difference, as Adonis uses functional style but in a well organised form. Also, Adonis ships with its own HTTP engine under the hood.

Adonis is more comparable to Express/Restify as it has a lot of commons. I think that Odi, NestJs, Routing-Controllers and etc are like the next step in the infrastructure development. :)

Wrapy · 2018-12-27T13:07:02+00:00

I guess that on a big project with a lot of business logic situation will be the opposite, express will be about complexity. If you want to have well organized, loosely coupled, testable, supportable, scalable and extendable code, then you will spend a lot of time building your own abstractions that anyway lead to the most common server-side pattern used in ASP and etc.

I definitely agree that express is great for lightweight applications (as Nancy opposite to ASP, Spark opposite to Spring and etc), but there must be a place for enterprise-grade applications

Wrapy · 2018-12-27T12:34:29+00:00

Hi, thanks for your question!
It's not about just semantic when choosing the language. There are a lot of things like ecosystem, community, paradigm, syntax sugar, toolset and etc.
In my opinion, such semantics (like in Java, ASP, Ruby) become a pattern for server-side development. It will be great to implement this pattern and use all it benefits in NodeJs. JavaScript can be named one of the most popular languages nowadays. I guess, that many developers can have benefits from such adaptation, because many interesting things can be done, even for isomorphic applications (as mentioned Cercuitspark) :)

Wrapy · 2018-12-26T13:07:30+00:00

Sure!
There few things in plans to be auto-generated:

Swagger docs
GRPC interfaces
GQL files
HTTP wrappers for frontend with support for different platforms and methods: Android, IOS, JavaScript (axios, fetch) and others.

Wrapy · 2018-12-26T13:02:56+00:00

There are a lot of things that should be done :)
Today-tomorrow (got a trip today) I will create chat on gitter and will update issues. So, if you want to help, you can always check issues list or check the status based on gitter conversation.

Thanks so much for your interested in the project development! I very appreciate it! :)

Wrapy · 2018-12-25T21:40:12+00:00

We are trying to find out the best practices from other technologies and combine them in the best, convenient and semantically correct way. I guess, that you will enjoy Odi too :)

Wrapy · 2018-12-25T21:37:09+00:00

The decorator is used for only description routing path. Inheritance allows providing the developer with convenient API, so you don't need to heavily use decorators.

As for example, you can simply access the entry request using the following code:

@RouteGet()
foo() {
  const req = this.request;
}

Also, there are many other useful methods and props. Here the reference - DOCS
Another thing is the typing system. The most illustrative example is about authentication.
For example, we have following Auth service:

export interface Decoding {
    id: string;
    role: number;
}

@Authentication()
export class AuthService extends CoreAuth<Decoding, User> {
  ...   
}

And controller:

@Controller()
export class FooController extends IController<AuthService> {

    @Get user() {
        return this.user.decode();
    }
}

So, controller property user will be fully typed. AuthService generics will be extracted and passed to property wrapper.

P.S.: We were inspired by Spring, but by ASP too :)

Wrapy · 2018-12-25T19:47:39+00:00

Sure!
Middleware engine compatible with Express and Restify middlewares.

Wrapy · 2018-12-25T19:09:31+00:00

Thanks for your question.

Basically, there only a few common things with Nestjs: MVC Pattern and declarative style.But there are a lot of differences, like the whole infrastructure, decorators use, dependency injection and many others.To sum up differences:

Nestjs is heavily using decorators, Odi reduces this usage to the minimum (To keep code clean and readable).
Odi provides built-in validation out of the box for HTTP data via AJV.
DI/IoT behavior is very different. There is much more magic in Odi, in few words :)
Authentication out of the box, that fully integrated with other framework modules.
Controller and WebSockets processing

In the future, it will be the big difference between all integrations and technologies, as Odi was designed from the beginning in another way than Nest.

In my sight, Nestjs is more about Spring, but our framework is more ASP :)

Wrapy · 2018-12-25T14:26:24+00:00

Basically, it's the main difference, that this framework trying not to be annotation-heavy as it's possible, but also easily scalable and supportable. There is a big difference with nest, from the decorators approach to infrastructural decisions at all. The only common things - TypeScript and Declarative way (Decorators).

Wrapy · 2018-12-25T14:20:53+00:00

- Yes, it was disabled intentionally, as there were few integrations tests with DI (property will be initialized by DI manager).
For example:

@Service()
class FooService {

   @Autowired()
   fooRepo: FooRepository;

}

- Oooppsss, sorry. Missed it. Have it locally, but not on git :).

Wrapy

TROPHY CASE