May 3, 2021

Inside the Logmore Front-end Tech Stack

Ilkka Pättikangas, Head of Software Development at Logmore, dives deep into the front-end technologies of the company’s product
Blog

Why Laravel? And the evolution of Logmore front-end stack

In 2021, PHP doesn’t have the best street credibility. Many would argue it’s either a dying language or already dead, or in the least something you should not be developing your apps on compared to more modern or “robust” technologies. To that, I’d say Laravel is actually the thing keeping PHP very much alive and relevant these days (in addition to Wordpress but that’s a whole another topic).

That being said, I have to admit that Laravel has a bit of a history in our stack and could be considered legacy in some sense. We first started using Laravel in the very earliest days of Logmore in 2017 because our first engineers knew the framework well and could create something useful with it fast. Because of that, the rest of our tech stack has really grown around Laravel over the years. These days, I like to call Laravel our “middle stack”, since it processes requests from Javascript to the actual back-end (written in Go) and takes care of authentication and session.

That’s not to say that Laravel wouldn’t have its virtues, because it certainly does. It’s a very elegant and capable framework while being easy to learn with a clear MVC structure, which helps a ton when introducing new people to the team. Its documentation is one of the best I’ve seen in any framework, so it doesn’t take long to get things started and done. All of this leads to a great developer experience. The framework also keeps improving all the time with an active community, and the ecosystem around it is actually quite amazing these days with a lot of different tools and services. 

It’s occasionally (and only half jokingly) said that 90% of modern front-end development consists of fixing up Javascript build tools. I have to say that Laravel has made life pretty easy for us in that sense, because the ecosystem includes its own Webpack wrapper called Laravel Mix, which (like Laravel itself) is both simple to set up while allowing deeper configuration as needed. With clear tools given, we avoided the chore of choosing the “right one” out of the numerous different build tools out there.

One of the clearest use cases we specifically wanted to use Laravel for in recent times is our custom billing management system, which we created almost completely in Laravel. We needed to build the system in a rush, and knowing that Laravel would allow us to create a rock-solid system fast, it wasn’t much of a debate. Laravel is also used in many of our other internal admin tools. 

Finally, Laravel includes a template engine for views called Blade. Like I’ve said about everything else in the ecosystem, Blade is elegant and easy to use, which allowed us to quickly develop the basic key components in our product back in the day. For instance, the view for individual Mission reports in Logmore Cloud is still built on Blade to this day. This is particularly cool, because Blade works very well with Vue.js.


Why Vue.js then?

Vue.js has become the main technology we use in our front-end. Initially, we ended up choosing Vue because of our experience with Laravel, as they work well together.

The Logmore Cloud contains a lot of data flowing in and within the service all the time. Naturally, interactive UI components are a necessity, when you need to manage a ton of different reports, graphs, user and Mission settings, and much more. Javascript is obviously a given, and back when we started, the Laravel community preferred Vue as the front-end framework.

In the beginning of 2020, we decided we wanted to start converting our front-end to a full blown SPA to further improve interactivity. The team was already familiar with Vue, and it didn’t take long for us to realise Vue would be a great choice to continue development with. For the structure we wanted, it turned out to tick all the boxes: Vue is easy to expand on and create a robust large-scale structure around, it’s suitably opinionated for us, and would work for both standalone components (to be used with Blade) and the bigger SPA architecture we were building.

Of course, many developers would argue that we should have chosen one of the other big three of Javascript, either React or Angular, most probably React. For some, Angular might be a great choice, being strongly structured and with first-class Typescript support, while React makes a case with its minimalism and the plain fact that it’s still the most popular JS framework by far. I think Vue is a great balance between the two of them. In a lot of use cases React could be better, but the things Vue is opinionated about happen to suit us perfectly. But obviously, all three of these frameworks could do the job just as well, so it comes down to preference. 

The basic structure of a single file Vue component is really great, dividing the code into a template part, script part and styles. The template resembles pure HTML, and styles can be easily scoped to the component at hand. Two-way data binding and state management are very simple, and smart computed properties are a joy to use. Vue also has clear lifecycle hooks, which are something we use in pretty much every component. It comes with its own router as well, which has worked great for us.

For global/module level state management, we use Vuex, which is obviously made for Vue and integrates seamlessly with the framework and its dev tools. Again, it’s a decision made for us, whereas React could be more open-ended in terms of what to use for state management. While it’s a strength in some cases, it also creates its own challenges. If we can use the work some other smart person has already put into figuring out how to best do things, why wouldn’t we do it like that? On the other hand, Vue allows us enough flexibility without being too opinionated, and we can do everything we need to do with it.

Personally, I’ve used all of the big three, and find working with Vue preferable to using React or Angular. Like Laravel, it’s easy to learn. In fact, one of our front-end devs had never worked with Vue before joining Logmore, and it didn’t take much time at all for him to be building great Vue components independently. Overall, we find the DX of Vue to be superb.


Did you enjoy the article? Talk to us or keep on reading

Want to
upgrade
your supply
chain
transparency?

Want to
upgrade
your supply
chain
transparency?

Let's talk