DEV Community

tony
tony

Posted on • Edited on

2 1

Laravel on Steroids! Get 10x Speed in Your App Development

Laravel on Steroids
Source

- DB-MVCr-MPR-TA

Using some steroids (anabolic) can help athletes perform exceptionally better than other competitors. The effect could be to enhance muscle gain, endurance in training or overall performance. This post aims to achieve something related with any Laravel app developer - time gain and overall performance (but we ain't doping nor cheating).

For grand focus that leave no stones unturned, there is something close to steroid that can be adopted by a Laravel programmer and every other programmers as well. While the chemical formula for an anabolic steroid, testosterone is C19H28O2, the one for a Laravel programmer could be DB-MVCr-MPR-TA, cool huh?

The idea is to pick one model eg Post model, use the DB-MVCr-MPR-TA on it and move to the next model in line. Before long you would have covered a lot.

Let's delve straight in.

Code Related Activities Concerned Entities
DB Database activities Migration files, Model factories, Seeders
MVCr MVC and routing Model classes, Views, Controllers & routing
MPR Auth and Auth Middlewares, Policies, Request validations
TA Tests & All others Tests, APIs, App planning, Eventing, Caching...

Have you worked on a Laravel app before and got lost as to what else to work on in the current model? Am I missing anything? While planning ahead tells you exactly what features are required in your app, DB-MVCr-MPR-TA can help to lift off 60% brainstorming on what next to code in your app. That's sub-automation at it's finest. It could even help you ace that technical interview ahead of other candidates for thou shall get 10x speed and focus.

1: DB

  • Migration File
  • Model Factory
  • Database Seeder

Everything about the database such as schema file configuration (and test), faker configuration and model factory creation, database seeding (and link up to the model fillables and table column whitelisting within the model class) can be implemented in this section.


2: MVCr

  • MODEL
    • $fillables[ ]
    • eloquent relationships
  • VIEWs
    • index
    • show
    • create form
    • edit form
    • delete button
  • CONTROLLERs
    • index
    • show
    • create
    • store
    • edit
    • update
    • delete
    • other non-generic methods
  • ROUTING
    • Have all controller methods set above been routed within the app?

In this section, model fillable attributes should be set, eloquent relationship connections made and tested. On the model, subsequent methods and features will get added incrementally as the need arises.

Not all the listed views above will be needed. Relevant one can get constructed with implementation of basic frontend validations and security-in-depth features by using relevant HTML5 input types, HTML pattern attribute, Javascript validation of input fields etc.

Controllers receives the user input, optionally validates (server-side and database validations) it and then passes the input to the model. It interfaces with the router. Most of the code needed for proper functioning of the controller can be written within the model so as to keep the controller methods as lean and clean as possible. This is in line with the saying thin controller, fat model which is not a bad idea at all. This pattern allows for ease of code testing. Repository classes and traits can be used to DRY code used in both model and controller sections if some methods are repetitive across your app.

Routers are like the traffic warden of the app that can direct or redirect request and responses as appropriate. They are able to route to a closure in or to controller methods.


3: MPR

This section deals with Security, Authentication and Authorizations.

  • Middlewares
  • Policies
  • Request Validations

Laravel make these concepts quite easy, organized and are available out of the box. To implement security and various degrees of access control, the AUTH features such as Middlewares, Policies and Request validation makes sense to be under one group. More interestingly, customizing own auth classes is a cinch. Ticking relevant boxes after you have a feature implemented in your model will put your mind at rest. This helps you ensure that you have executed the right authorizations for the respective model.


4: TA

  • Tests
  • App planning
  • All others : Queue jobs, Eventing, Caching, etc...

This section should come first but to make a better acronym it is just fine here. Also, tests and app features can fit in at any point in an application. More features could be added anytime later which means all plans cannot be made at inception. In the same vein, TDD is not necessarily to be followed religiously. Some tests may not come clear initially but added later as possible later. Other non-common features such as queueing, event handling can be placed into this section. It should be a part of your app planning and so, you must find a way to track that you have implemented them as required. Examples could be inclusion of model observers while coding the CRUD part of a particular model.


This acronym and guide, DB-MVCr-MPR-TA concept helps you walk through an app development process without feeling lost. As long as you tick (or mind) the implementation of each stage, be rest assured you are making real progress. Let me know if you want a basic project detailing my workflow using this particular concept.

What do you think? I need to learn from your own coding tip in whatever language or framework, let's do this in the comments.

Top comments (0)

Eliminate Context Switching and Maximize Productivity

Pieces.app

Pieces Copilot is your personalized workflow assistant, working alongside your favorite apps. Ask questions about entire repositories, generate contextualized code, save and reuse useful snippets, and streamline your development process.

Learn more