Rretzko's avatar
Level 15

Add configuration table or pass variable

Hi - I’d appreciate any feedback on the following design decision :

My app is used by teachers. Teachers belong to schools and schools have ensembles, libraries, and programs. In working through the CRUD workflows, I can either pass a school id on each call to the ensemble, library, and program modules or I can save the school id into a teacher_config db table (or session variable) for general use and update this value whenever the user changes the school.

Passing the id on each call seems more ponderous but transparent for later development, while using a configuration option hides the additional layer of ownership but might cause unexpected troubleshooting glitches down the road.

Your thoughts on best practice? Thanks, Rick

0 likes
3 replies
LaryAI's avatar
LaryAI
AI
Best Answer
Level 58

Hi Rick,

The decision between passing a school ID on each call or storing it in a configuration table or session variable depends on the context and requirements of your application. However, I can provide some general guidance that might help you make the best choice for your situation.

Passing the School ID on Each Call:

  • Pros:

    • Transparency: It's clear which school is being referenced in each operation.
    • Statelessness: Each request is self-contained, which aligns well with RESTful principles.
    • Flexibility: It's easier to support scenarios where a teacher might interact with multiple schools within the same session.
  • Cons:

    • Verbosity: You'll need to include the school ID in many function signatures and API endpoints.
    • Repetition: You may find yourself repeatedly passing the school ID through several layers of your application.

Using a Configuration Table or Session Variable:

  • Pros:

    • Convenience: You can access the school ID from anywhere in your application without passing it around.
    • Less Clutter: Your method signatures and API endpoints can be cleaner without the extra school ID parameter.
  • Cons:

    • Hidden Dependencies: It's not immediately clear that a function or method depends on the school context.
    • Potential for Bugs: If the school context is not set or updated correctly, it could lead to hard-to-trace errors.
    • Scalability: If your application needs to support concurrent interactions with multiple schools in the future, this approach may become a limitation.

Best Practice: A best practice approach would be to carefully consider the trade-offs and choose the option that best fits your application's current and future needs. If your application is relatively simple and a teacher is unlikely to switch between schools frequently, using a configuration table or session variable could be a pragmatic choice.

However, if you anticipate the need to support more complex scenarios or want to adhere to stateless design principles, passing the school ID explicitly might be the better approach.

Here's a simple example of how you might pass the school ID explicitly in a Laravel route:

// Route definition
Route::get('/ensembles/{school}', 'EnsembleController@index');

// Controller method
public function index($schoolId)
{
    $ensembles = Ensemble::where('school_id', $schoolId)->get();
    return view('ensembles.index', compact('ensembles'));
}

And here's how you might store the school ID in a session variable:

// Storing the school ID in the session
session(['school_id' => $schoolId]);

// Accessing the school ID from the session
$schoolId = session('school_id');
$ensembles = Ensemble::where('school_id', $schoolId)->get();

Remember to consider security implications as well. If you're using a session variable, ensure that it cannot be manipulated by the client to access data from another school.

Ultimately, the "best" solution is the one that aligns with your application's requirements and your development team's preferences for maintainability and scalability.

I hope this helps!

Best regards, LaracastsGPT

lyleyboy's avatar

Personally, I think passing the ID is good practice and lets you take advantage of Route Model Binding. That said, you have to make sure the user has access to that item. If you have a multi-tenancy application, which it sounds like you do, it might be better to swap the ID's out for a slug. This way your tenants can't guess URL's and potentially see data which belongs to a different account.

I hope that helps

Please or to participate in this conversation.