@akaydin I'm not sure what you mean: "Is it practical to have common files for those two apps?"

how do they handle multi-platform and secure apps?

NativePHP is multi-platform by default - your single Laravel codebase is used to build binaries for each platform.

No apps distributed to a user's device are 100% secure. Any critical business logic should always run server-side with a secure API in front of it

@akaydin I think if you plan having undetermined amount of admins and don't want to make anything complex, you can replicate what Jeffrey suggest: A field named role and define different roles such as user, advanced user, operator, admin, superadmin, etc. According to your needs.

if you require anything more sophisticated you can create a permissions table, role table and pivot table. Then you can associate that role to a user. Each permission can correspond to a Gate. And inside the gate you have to check if you have that particular permission.

@akaydin While the ID reservation will work technically, I don't believe that is common practice in an application where you have many "sysadmin" users. A more common approach in this instance is to have a flag on the user that is specific to indicating that they are a sysadmin/superuser and check that. So the users table would have a boolean column named is_sysadmin that you set to true for any sysadmins in your platform.

If you have a lot of staff who require varying levels of access, you may end up at some stage with a separate user model for staff with its own role-based access control system that's separate to your end users. In large applications, managing internal staff users can end up becoming separate apps in their own right - especially where you require stricter access governance and higher levels of security, or if you end up with multiple deployments of your application for data sovereignty or customer data privacy needs. I've worked on apps where granting sysadmin access had to go through a multi-step approval process, was time limited when it was provided, and had extensive logging of what the sysadmin actually did while they had access. It can get pretty crazy how complex this solution can evolve to become.

I would follow Jeffrey's advice in the video to keep things as simple as possible at first, and only add complexity later when you actually need it. Far too often we try to build something that feels like it will flex to accommodate future complexity, only to find that when we eventually meet the complex scenarios down the road that they actually require a different solution altogether. It's much more difficult to change an existing complex solution to a different complex solution than it is to make a simple solution more complex.

morning, overslept or something? :))

I have made a primitive nightshift worker to myself like a week ago. My task was to update and refactor everything to new Livewire 4 setup. It's not arbitrary, so that I did not want to spend my time on this "luxury" task. Created a new branch, so if thing's got messy, I would go back easily. I waited like 20 minutes and it was going perfect. Then left it and go to bed.

My rules were similar, but I also added call laravel-simplifier and check after every commit. This was misunderstood, it kept calling laravel-simplifier:laravel-simplifier after every edit, was like 10 thousand times. After a sanity check, I figured out that too much refactoring and had to re-write almost half of my tests, so I went back to the origin branch and add testing to the scope of the nightshift. (I didnot call it nightshift, mine was "unmanned")

Second night, I requested Claude to make a master plan first, and follow the plan. Included testing. This way, it had a better routemap and did not call laravel-simplifier once in every minute. again, almost was ok. but figured out that it created irrelevant directories and forgot to remove old directories. some new files were referencing old classes, again it was a mess.

Third try, (I created a totally new livewire project, and referenced it's directory and approach. The scan notes were inserted into my main project. This second .md helped a lot. While maintaining the consistency, it also figured out some more improvements by itself, that I hadnot noticed even.

If to summary, for the first time in this human being's history, I managed to think something earlier than you. I'm proud.

Cheers,

Thank you for the great tut.

Just out of curiosity, creating a native app for Windows desktop and Mac desktop will have too many common files. Is it practical to have common files for those two apps?

Also, can we do it for the web app and desktop app? I mean the styling, the models, the actions.. almost the core will be the same, how would it be to store the common files in a single dock? I have 0 knowledge about this, I may sound silly.

One more question, how do they handle multi-platform and secure apps? We would not want out code to be cracked, so critical data and code would be stored in our own server, while simple calculations and request-handling would be on the client side, this is reasonable. If I have a web app, should I create an API to my desktop app and connect the client to the core app?

Regards,

CodeRabbit is a paid service, and deserves every penny. But for a more laravel-native and free alternative, I'd recommend laravel-simplifier. php-simplifier's laravel-first version, kinda.

I commit and before pushing, I call Claude to scan with laravel-simplifier. Almost 99% accurate and most times I accept without touching anything. Then I push.

https://laravel-news.com/laravel-gets-a-claude-code-simplifier-plugin

@jeffreyway I was thinking of reserving a certain staff ids, like up to 1000 (yeah that's a daydreaming, having a 1000 admins in my company :) )

so first 1000 ids will be reserved to the system admins. and in the Gate, I can check if auth user id is smaller than 1000.

Is this a reasonable approach? I mean, do Instagram, Twitter or any other company do it this way? Or in Laracasts, you use this approach? Or, instead checking of the roles?

I do have roles too, admin, editor, viewer (buf these are model Company's roles, not the app itself)

Any recommendations?

lol. 17:25 @jeffreyway reaction to the button colors.

but he keeps his nerves and has to go on somehow..

The moment purplish login button popped up next to the pink logout, he was like " what the.." ahahaha

@jeffreyway in every video, there's a moment cracks me up. This time, the super explanation for the 419 page expired.. typing fast enough ahahah.

Amazing series - hype for sort and islands. ISLANDS!

@alecgarcia awesome, good luck!