Livewire and Service class with business logic

Level 58

Great question!

Short Answer:
If you never return, expose, or render the $formula (or the business logic that uses it) to the browser (via Livewire properties, responses, views, or emit/broadcast), then no, there is no risk that the confidential formula will be exposed just by using it inside a service class or a Livewire component.

Explanation:

Livewire components run primarily on the server, and data stays server-side unless you:
- Assign a value to a public property of the component (so Livewire serializes it to the browser).
- Expose it in your Blade views using {{ }} or similar.
- Return it as part of a response (e.g., JSON or download).
Private/protected properties and internal service calls in your Livewire component (like your $tableService) are not exposed to the client automatically.

Example trap to avoid: Suppose you have this in your Livewire:

public $formula; // dangerous if you assign the confidential formula to it!

Then, if you do:

$this->formula = $article->formula;

or expose it in your view:

{{ $formula }}

Now it will be sent to the browser!

Your Code (Safe):

private TableService $tableService;

public function boot(TableService $tableService)
{
    $this->tableService = $tableService;
}

And in your service:

public function calculateQuantityForArticle($article, $variables)
{
    $formula = $article->formula;
    // ... processing ...
}

If the $formula is only ever handled/processed in PHP, and never sent to the browser, you're safe.

To Summarize:

As long as you don't assign the formula to a public property or render it in a view, the formula will not be exposed to the client by Livewire.
Keep all confidential processing strictly server-side.

Tip: If you're worried, you can even name the property on your Eloquent model as protected $formula (so it won't be included in arrays by default), or use guarded fields, but this is just an extra measure.

Conclusion:
You're handling the logic securely. Just remember: never put confidential data in public Livewire properties or views. As long as you stick to that, your formula is safe.

Let me know if you need more information or code examples!

Level 122

only livewire component public properties are shared with the frontend.

1 like

Level 63

I asked for this because in the Livewire documentation it is written that all public functions are accessible from the backend.

If I use a private instance of my service class, it isn't accessible from the frontend.

But what happens if inside the service class, I have public functions ?

Level 122

public functions in the component are callable if the user knows the name of the function.

but nothing that the component uses is callable directly. For example, you cannot call config() using the livewire endpoint.

1 like

Level 63

Arggg I wanted to say in my previous comment that all public functions are accessible from the frontend with Livewire.

Well ... ok ... So even if my service class contains public functions, these public functions aren't accessible from the frontend if the service class instance inside my Livewire component is private.

https://livewire.laravel.com/docs/3.x/properties#supported-property-types

Level 122

doesn't matter. A class cannot be public, its not a supported property type.

A new instance of the service class will be instantiated on every request.

1 like

Level 63

Yes ok ... when I say that the service class instance is private, I mean this.

private TableService $tableService;

public function boot(TableService $tableService)
{
    $this->tableService = $tableService;
}

Level 63

Good idea ... but what about the privacy ?

The calculateQuantity function is public, so accessible from the frontend.

Is there any risk that the service is also exposed if doing like this ?

Level 63

But there is another problem.

Injecting the service directly in the function doesn't seem to be possible.

public function calculateQuantity(Article $article, TableService $service): void

Too few arguments to function

Livewire doesn't resolve automatically the dependencies like in an controller.

So your suggestion isn't relevant in this context.