This is a transcript. For the full video, see Tackling Complex Business Logic with Laravel - Tag1 Team Talk #012.
Preston So: [00:00:00] Hello, and welcome to Tag 1 Team Talks. The webinar and podcast series on emerging web technologies. I'm really excited today because we've got an amazing tag one team talk episode this morning about a Laravel and complex business logic. my name is Preston So, I'm located here in New York City, editor in chief and Tag1, moderator of the Tag Team Talks, and also senior director of product strategy at Oracle.
We're joined today by three of my cherished colleagues today at Tag1, first Laslo Horvath, who is the senior Laravel developer at Tag1. He has 13 years of experience in various technologies, mostly PHP based, specialized in Laravel and Symfony , applying them to middle to large size projects. He contributes to a variety of different Laravel and Symfony packages, including creating the entity hydrator for genetic, generic entity, hydration and Symfony and soft delete cascade for doctrine.
All of those words went pretty much over my head, but I'm excited to talk more about what Lazlo's working on. we're also joined today by Fabian, a mainstay on the show. Fabian is the senior technical architect and performance lead at Tag1. Fabian Franz is also one of the five Drupal seven four branch maintainers.
He's based in Switzerland, and he's also one of the top 50 contributors to Drupal 8 and as the maintainer for several Drupal 8 core subsystems, including big pipe, dynamic page cache and theme API. Now those words I know. And finally we're joined by Michael Meyers, managing director of Tag1, also located in New York.
And just to kick us off, Michael, what are some of the things that we're interested in talking about today? Why Laravel for a group that has primarily talked about Drupal in the past?
Michael Meyers: [00:01:39] Yeah. Great question. everybody, thanks for joining us today. We work with a lot of tools and technologies. We're definitely most well known for our leadership in the Drupal community, but we work with a lot more technologies and try to pick the best tool for the job.
We're going to talk a lot about this today, but there were many advantages to using Laravel for such a data-driven application, some unique client needs. and, It's exciting. It's a really cool piece of technology and it's a great fit for the project. And so we wanted to share why we chose it and some of the awesome things that we've done with it for this group.
Preston So: [00:02:18] Thanks so much, Michael. And just to kick us off here, I mean, one of the things I know that is really interesting about this project is that, it involves, millions of users. I know that we can't really talk much about the actual client, but what exactly did this project entail? What's the story behind this incredible use of Laravel that we're going to be talking about today?
Michael Meyers: [00:02:39] So it's a, it's a large membership based organization. They have millions of members across the United States, broken into over 3000 affiliates, managed by local groups that roll up into state groups and conglomerates of state groups. So it's a really complex structure. Local affiliates can often be managed by volunteers or designates.
and so, you know, the systems need to be really usable to a broad array. and then there's of course, the organization itself, the national organization, and a whole team and slew of users that oversee and need to be able to jump in and do all sorts of things. It is really complex, you know, people, join the system, lead the system, can hold many roles.
and there's a lot of information, and information that changes, you know, say you get married, you need to change your, your name, you move from one organization to another, change your address.
Alright. Initiation for the benefit of dues. And so it's really a critical and core part of their business because it's how they raise their money to service the organization through fees and dues and for their members. It's how they track and receive the benefits that they get. As you know, being a part of this organization.
there were also a lot of technical challenges, again, that we're going to go into as well as internal organizational challenges. And I think a lot of organizations deal with this, you know, they have a lot of tools and technologies they use, but limited funding and a limited technology team. And so internally, they have a really great team that has a broad array of knowledge, but they don't necessarily have a tremendous amount of expertise in, you know, individual systems.
And so one of the critical things here is that they're able to run and manage this system longterm. And what we're doing is replacing a system that was built historically by another, a services company and agency that really never met the needs of the application itself. but also wasn't really something that the organization could own and continued to build on top of both because of the architecture and because the technology choices that were used.
And so a big part of this engagement is we're working very closely in conjunction with the organization, training and mentoring their resources, overseeing their development so that they are in a position to continue to own and maintain this internally. And one of the reasons that we're going to about picking Laravel is because we abstract a lot of the complexity once it's been put in place and enable them to fulfill their day to day needs, without necessarily having to dig into that on a regular basis. It's inherently there for them.
Preston So: [00:05:31] So I definitely want to dig more into the choice of Laravel and how exactly you abstracted it out that complexity. but first, you know, I know that one of the things you mentioned was, you know, changing your name, changing your address. What were some of the other core features that were involved in this project, that this organization has really required? During a, the kind of discovery process and development cycle.
Michael Meyers: [00:05:56] Laslo, Fabian, anything exciting or or complex on a feature and functionality standpoint? I know that, there are some really cool things that we did as far as managing the data from a UI standpoint. the ability to, you know, edit in place, you know, trying to make it significantly more efficient to save the organization time.
Because this is a big part of their, their resource, you know, day to day work. And so every click we can save them every minute, you know, that we can bring back to the organization is something they can use to, you know, applied to other areas and functionality. And then, you know, the fact that we have a, you know, an API based system that plugs into a, you know, a decoupled UI.
it can integrate on the back end with a wide array of technologies. So their accounting system, for example, Microsoft Great Plains Dynamics system and other internal systems need to pull data and push data, enter the system.
Fabian Franz: [00:07:02] Okay. I think, if one is most important things is just the sheer amount of data, like millions of numbers.
That gives challenges on a completely different scale because you're not just, need to migrate, migration also was a large part of this project, you don't need to migrate like, like one thing. It's a little thing and after an hour you are done , type of things. But at one point before performance optimization, which we very nicely did, it took seven days, to migrate just one part of the database. And, before that we were talking about like maybe, I think the original estimate was like 14 days or something. We are now down to whatever, one day. that's pretty cool. but really the amount of data is also really like a, it's like a huge challenge for the organization.
And because there's so much data already there, obviously, you also need to process it and, and do different things with it. So that's, there was definitely one of the challenges to get this project.
Preston So: [00:08:15] Yeah, sounds like an incredible project. and one of the things that I wanted to ask is, especially because of the fact that, you know, a lot of people have heard of Drupal, they've heard of Symfony . a lot of
People have heard of Laravel , but I think it occupies a bit of this kind of gray area where people are a little bit less aware of what Laravel is, why, why was Laravel chosen over other frameworks for this project.
We dug into a little bit, but I'm curious, you know, is it just because the name sounds cool? I really liked the name Laravel . I think it's a great name, but were there other reasons why Laravel was chosen and really articulated for this particular project?
Laslo Horvath: [00:08:53] So, well, basically, yeah, you're correct in saying that Laravel occupies a sort of gray area. It was one of the frameworks that came a bit late to the game, so to speak. And it's internally, parts of it are really based on Symfony , so like internal works of Laravel use Symfony components. And well, from my standpoint, I would say it's....
First of all, it's a really well structured and it allows the developers to really focus on just like developing the logic itself. Not waste too much time on, on doing repetitive work, but really be able to focus on, on the meat of the project. So really, really building out the business logic.
Apart from that, since we are talking about the single page applications, we have a completely detached front-end. It's also really easy and really powerful in building APIs. So again, when building an API, you can really just focus on fetching data, returning it without having to worry about a lot of the other things.
Plus, it has a great way of allowing developers to control what they want to send back from the information. Because as we already said, or mentioned, there's a complex permission structure in place because there are different levels of, org affiliation and organizations. So this plays a huge role in deciding for Laravel .
it's, it's actually, they have a built in integration Vue.js, So this actually speaks to add to it being a good choice for a single page applications. And, one of the main selling points is as, as someone mentioned, the team, their internal team that should, later build out the project and, and continue maintaining it, was not, familiar with, with Laravel or I think they, they know Drupal well, but, since they were not that familiar with any framework or they didn't have a preference in that Laravel is a good choice because it's a lot easier to learn. It has a much a better learning curve than other frameworks like Symfony because you know Symfony is more...
I always say like, you need to be more of an engineer to, to, do Symfony and Laravel is more free flowing, so it's, it's easier to dig in and really start seeing results right away.
Fabian Franz: [00:11:29] Yeah. one thing that Laravel really makes great is, how it focuses. So 100% on a great development experience. This makes it really, really nice to work with and, M saying all those concepts you know, from somebody like a dependency injection container.
Now all of those, they've taken those same concepts and made them simple. This is kind of how I would describe the main draw thing of Laravel for example, I know saying that honestly blew my mind was, if you want to , set up an API, you usually have to, include authentication. And then you have to put that token that you have to put that into the view into the Axios and, and do all those things.
And maybe you need to set up an authentication token factory, like overall service or whatever. So it's, it's really complex. It's usually blank. it goes through some tutorial, of course, reached somewhere, In Laravel . It's one line of code. It's, it's really one line. You add it, your whole Vue front-end can speak as Laravel , automatically magic, transparent.
And I was like, wow. Like this side of code. It allows everything to do that automatically. That was really great experience in that. And speaking of APIs, so it was also one important part here. Well, what's usually not a good idea technologically is allowed for everyone to just direct divided interest database.
Because while the stored procedures, you can do things like triggers or you can have an audit trail or other things, in, in modern words, you really, really want your database specified on a schema, but then you want to hide this database complexity behind, way easier APIs. And that's also why Laravel was a very good choice for this project is because, if you want to build everything API based anyway, a single page application is the next natural choice because then everything is API based.
You are basically dogfooding your API based approach. So that other systems in the future, like a 3rd party system like internal third party system and like combining needs to get data from the same database, can use those APIs to basically get their data out and in, in the inconvenience that, so that's one way to, To basically, you build up a database that you're building internally into the organization after success by providing this API layer that can then be used for everything within the organization to interface within that database. And I think that's, that's also a very powerful way. And again, here, Laravel has some strengths and, on the other end, everything's a lot more bare bones than what they used to from Drupal, for example.
Just for our audience that are familiar with Drupal. you have something akin to entities, which is so-called models. but they are like directly edit to tables, and then you add like, things like, you wanna, go to some other tables. So you will define relationships. Like this has one, for example a user has one email address or things like that. And by doing that, you very simply, can, can build up basically this complex structure in the database. You can describe the same logic in your application. And again, this is when you have to work with very custom data models. it's a pretty good way to ensure you can, can build an application that tailors to your database.
And not an application that defines the schema like that. And, that was really, another huge advantage here in that. And yeah, it makes everything basically simpler. Then Symfony for example. So that's a really cool thing.
Michael Meyers: [00:15:44] Fabian, So what's the back end database that you guys are using for this
Fabian Franz: [00:15:49] In this case? It's a Microsoft SQL server thing.
so, Laravel can work easily with MySQL, but it can also work as seen here with MySQL, ms SQL server. So Microsoft, there's other bindings basically. Yeah. So that works well.
Laslo Horvath: [00:16:14] Had any issues with, with some custom stuff that's, that's applied only to, to my, to MSSQL server. So I was actually surprised that it works this well. I was, I was interested in seeing how it works because it's really an odd choice to use, like PHP and then. MSSQL server, but so far really like what we're doing, three months of work already.
not a single issue was, was noted. I really expected to like, okay, finally I'm going to submit like two to Eloquent is called the your Oren tool that that Laravel is using. I was ready to submit like a bug report. Like, okay, this is not working in, in SQL server, but so far it's, it's gone without a hitch.
And. It's really important because as Fabian, as you mentioned, when you have an existing structure, to like, like Eloquent really helps because you have the freedom to, to build out your model without having to, to alter the database because you know, all the modern modern frameworks have this, this way of, yeah, define your code and then the database will be generated based on your code.
Like you define the class system in code, like entities in Drupal and in case in this case, you really have a database that has, frankly, 30 years of data in it. So it's not an option to, you know, build out the model in the code and then like hope to somehow fit everything together. So this is, this is one of the good, good things about Laravel .
Fabian Franz: [00:17:46] Yes. I suppose also for this particular client, very important for them to be able to say, because as I said, the data migration process, which part of this project, but also designing this database structure. So why the date data is 40 years and more older? It all gets imported into a very fresh database.
So in theory, the model of the application providing that thing would have worked, but the problem is, and there was kind of what the previous database was like. if you do something like that, then you have some problem that writing reports can get very tricky at times because you have very, requirements that are very important and that you need to generate some reports just for the business to work correctly. And if you can't generate those reports, you're basically toast. And, when I see other parts of the project not related to Laravel , but more in general, was that we took good care like we said, we need to build, we need to migrate the status as soon as possible, and I then we need to build out all these reports.
So then we can prove that the system works. And not just after the fact, after it has been built for three years or whatever, they see, we cannot get the report that you need. So, but yeah, here Laravel really was nicely adjusted to being able to fit to whatever data structure you throw at it.
Preston So: [00:19:23] Wonderful. And I know that, one of the things that I'm sure is going to be very interesting to our Drupal audience is also the notion of Laravel adopting a Vue.js . I want to just turn to that just very briefly here because I'm very curious. What exactly does that mean when we say that Vue.js can use Laravel and how did this client use Vue.js with Laravel but, maybe before we actually turn there.
Let's just tease the audience a little bit because I know we're talking about the front end. Let's turn first to the backend challenges because I think this really extends upon what both of you are talking about. so here's, here's a really interesting example that I know Michael wanted to call out.
You know, there's this idea in a variety of different dashboards and reports of a filtering component. now I understand that you were able to use an existing package for this. How did the kind of ecosystem surrounding Laravel help solve a lot of the backend challenges that you had?
Laslo Horvath: [00:20:21] So, Fabian, you want to proceed?
Or
Fabian Franz: [00:20:24] Just quick intro. So from the Drupal world, we are used to "there is a module for that''. And, now you're come into, say, PHP or even God forbid, the JavaScript files. And yes, there's an NPM package for that and has around 10,000 requirements. And, Then, so from Drupal, we are basically used to this one module, one job for one thing, and forking is really, well, it's a little bit discouraged.
It's seldomly happens. that's something is forked. And so, we really have this, if you know this, a module, you usually know it's of high quality. And, That was particular in the PHP world in general, in the MPM world it's not always the case. However Laravel here? and the ecosystem around it has really astounded me that many, many, many of the packages that are available are of very high quality.
So this again, speaks to the, to the nice, ecosystem that Laravel has built that many of those packages are really high quality, nicely to use. And yeah. And now giving Laslo to introduce it some more.
Laslo Horvath: [00:21:49] Yeah. So what, one of the things we noticed when we got there, so one of the most, the most important requirements for the API was that they are generic.
That there is no duplication of code, no copy pasting, and that it's very easy to extend and like perform some, some actions without having to really do a lot of implementation behind it. So what we, what we, When we got to the project, we noticed that some of the things we're already were started to be built out in this generic fashion.
And then we were like, Hey, there's a, there's a package for this. So this is something that I constantly do. And when doing Laravel like, okay, I still do this, but let's first check if there's something on this subject. And. You just check in there, they already done it. So there's really, if you just dig up the documentation, they have so many powerful things out of the box.
Like it's, it really helps in focusing on just doing the logic and not, not wasting time on things like this. In our case, since the API has had to use like generic filtering and sorting. And, eager loading. There's, there's a great package. it's called query builder from one of the core larval developers who already encapsulated all this.
So you, what you do is just, you know, you, you have your API endpoint, you specify, you have the documentation, you take what you need, you specify it through the front end, you get. And basically the backend already sends you the data in the format that you need. So we had some work to do it, to adjust it, but it was really minimal. So
Fabian Franz: [00:23:31] Yeah. So to make this more concrete of what this does is let's say you want to return a member and the member has, has an address and you want to return the address in the same API call. And all you have to do is basically add to the API call list. include and then you include that you want to, for that member address, you want to include those. And then due to the relationship being already defined, that one member has an address. It gets automatically put in.
So again, it's, it's nice, nice developer experience. Yeah. Again, I, that we have seen,
Laslo Horvath: [00:24:11] Yeah. Because you know, in, in, in other, you always have like a trade off. Either you will load, like I already met the applications that, you know, you have, you want to show a list of hundred entries.
So let's say in this case, you want to show a hundred members and each member has a relationship to an address, to an email, to social media, to bank accounts, to whatever other information. And then you end up with like pulling one third of the database on an API call because you know, we want to display all the data.
And the other end is you end up with a lot of API calls because you load the basic data. And then for each role you have to. you get like, okay, these are the routes to the other information. If you want to load it, then you do a look up from the front end and then you end up with, with a bunch of API calls that just cause a lot of server activity that you could like say with, with the, with a much simpler call.
So in this case, we had like a best of both worlds approach where the package itself is allow us to. To include the information that we need dynamically. So if you want, you can just just get a flat list with just the basic information from, from your model, or for listeners who are more familiar with entities.
and in the other case, if you want to show like a relationship data in the in the table as well. So let's say if a member has an address, you can just specify it and you can even drill down to, to the field level. So you can say, okay, the address itself has 50 fields in the, in the table, but I don't need all of them.
I just need like a street address. state. And that's it. So you can just say, okay, just give me the address, ID, give me the, the street address, and the state. Then it will be done like that. So this is, this is one of the, one of the good parts about this package.
Fabian Franz: [00:26:05] So basically, there has been a certain push.
Certain developer types that say, Hey, every API needs to be very pure. It needs to be a pure in that it only returns like the raw data. And then you need to do another eject call for the address, et cetera like that. And then, then you have GraphQL, which basically allows you also to do such query. Claiming from the, from the client, which then is basically doing the same. but Laravel basically it's pragmatic. That's kind of what I would call it.
Laslo Horvath: [00:26:42] It, yes, that's the best expression,
yeah.
Fabian Franz: [00:26:46] Allows you to be pure if you want to be, but it's pragmatic by default. That just gives you the best out of both worlds. And that's really good. In other packages we used originally, not in the end, but originally it's paid package, but it was still pretty nice for some early stage demos, was Laravel Nova.
And with that we were able to demo at least at all. The data is now in the system. We can access it, we can drill down. And again, that was already making an impression early on as a sprint spend, the front end and back end was not built out yet much. Just to be able to see all the data. So there was also pretty good
Laslo Horvath: [00:27:27] Laravel always.
Like I used a bunch of scaffolding applications in different technologies from botnets to Java, but Laravel Nova was the, like the easiest one to set up and to like, as you said, just to be able to, okay, this is the data you can. Just display it and then have time to, to develop your, your own map. It's, it's really powerful.
And it's also developed by the core team. So you know, that it's of high quality.
Preston So: [00:27:59] I am really interested in, in talking more about the, kind of, how
you described level as being pragmatic. we'll, we'll take that offline. but Fabian, Hey, and last of all, I'm kind of curious. one of the things that you mentioned as well was. you know, we talked about filtering a little bit.
We talked about eager loading. but what about enabling some of these really complex workflows? You know, I know that, one of the things that has to happen with these members in this application is that they have to be able to do certain complex things, engage in a process over a period of steps.
what exactly, how exactly did you use Laravel ? to. Make these complex workflows really streamlined and a much more easy to build and also really straight forward for the members side of things.
Laslo Horvath: [00:28:48] So, as, like the, like the saying goes in, Laravel , there's a package for that. So in this case, there's a, there's a fairly cool package.
It's called Laravel Actions, which is, Which is like focusing on, they call them vocable classes. So it's basically an action as its name defines it, just focused on executing one action and how it's. How it affects development is when you think of a workflow, it consists of certain steps. So I don't know, you have a new member, you want to make sure that you fill out all the info, all the most important data.
You want to verify that information, and then you want to like either activate the, activate that member, or maybe you want to get some more information and things like this. So in this case, each step would be one action. And, you just chain the actions together into a certain workflow. So because they have a lot of complex workflows where based on membership changes, based on like, maybe even.
Like moving an address, for example. Maybe they need to change the affiliation, things like this. They have a certain certain steps that they need to go through, like the organization. Is there for a long time. So it's normal in big organizations with 3 million members. They all stay. Of course, they have to have like process for everything.
And this process results in these workflows. So what, what the, what the package enabled us to do is, just like build out single steps and you can reuse them in each workflow as you wish. So it's pretty cool. Also from, cause I'm always interested in the, in the design patterns slash software architecture side of things.
For me, it was really cool because it really plays well with, with certain patterns that, that allow you to set up complex workflows without having the complexity in the code itself. Like, you know, otherwise you would, you would get certain parts of the code that would be hard to maintain and . Hard to test out actually.
And in this case, writing a test for an action is like, okay, you have, you have one test case. Maybe it's, it's defined by the data that flows in and that's it. So it's really easy to test that out. And make sure that it's, that it works properly.
Fabian Franz: [00:31:13] Yeah. Again, again, it speaks to the pragmatically being, being out in that it makes design patterns, which are, Pretty complex or can be pretty complex, easy to use, but not over abstracted. That's kind of kind of the point because Java, Java being the prime example of having basically all design patterns that exist unearthed, in PHP, also going in, in parts to this. one of the larger problems is that you get so abstracted, that you.
Get lost in translation or you get lost in the, in the interater or lost in the decorator where you have five layers of decorators at a decorating each other, et cetera, and where in the end you have so much complexity that a team that is more at the normal developer level to junior level. Will have very, very hard time to, to even grasp what this code is even doing anymore and someone in five years will like, I have to click five times to do that. And this fortunately Laravel , but it's not. So, that really is pragmatic here in that you define your action. It does. One thing, it does it well. Things like the Unix command. And you can have an isolate test.
Laslo Horvath: [00:32:44] Yeah. So think of for that, a good example in this is, for example, if you want a certain action to be asynchronous.
So for example, I don't know what this action is. Export 20,000 rows from the data they build into a CSV file, for example. You don't want this to be like, you don't want the request to wait for, for the response from this action. You just say, okay, now I want it to be asynchronous. It's basically just one line of code and the action will be called asynchronously.
It will be done, done in the background and your code can go on and do wonderful things, and then you just decide what to do with when, when the call is over. But basically it's just the one liner. I can relate in Symfony if you want, you have to find a bundle or a package that does this, then you have to include it and you have to trigger an event.
You have to give it the payload. Then you have a whole structure that you need to go through before you are able to really just. You know, do the thing that you want to do and here is just say you take the action that you had and you say like, okay, this is curable. And that's basically it. It will take the configuration and trigger it itself, and that's it.
So really it's a really cool, cool thing. It takes a while to let, not a while, but you know, it's, if you're coming fresh to this, it's great. If you come from a world where you are used to like having to jump through hoops to achieve your goal, it can be astounding to know like. Wow. I can just add one line and that's it.
Like I'm not used to this. And then I'm like, okay. You know as when you do a lot of software development, you realize that the complexity has to be somewhere. You know, it's, if you do a lot of simple actions, they will have to be bundled together somewhere and the complexity will end up there. And with Laravel , the complexity is
taken away from you into the core package. So they take, take out all this, okay, you need to wire this together and you need to call this and that and just give you a one liner that you can call in and just focus on your stuff. So that, that's what's really cool about, and all the packages that are, that are developed for Laravel , the, they follow this same design principle, like make it easy for the developer to use it and then it will be used.
So don't. Don't overengineer or make it, as you said, pragmatic, and it will, it will be used. And that's, that's what we had with all the packages that we included in the project.
Preston So: [00:35:17] Amazing. And, I guess just on the topic of abstraction, one of the things that, I think is really interesting about this project is that you leveraged a lot of the existing capabilities that were available and Laravel to enable. Access control at a variety of different levels. how did that work exactly?
And how does the access control that was provided to these users relate to the filtering that we've already described?
Laslo Horvath: [00:35:44] So from, from a business side perspective, we already touched briefly on the subject. Basically, users are always part of a certain affiliate. So they are always part of some organizations, let's call them organizations because it's, I think it's easier to envision that.
And of course these users should only see the information that's available in this organization. They shouldn't be able to see like all the information that that's out there. So like the first, we have this really low level filtering that says like. Just show the user of the data that he's allowed to see.
This is what we call like a first level low level filter. That's basically what we had to do in Laravel and what's what was really easy to achieve is to. Have this, it's called the scope. It's a global scope per Laravel definition. This is a bit of a technical term, but what it does is it takes all the queries that are, that are ran through Eloquent, and it applies a certain filter to them, so you can define what the filter does.
And what did, what the does is all the data that can be filtered by a certain affiliate in this case will be filtered with, with this affiliate. So it can be one or it can be multiple affiliates, but the important thing is all the data is filtered this way. So you will never end up in a situation where a user will see data that's, that's not, that shouldn't be available to him.
The good side about this is if, if you want to do some reporting, for example. And you want to see cross-affiliate and you want to see everything. You can easily do this by just the disabling, the, the, the filter. So you, it's, it's possible. And, the benefit of this is the developers don't need to take care of it.
You know, you just, you just code away and the system will take care of, of, of all of these things. And you know, you, you don't have to apply. conditions to your queries anywhere or to too Eloquent, Eloquent queries. You can just, you know, write, write the code that you, that you need to write so. Yeah.
And
Fabian Franz: [00:37:53] for the viewers , this is very similar to how, node access, control bugs in Drupal away where basically, when one thing can grant access control to node.
Basically, you're part of an organization because that your user is part of this organization and this organization that can then grant a content node. the access control. so if you are part of this, you will automatically be having this access control. So that's one part of how Drupal makes us possible.
simple, Clary older, eh. Where this in Drupal you have to implement like 3 things. I've used Clary Alta and the entity variable times normal carry all tops if you want to have all the use cases in there. But if, for example, all your Drupal is built up on views, it can be as simple as adding a mandatory filter to every view.
And then you also have said, he, again, Laravel just gives you some concepts of making it possible to do this, that you can, it's basically giving you, again, a framework of how you can implement those, access control and filtering. It's still not easy. because it's, it's, it's a hot topic regardless in that, it, just as a caveat on that, but, this was basically allows you to do this like node access or group access or group filtering that Drupal also can do, in, in Laravel .
And this is how we, how we were able to achieve that for ensuring that, for example, if you choose something on the front end, we are not always passing this back to the backend. Well, basically anyone could hack, Hey, I want to use some other group instead. And when they look at that, but because it's server side set, you only have access to those.
And this is filtered out for your automatically. You cannot basically access. So and so. The front end also does not need to deal with it to find and can just just say, Hey, display me all members. And depending on the service at scope, it will get different data. Yeah. I think front end also is next. Help.
Laslo Horvath: [00:40:21] Yeah. So, so this is, this was one of the types of filtering that we had. we had another two layers of filtering added as you, as you, Fabian already mentioned, we had, we had also the goal to, or the requirement to be able to filter. On an organizational level. So not just give me all, all the data from all the organizations I have access to, but give me data for a specific organization.
And this meant that all the data, all the, all the data in all the tables that we have had to be filtered down by this organization. And again, it was fairly easy. It's, it's, it's easy to, to set it up, but then to implement it, you have to, you have as a, there's a caveat to that where you have to. To implement the use cases, but it was still, if there's a place for it and, and you know exactly where you need to go to to achieve that.
And then there we had the third level of filtering that was like the dynamic filtering that the users themselves can apply, which means if you have a table that displaying members and then you go want to go and say, okay, give me all the members that are from a certain state because you want to organize an event in that state, and then you want to invite those people so.
This is also fairly easy. I mean, for, for the basic use cases, it's just goes down to filter the table based on some information. But you can come across some more complex situations where you need to, like even in an invoke some business logic before or after applying the filters. And it's also fairly simple.
In Laravel you can, you can do that. You can just define a filter class and implement it and you know, it will, it will take care of the work for you. And you just pass it. Of course, you pass it through the, through the call, and this, this will be, this will be done.
Preston So: [00:42:19] Wonderful. Well, you know, we talked a lot about kind of the backend logic and how you all have really successfully abstracted out a lot of this complexity that's in the business logic.
Let's talk a little bit about where, users actually interact with this, with these workflows and, and leverage, things like lyrical actions from their standpoint behind this kind of glass layer, which is the front end. and one of the questions I think is on everyone's mind, especially as they listen to this as well as is a very complex application.
Why did you go with the single page application approach? Were there considerations maybe to go with the traditional model and more monolithic approach?
Laslo Horvath: [00:43:00] Well, there were certainly pros and cons in both approaches. So, you know, people are more, you're more used to maybe the, the monolithic, the, I call it old school approach, which of course has its, has its benefits.
But in this case, I mean, you know, the. The verb is and not now. It's, it's, it's been moving this way for a long time already. But you know, this is like, especially for, for these kind of hidden business side apps that are not, where SEO is not important, where you don't have to take care of marketing and branding or whatever.
Very can really focus on, on like data management. Because after all, this is a data management platform that we're talking about and it's kind of natural for it to be. You know, to, to enable the users to do much more things without having to wait each time for the page to load. Because every run for the server and, and, and getting the information back takes, it takes a certain amount of time.
You know, you can do a lot of caching, you can do a lot of optimizations, but in the end you will have to go to the, to the whole cycle each time. And in this case, you can really like, Focus on, okay, so now I have to hide this page. I have all these available actions from this page and each of them will take a certain amount of milliseconds and we are talking about like two, two digit low, three digit numbers, which, which make the whole experience for the user like really pleasant because you can just click around and things are happening instantly.
Without having to wait for the page to load and for information to become available. So this is like one of the, one of the things that I stress always to people who okays you. So you won't want to have a B2B app or you want to have like a on a platform for managing data. And this is, this is a good choice.
It's certainly adds a certain amount of complexity because now you have. A full stack environment. You just don't have your, your normal environments where you can focus on on PHP and just building out the HTML or whatever. Now you have to like decide where to store some of the logic. So some of it belongs to the front end, I don't think goes to the backend, but when you know what you're doing. It's, it's a much, much more, it's a much better approach than, than just just doing the old school way.
Fabian Franz: [00:45:22] Yeah. Absolutely. one other thing is, as I've said already, they need to dog food, the API. So, if you don't use those API they would be in some corner crying and be left forgotten. So, it's really important that those APIs are used so, the application is built versus API. So that made an SPA approach. The single page application approach, kind of the only one. Obviously, especially for something that is called a membership application makes a lot of sense to actually be an application, and I mean, we've all seen how rich applications feel very similar to desktop applications nowadays through a good made a mobile application.
It feels almost just indistinguishable from, from a native application, except for maybe some speed or latency. so it really made, made sense. Yeah, on the other hand, legacy is coming back. It's not only me, but also Laslo will be talking way later here and announcing something nice for people.
in the, also talking about basically bringing, bringing, legacy applications back, to, ensure, That this Full Stack also has a lot of problems and you also always have to comply. You with, you have to and Laravel again is so pragmatic. It makes sense. The most simple way to implement a boosting.
It's like if he is natural in that, you just have all the steps set up for out for you and you basically can just start building from, from day zero. in that you don't have to do large plumbing first and set everything up. but really you just define your component and it's found you can use it and the rest is again, then automatically for you, how it should be,
but yeah, a legacy will be making a comeback.
I, let's say right now in that, but we are, we've talked a little bit more at the end.
Preston So: [00:47:44] Wonderful. So the, kind of, you know, we talked a little bit about the APIs and the link between how we can handle presentation and data, within this application. How are you actually building the front end, with Vue.Js and, and this really brings us to kind of the, the actual interior of the, and the inner workings of the single page application.
And Vue.js.
Laslo Horvath: [00:48:08] So, yeah, Vue.js Was the natural choice because it, it plays so well with Laravel . And the next step was to find like, okay, now we want to, to, to use Vue.js So we need to like use there are,some basic components that you want to use everywhere. So if you have tables, you want a data table defined once, and you don't want to have to.
To like implement a lot of things all the time and just basically it boils down to copy pasting. So, there are a couple of frameworks that are really good. So component frameworks for, for Vue.js. Okay. Yeah. Beautify, which, which we ended up choosing, and Quasar are probably the two most widely used ones, but Vuetify is by far the simplest one to integrate.
So it's, it plays well with a lot of CSS framework. So you, whatever you choose from, from the CSS standpoint, beat material, Bootstrap, Tailwind, whatever you want to, it's, it's fairly simple to. To integrate it with, with Vuetify. And it has a, a huge repository of, of, components that you can just plug in and, and start using.
So this was, from, from the Front end standpoint, this is, this was the biggest choice we had to make. And so far I didn't run into any problems. We didn't, we basically didn't have to code to change any behavior. We didn't have to like I'm used to, I did a lot of Vue and a lot of Angular projects and sometimes I ended up browsing through the GitHub finding the component that I need them. Then checking the inner workings to actually be able to, to do something. And here all I had to do was like browse the documentation if I was unsure on how to get something done, and that was it. So it was really a pleasant ride for me.
Fabian Franz: [00:50:05] Yeah, we did a pretty large review of several different technologies that were available to us at that time and when we did to choosing, and that also looked at a lot of the inner workings of code.
And Vuetify came out as most clean and all of that where the components, even looked a little bit React like. So very clean components very nicely to use. In fact, sample sets things for somebody like a flip card. You just define a flip card. And then you nest the lsots be, it'd be below like the children and it just works.
And this is how components should be. You use it. You take a look at the documentation and also data tables. it made it really, really simple to do. so it was more larger complex things that are usually taking a lot of time to build out in applications and such. Saved does time basically.
Preston So: [00:51:06] Well speaking of time, we are running short on time here today. I really think we can talk for another couple hours about, Vuetify and some of these really interesting, elements of the project. I'm particularly interested in the kind of component architecture that you just described, Fabian. Unfortunately, we are at a time, so I do want to take a little bit of an aside tag here.
And talk a little bit about some of the other things that we're working on, out in the world today. I guess I'll go ahead and start and we'll just go around the table and hear from everyone about something cool or interesting that you want to share with the audience that you're working on.
Shameless plug could be an interesting piece of content you're working on. Could be a cool project. So this week I've been working with the Decoupled Days team, of days is the kind of premier and first ever. Community led headless CMS conference in New York city. It's also the kind of decoupled Drupal unofficial conference as well.
And this week is your last week, to get, I'm not sure when this will be posted actually, so maybe I shouldn't say this, but, we are working very hard to prepare for the conference and get tickets right now at decoupleddays.com. by the time this comes out, sessions will probably be announced. although, with the current situation, around the world, in terms of public health, we'll see how that goes.
So it's decoupleddays.com. If you want to check that out and let's go ahead and switch over to Laslo. What's your aside tag for today?
Laslo Horvath: [00:52:33] yeah, so we actually touched on it, or Fabian mentioned it and I completely agree. So the backend is kind of coming back. So, so like legacy apps are making their way back.
And, to honor this, there's a really cool new Laravel project slash package that was announced a couple months ago. Now. It's already available. it's actually really easy to include it in the upcoming Laravel seven release. It's called Live wire. And it's like, it makes it so much easier to, to, you know, to create components that will seamlessly integrate with, with, with your existing application.
Or if you're starting a new one, it can like,. it allows developers to really code how they use to code. So if you're used to like legacy apps and how you code on them, how you, how you structure your code, where you put your components and everything, it actually allows you to do the same thing. And, but on the other hand, it seamlessly integrates between components and the backend so that you can, you can leverage APIs and things like that without having to worry about wiring without having to.
To specifically call like Ajax and, and perform Ajax calls. You can just, it does it out of the box. So it's, it's really, it's really a cool feature. And the shameless plug would be that, I am currently writing a plugin for, for intelligence or for PHP store that will enable users to use auto complete features and things like that with the live wire package.
Fabian Franz: [00:54:12] Yeah. Basically, I'm Livewire implements, a huge part of this vision that I've shared at Drupalcon. I was not aware of that at that time. So, basically they, they did all of that. They did use, even in Laravel seven, they've now switched over to define components no longer in blades, like add some text, but completely as tag.
They just do the X and then the component. You can just define a component and it's a critical S class, but if you're not PHP savvy, then also define a component with some properties just as as a blade file, so it's really, really great. it also takes the best, best of the worlds of, of what we had in Drupal Ajax system.
And still people are using, it takes this and makes it a 10 or 20 times better in that it makes it developer experience of using this. So easy to blade X dollars like this. We have to go through all those steps to make something. And really, you, you, for example, you have some counter and when you're incremented, you just put it put like a Meg, similar to a very virtual property via, colon click.
increment, and then it automatically calls the increment method on your class in the backend. Whenever someone clicks this button, and this is just, that's why we are saying our backend is coming back because it basically does all those things of, of, of or whatever in, in, in simple things, but really as a pure backend, like an application in that combined just tremblings.
And you're pretty much, it's near single page application and it's unfortunately not as data driven as I would like, but this with the HTML algorithm, they speak of HTML is a data structure. And I, I assume that be, you're running into some problems in the future with that as well. but it's still a very interesting thing.
Well, the thing I wanted to talk about is Tailwind, because we've, we've started to use this. And Tailwind is this crazy thing where you basically put inline styles as a critic, like to call it. So, you, if you want to style something, you put like text center. And then you put md font large and such things.
so, and people like are saying, Hey, these are inline styles. They never worked, but, when inline states originally had been, had been invented, those inline styles, had begin. Where you had like a thousand HTML pages that you were putting in HTML by hand, et cetera. So the cascade made a lot of sense.
But today we are in a component based world and it's so much more simple to just, not have to invent a class for everything you would want to style. So for example, you have a card and you need to put card, this is card and this is a, or this is a button or whatever. And instead when, now you have your blue button component, your Laravel button component, maybe introduce your Drupal button component.
And. Well, we've gone away from that. And then you can really just put, put your classes in there and you don't need an external CSS file. And this makes that, it makes things much more scalable because one of the things I've found on many of our legacy projects is that this CSS gets to be immutable over time.
That means, No one dares to change it anymore because no one knows what side effects it would have, and that means only used CSS gets added. And that happened not only with our project, long legacy projects, even with best developers in the world this happens. And the proof of that is it happens to say as far as it happened to Github, it happened to all those organizations.
They'd have basically had the same problem of only new code was written and the more developers you have, the worst the problem gets. And this is basically taking those global changes that change everything. You change one class, it can change everything back to localized changes. If you change this part of the HTML, if you change this template, it will only effect this template, and this is just absolutely fantastic, because it allows you to prototype very nicely, it allows you to work very fast.
And, we're trying it out and, it feels very feared to write HTML with all those classes in first, but it makes a lot of sense. So try it out. Tailwind.CSS.com. But yeah, Tailwind CSS, you'll be able to find it.
Preston So: [00:59:14] Awesome. Thanks. Fabian, how about you, Michael? What's your aside tag for today?
Michael Meyers: [00:59:18] I wanted to mention the Acquired podcast, outside of, of costs, the a Tag Team Talks, the Acquired podcast is my favorite. It's awesome. They talk about, tech IPOs and startups, and they cover everything from the history of the founder. Through to the history of the company. what's made it successful?
The challenges, the business models, future predictions. so for example, you know, Oh, well, it's yoked with two part series
on the history of Elon Musk and what led him to becoming the quote unquote founder of Tesla. And, you know, as an entrepreneur and someone who's worked on a lot of startups, it's really awesome to hear about, like the trials and tribulations of, you know, of Elon, you know, leading up to this and the near failures and catastrophic ends to Tesla along the way.
so it's, it's fascinating. And it also, I think, Has taught me a lot about, you know, how to run a business, including things that we can leverage a Tag1, listening to like the Shopify talk and how they leverage partner relationships early on. You know, reminds me of our approach to Tag1 quote and partnering with agencies with rev shares, to, to grow our market.
So if you're interested in, in startups, and technology companies, I highly recommend you check it out. And, they actually gave me the idea for this new section or a podcast. At the end of their talks, they bring up something interesting and exciting that's going on. You should check out. So I hope you guys like this new section.
We're looking for a name for it.
So, please, please reach out to us if you've got a great name for what we should call this section and, check out the Acquired podcast at acquired.fm.
Preston So: [01:01:11] Well, I'm personally a fan of A Side Tag, but, I think it's a joke that'll go over a lot of people's heads.
For a name, alrighty. Well, we are just about out of time. I want to say a big thanks to Laslo and Fabian and Michael for joining us today. as we mentioned, at every single, end of this, at the end of every single tag, one team. Talks episode. All of these links that we mentioned today are going to be online at the top.
Whether you're interested in Vuetify or Tailwind, CSS, Fabian, or other things that we've mentioned today, they'll all be available
in conjunction with this talk. If you do enjoy these episodes, please feel free to upvote subscribe, share it with your friends and family, your grandparents, and also check out past talks that we've done at dot com slash tag team talks.
You can always suggest the topic. Give us some tips. Drop us a line at tagteamtalks@tag1consulting.com
I want to thank everyone today for joining us as well as my dear friends Laslo, Michael, and Fabian, and until next time.