Mullilng Over LaSalle Software Version 3.0
by Bob Bloom
category: news
Laravel Framework's version 8 was announced at last week's annunal LaraCon US conference.
The new features have me mulling working on the next "point" release of my LaSalle Software, instead of the usual spate of minor tweaks to get my Software working with the new Laravel Framework version.
The funny thing is, on the face of it, that I will not have to do any LaSalle Software updates for the new Laravel v8. I'll know what the absolute minimum upgrades are when I see the final L8 code.
However, there are major improvements to the factory (seed data) that I want to incorporate. It will be nice to do this in conjunction with cleaning up my test seeding (and perhaps a few other things). I'll be putting this on my list. This alone is not sufficient to warrant a LaSalle Software "point" release, especially since at the end of this exercise there will be no new features.
A new separate package called JetStream was unveiled at the conference, and will be released shortly after the Laravel v8 release. This package is not yet released, whatever was displayed during its presentation is all that I know about it. The image for this post is a screenshot of that presentation's video (behind a paywall, otherwise I would link to it), taken by someone else.
This package will be released as free and open source, encompassing authentication front-end "scaffolding". This scaffolding is very attractive to incorporate into LaSalle Software, as a replacement for the existing "UI" package.
One of the things demonstrated was "teams". JetStream has front-end scaffolding for "teams". I was thinking, well, that looks nice, but there is nothing resident within the Framework, nor anything announced so far in the presentation about new Framework features, for teams. So JetStream has nice looking forms for basically nothing?
Well, it turns out that JetStream uses something else, the name escapes me. The name escapes me because it was not at all presented, but it was mentioned. Also mentioned was that the currently first party commercial app called "Spark" was being discontinued, in lieu of releasing all but a few key features as free and open source. I surmise that the front-end of "Spark" is now JetStream; and, the back-end of "Spark" is now this other package that was not formally presented -- but mentioned.
Which is how I had visions of my LibraryBackend package dancing in my head during this presentation. The "teams" concept associates users with other users (something I do not do in my Software), and associates roles for users (something I definitely do in my Software). The Laravel Framework has built-in capabilities to create roles, called "policies", but no where are policies implemented. This is left to the developer, by design so that the Framework remained "unopinionated".
How resonate the idea of giving people a head start building apps by giving the a fuller building block over and above the Framework! Glad I thought of it!
What is interesting about what I saw in the JetStream presentation is what looks like there is a GUI front-end and a database back-end. The front-end has all the screens, and can reside -- I assume -- in its own domain. The front-end does not do any database operations, it sends its requests to the back-end that does all the database stuff. It looks like the front-end and back-end can be in the same domain.
What intrigued me during the presentation was the idea that the back-end had a viewable and discrete API that could be broadened to include more database administration. If the back-end was written in a straight-forward way, then it could perhaps be broadened -- say, by me -- to encompass the entirety of my administration. Not to put a fine point on it, then I could replace Nova. And in an instant epiphanous moment I understood in my deep heart that I want to drop Nova. Only then did I understand where I truly stood with it.
Another interesting thing about the JetStream presentation was the multiple device feature. The Laravel session guard has a method or two for "multiple device", but more is needed to support it. It was intriguing seeing a list of devices used to log in, during the presentation. There is nothing to track devices in the Framework, unless the device information is tracked in the browser session. Even then, not sure this would really be enough to evince a logout-by-device capability.
Just for fun, since I'm wondering, and it's been a long time, I am looking at https://github.com/laravel/framework/blob/7.x/src/Illuminate/Auth/SessionGuard.php#L11 and https://github.com/laravel/framework/blob/7.x/src/Illuminate/Auth/SessionGuard.php#L553. Yeah, maybe it's about tracking the individual sessions.
I do like the integration with Laravel's Sanctum. The login-by-device is nice to have. And really attractive is the idea of not maintaining my own custom guard!
Finding, and merging, Framework mods into my custom guard is a PITA. I'm thinking that I could "have it all" by using authentication events: not maintain my own custom guard, have all these wonderful native features at my disposal, and keep my own authentication stuff.
Well, dispensing my custom guard is itself worthy of a "point" release. But first things first, I have to see these new packages, and see the new final Laravel Framework 8. Then I'll post anew.
The new features have me mulling working on the next "point" release of my LaSalle Software, instead of the usual spate of minor tweaks to get my Software working with the new Laravel Framework version.
The funny thing is, on the face of it, that I will not have to do any LaSalle Software updates for the new Laravel v8. I'll know what the absolute minimum upgrades are when I see the final L8 code.
However, there are major improvements to the factory (seed data) that I want to incorporate. It will be nice to do this in conjunction with cleaning up my test seeding (and perhaps a few other things). I'll be putting this on my list. This alone is not sufficient to warrant a LaSalle Software "point" release, especially since at the end of this exercise there will be no new features.
A new separate package called JetStream was unveiled at the conference, and will be released shortly after the Laravel v8 release. This package is not yet released, whatever was displayed during its presentation is all that I know about it. The image for this post is a screenshot of that presentation's video (behind a paywall, otherwise I would link to it), taken by someone else.
This package will be released as free and open source, encompassing authentication front-end "scaffolding". This scaffolding is very attractive to incorporate into LaSalle Software, as a replacement for the existing "UI" package.
One of the things demonstrated was "teams". JetStream has front-end scaffolding for "teams". I was thinking, well, that looks nice, but there is nothing resident within the Framework, nor anything announced so far in the presentation about new Framework features, for teams. So JetStream has nice looking forms for basically nothing?
Well, it turns out that JetStream uses something else, the name escapes me. The name escapes me because it was not at all presented, but it was mentioned. Also mentioned was that the currently first party commercial app called "Spark" was being discontinued, in lieu of releasing all but a few key features as free and open source. I surmise that the front-end of "Spark" is now JetStream; and, the back-end of "Spark" is now this other package that was not formally presented -- but mentioned.
Which is how I had visions of my LibraryBackend package dancing in my head during this presentation. The "teams" concept associates users with other users (something I do not do in my Software), and associates roles for users (something I definitely do in my Software). The Laravel Framework has built-in capabilities to create roles, called "policies", but no where are policies implemented. This is left to the developer, by design so that the Framework remained "unopinionated".
How resonate the idea of giving people a head start building apps by giving the a fuller building block over and above the Framework! Glad I thought of it!
What is interesting about what I saw in the JetStream presentation is what looks like there is a GUI front-end and a database back-end. The front-end has all the screens, and can reside -- I assume -- in its own domain. The front-end does not do any database operations, it sends its requests to the back-end that does all the database stuff. It looks like the front-end and back-end can be in the same domain.
What intrigued me during the presentation was the idea that the back-end had a viewable and discrete API that could be broadened to include more database administration. If the back-end was written in a straight-forward way, then it could perhaps be broadened -- say, by me -- to encompass the entirety of my administration. Not to put a fine point on it, then I could replace Nova. And in an instant epiphanous moment I understood in my deep heart that I want to drop Nova. Only then did I understand where I truly stood with it.
Another interesting thing about the JetStream presentation was the multiple device feature. The Laravel session guard has a method or two for "multiple device", but more is needed to support it. It was intriguing seeing a list of devices used to log in, during the presentation. There is nothing to track devices in the Framework, unless the device information is tracked in the browser session. Even then, not sure this would really be enough to evince a logout-by-device capability.
Just for fun, since I'm wondering, and it's been a long time, I am looking at https://github.com/laravel/framework/blob/7.x/src/Illuminate/Auth/SessionGuard.php#L11 and https://github.com/laravel/framework/blob/7.x/src/Illuminate/Auth/SessionGuard.php#L553. Yeah, maybe it's about tracking the individual sessions.
I do like the integration with Laravel's Sanctum. The login-by-device is nice to have. And really attractive is the idea of not maintaining my own custom guard!
Finding, and merging, Framework mods into my custom guard is a PITA. I'm thinking that I could "have it all" by using authentication events: not maintain my own custom guard, have all these wonderful native features at my disposal, and keep my own authentication stuff.
Well, dispensing my custom guard is itself worthy of a "point" release. But first things first, I have to see these new packages, and see the new final Laravel Framework 8. Then I'll post anew.
Update: Perhaps Not So Fast Dispensing With LaSalleGuard
September 02, 2020
It's been a while since I looked at https://github.com/laravel/framework/blob/7.x/src/Illuminate/Auth/SessionGuard.php. Ah, down memory lane! The purpose was to see what and where the authentication events are dispatched.
The purpose of re-visiting the auth events is to relieve myself of the burden of merging session guard changes into my custom auth guard. I forked the actual Laravel sessionguard.php, and so now I am faced with the constant PITA exercise of merging.
The reason I forked the native session guard was wanting the assurance that I would not mess up the critical authentication function, whilst interjecting my authentication customizations.
Now that I have gone through the exercise of forking the session guard; and, merging Framework changes into it (thankfully, there have not been many); and, actually using my Software in production; and, concluding that the existing authentication events are inadequate for my needs; and, with Laravel Framework's version 8 release along with its new authentication accoutrements, it's time to build a new custom guard from scratch.
There are only a couple of authentication contracts to honour -- and honour these is de rigueur! My focus will then be on monitoring changes to the auth contracts, a saner exercise then merging new Framework code into a forked class. A very busy native class!
User! What art thou? This is a major question to mull in the quest to build a custom Laravel Framework authentication guard from scratch.
The purpose of re-visiting the auth events is to relieve myself of the burden of merging session guard changes into my custom auth guard. I forked the actual Laravel sessionguard.php, and so now I am faced with the constant PITA exercise of merging.
The reason I forked the native session guard was wanting the assurance that I would not mess up the critical authentication function, whilst interjecting my authentication customizations.
Now that I have gone through the exercise of forking the session guard; and, merging Framework changes into it (thankfully, there have not been many); and, actually using my Software in production; and, concluding that the existing authentication events are inadequate for my needs; and, with Laravel Framework's version 8 release along with its new authentication accoutrements, it's time to build a new custom guard from scratch.
There are only a couple of authentication contracts to honour -- and honour these is de rigueur! My focus will then be on monitoring changes to the auth contracts, a saner exercise then merging new Framework code into a forked class. A very busy native class!
User! What art thou? This is a major question to mull in the quest to build a custom Laravel Framework authentication guard from scratch.