Laravel Orion: Build API With A Few Lines of Code

This is a quick review of a package, with also a discussion on other code generators.

Links mentioned in this video:

- - - - -
Support the channel by checking out our products:

[LaravelDaily]

Posting this on behalf of Aleksei, the author of Orion, his comment was somehow blocked by Youtube.

Hi, Laravel Orion creator here. Thank you for the review!
The idea behind the package lies in a different approach to API development and its architecture (this is crucial). Back in 2017 I saw a tweet from either Jeffrey Way or Adam Wathan that said something like this:

"When you create an API to manage subscriptions, instead of creating a "subscribe" POST route, try creating "subscriptions" POST route instead - it neatly maps onto REST and HTTP, because what you essentially do when subscribing a user is creating a Subscription entity. Instead of "cancel-subscription" DELETE route, just use "subscriptions/{id}" DELETE route instead .

This tweet inspired me to work on Orion, because after a few years of working on APIs (ranging from e-commerce to CRMs), you inevitably start to notice common patterns across even drastically different projects.

Yes, there always will be cases when you cannot get away with simple CRUD and either usage of the hooks feature or custom endpoints would be required - that is perfectly normal. It is not intended to have all the features you might need - that is practically impossible. Orion is meant to accompany your API development - not restrict it.

But think about this for a moment - how many times have you (a developer) written a code to store a model? to validate a request? what about unit and integrations tests? (I hope you do write them) oh, your PM asked to write OpenAPI specs for all endpoints? Now scale that to the factor of domain entities of your project times 5 (roughly the number of endpoints typically needed for an API resource).

If you think about it, creating a maintainable and robust easy-to-use API is not a simple and quick task. If you think that repeating the steps above over and over is fine just to avoid that extra package dependency is not time-consuming and is more maintainable in long-term with a growing team of developers, then sorry to break it down for you, but you completely lack the time and complexity estimation capabilities. Sure, you can write all that yourself, but then you would need to use it in another project (unless your software engineer career does not consist of one project for a lifetime) - congratulations, you just invented a package yourself.

Learning curve - yes, it is there, and it will be anytime you learn something. I have tried to architecture Orion in a way that it sits as a thin layer on top of Laravel and the learning curve is not steep - getting started requires basically 5 minutes of browsing through the documentation, and most of the features faced towards developers do not introduce new concepts that are unknown to them - you would still use controllers, models, requests, policies - there are no new things like action or some new entity classes.

Also, Laravel Orion is not meant to be used solely for the purpose of admin/CRM/CRUD-only apps - please think about the concept from the tweet mentioned above. We successfully use it for both internal (CRM-like) and client-facing applications, and having integration tests for common endpoints that Orion provides saves us a ton of time (and, well, you basically get less bugs, because the logic is tested on package level).

As for the code generation packages, the main reason I'm not a fan of it is maintainability of already generated code. Imagine you generated a controller, then you made changes to the generated code, and now a package used to generate the controller has released a new version with new features for one of the endpoints - what will you do? I'm sure that no matter how advanced that package is, deciding what to update or to delete is something that only a developer can do (with all the knowledge of the domain, since there are changes specific to that).

[adityakadam]

In my experience, packages are good for simple cases where the deeper level of customisation is not required. But to be honest, when it comes something like developing an api, generators do not solve the problem. I would rather prefer to use Sanctum/Passport only and create my own api rather than using generators.

[alexaverkiyev]

From my experience, very low amount of these packages would fit me personally.
The problem is the time you need to understand how that particular package work. And another problem rises the moment you need some extra features which that package doesn't have.
So basically you have 2 options: either you create everything by yourself, or you fork the package and start maintaining your own branch. To me the first option is much better.
Less packages = less headache. Stick with that rule

[debjit]

Adding any package not only add dependency and breaking point, but also we need more learning and onboarding time for a new dev. Using it for a test is ok, but it just takes 30 more min to create an API. I am yet to use the laravel framework generator, so can not say anything about it.

[frankincredible]

Nice demonstration, Povilas. Happy new year to you and thanks for all the great content.

[techfuture-code-tv]

Great short time review. I love blueprint. It gives 100% customization ability.

[avidian]

Blueprint is something I can get into compared to other packages mentioned in the video.

[ivan_adamovich]

Thank you for good package!
Get well!

[salimedia]

اللهم اشف أنت الشافي ، لاشفاء إلا شفاؤك شفاءا لايغادر سقما.

[Akhzar]

backpack, nova ETC could be called Laravel Admin Panel generator IMO.

[dauletsailauov]

Hello! I need some help, i have comments in event, and it is nested, how can i do this?

[erichansen]

I'm really not a fan of controlling a controller via traits. Wrapping around Route::resource() is one thing, but doing "use DisableAuthorization" instead of using middleware appropriately feels like it adds more complexity, and even deeper tie-in to an ecosystem that isn't officially maintained by the vendor (Laravel).

[SvilenStoyanov]

@Laravel Daily can you make a podcast comparison Orion and Lumen and what are differences between both. Pros and Cons. Think that this will be very helpful for most of us. Thanks in advance and Happy Holidays to all.

[devsbuddy]

I am currently working on an open source project of mine in which Laravel developer can generate native crud and api crud and also if they wants to customise it they will be able to customise it by changing generated code.

[bagussonarangga]

How about performance? when handle more than -+ 100user request in a minute?

[tatendawilson]

the general purpose for packages is to less work for a developer, if a package took most of your time then the package is not saving the purpose. i used quick admin, was great experience easy to learn, pure laravel. im stuck with Blueprint

[GamePlayByFaks]

I think the big complexity that introduces the likes of Orion is the worst one (high cost of knowledge and maintenance), I would rather prefer a simple approach like a blueprint.

[CodrMax]

is there a way to protect your api link when it is used with axios from internet scrappers? and allow the request only if it is made inside your server?

[SalomDunyoIT]

I like native one. but the on-top developed ones can be a little faster in terms of development.

[relliv]

Code generators is not cover all problems but I think it is ok building or starting quickly the projects. Also I will start developing low code platform this year. I beleive the low code is part of future because we are repeating same things and generators can help us for doing same job more quickly.