bugsysha

@mmaged my pleasure.

I would use this

https://laravel.com/docs/7.x/routing#rate-limiting

With Laravel 7 there is no need to do it that way unless you have a specific reason for it which you haven't mentioned. Check this out https://laravel.com/docs/7.x/routing#implicit-binding

Route::get('api/posts/{post:slug}', function (App\Post $post) {
    return $post;
});

Route::get('api/users/{user}/posts/{post:slug}', function (User $user, Post $post) {
    return $post;
});

I think I didn't explain myself well.

Yes, you did explain everything thoroughly. I've just tried to avoid answering that question since there is no consensus on that topic, and you should try to develop your own opinion on it.

But since you are asking politely again, let me give you my idea of how it should work, but take it with a grain of salt.

Should service class make calls to a repository?

If you can avoid it, it would be better. Check out this article since it probably can better explain than I can in few sentences https://reinink.ca/articles/optimize-database-queries-in-the-perimeter-of-your-laravel-apps

It is good practice to put queries logic in the repository?

If you are thinking of Eloquent queries, then yes, with repositories, you force people to give more meaningful names, especially on large projects/teams. If someone is not using repositories, then they might create few scopes to do a specific query, but other developers might miss to include all of those scopes when they try to fetch the same data. And for me, it is more meaningful to test those repositories than separate scopes.

As I do not plan to switch between ORMs, should I put queries logic in my model or create a repository and store my queries logic there?

I think I've answered this one with the previous question.

I would use this

https://laravel.com/docs/7.x/routing#rate-limiting

Which auth package? Have you seen a lesson here on Laracasts on throttling? Check that out, maybe it can help you figure out what you've missed. I do not use it that often but whenever I've used it, it worked.

You will not see any common opinions on this topic. Check this link out, maybe it will help you with your structure.

https://dev.mysql.com/doc/sakila/en/sakila-installation.html

For me, Laracasts is almost a few times per day, unable to load content. And post times still have issues.

Try to reproduce that bug without changing anything in a fresh Laravel install and you should see that everything is working. That would be such a huge bug that everyone would notice it and it would be fixed very fast.

@drewlim7 just register new account every day and like all replies that helped for the next 20-30 years. That should be enough.

😂😂😂

What is social listening?

@ivanradojevic

["2020-03-16T14:44:02.000000Z","2020-03-18T09:07:25.000000Z"],

This looks like you are doing something like {{ $dates }}? If I'm right then you should resolve this with {!! $dates !!}.

The one which you've built and others pay you to use :D

Yeah. I'm confused about how people miss noticing that.

@jjk I'm saying that you should not return contact name also. Just contact ID if you care about data size. But never mind. Point is do not fetch from objects properties on other objects.

@jjk

If you are so worried about data size then you should not return anything from contact object except ID.

@drewlim7 one note. If those columns likes and comments are on that other database then just replace with with join.

Report::query()
        ->selectRaw('report_id, influencer.u_id, likes + comments as total')
        ->join('influencer', 'influencer.u_id', '=', 'report.u_id')
        ->whereBetween('total', [0, 20000])
        ->get();

I'm saying that you should not break encapsulation. If you have something on one object (Contact), do not fetch it from other object (Order). Your app will face a rock bottom if you continue down that path.

Replied in that thread.

@drewlim7

This should work unless you have some hidden gotchas that we can not know of.

Report::query()
        ->selectRaw('report_id, influencer.u_id, likes + comments as total')
        ->with('relationshipName')
        ->whereBetween('total', [0, 20000])
        ->get();

It provides you a simpler way to handle auth via API. You would not have to bother with many things that you would have to think about and implement with Passport.

return $this->contact->name;

This is not appending. It is first doing $this->contact which fetches full Contact object and then you are just getting name from that object.

As I see it DigitalOcean is a provider and Server is one of their Droplets. So with one2one relationship, it turns out that DigitalOcean can provide only one Droplet to whoever comes first to their site and creates a server.

Do you know how to disable access using htaccess ?

No. I haven't used Apache for decades.

Ex: if someone tries to access a subdomain to redirect to the /

You can redirect inside Laravel if you want to go down that path.

Just create a route and redirect to that domain without subdomain.

What have you changed in Http kernel? Or are you doing something with middleware in Service providers? Or maybe some package you've installed?

That is such a bad architecture design that I would make you do a million pushups for it 🤣

Could be.

Use Laravel Airlock (at least that is what it's called at the moment) for that.

Why is German a requirement?

Have you configured the HTTP server and DNS for that VPS? It looks like your configuration is not correct.

Also having one2one relationship there does not make sense to me. I think that Provider can have many Servers.

Table providers has a provider_id column.

Is this a typo or not? Cause providers table should not have reference to itself.

The LEFT JOIN keyword returns all records from the left table, even if there are no matches in the right table.

Your problem is caused by using web and auth:api middleware on same route. Split it into two routes. One prefix with api and other without it.

For those things I use builtin php server. It is great that all my projects are under same URL http://127.0.0.1:8000 😌

You can not get an attribute of some related object which is on separate database table without getting that object from the database.

Probably those two files have the same class names. Rename wrongly named one or remove which is appropriate.

If it relates only to that notification you are sending, then put it inside of that notification class.

The project is in Laravel 5.6 and I have PHP 7.4 installed, maybe that's the problem or part of it.

That should not be a problem.

Hard to help without insight into code. I had a similar issue and I fixed error by error.

  public function toMail($notifiable)
  {
     $message = new MailMessage;
	$message
        ->subject($this->details['subject'])
        ->greeting($this->details['greeting']);

	if (/* condition */) {
		$message->line($this->details['line1']);
	}

	$message
        ->line($this->details['line2'])
        ->line($this->details['line3'])
        ->line($this->details['thanks']);
  }

You can use the cache for that if you do not want to store it in the database.

cache()->forever('user-color' . $user->id, $color);

I guess you can replace Error Handler and do whatever you like https://laravel.com/docs/7.x/errors

That smart TV does not feel smart at all :D

Every larger TV manufacturer has either it's own app store, or it is using something that provides such a feature to it. I guess that it all comes down to publishing an app to it, and after they approve it (if there is QA), then you are all set.

Should I add all relations to the User model, even if they're not applicable to some user roles?

Yes, add them.

Just do not overcomplicate it. Go with the simplest solution. If you want to clean up the User model, then add simple traits to encapsulate common logic for specific user types.

Showing me a broken example without an explanation of what you are trying to achieve does not help. Use words to describe the desired behavior.

I am looking for a good website or resource to kick-start my learning with NodeJS specifically Express

I'm not aware that something like that exists.

Also, I am curious if JavaScript back-ends have proven themselves to be good alternatives to something like Laravel, or Rails.

Yes, but no. They are used by "smart" companies, but still not that common in lower-tier market companies. Not sure if there is some specific reason for it.

Should I add all relations to the User model, even if they're not applicable to some user roles?

Yes, add them.

Just do not overcomplicate it. Go with the simplest solution. If you want to clean up the User model, then add simple traits to encapsulate common logic for specific user types.

I'm not sure I understand what you are doing here. If you are looping through arr then why do you need getter and setter for it? Operate directly on it.