## who we are
The team of web backend developers, doing custom cms solutions in Laravel for a couple of years now. Solutions are pretty advanced, and following one of the biggest names in the field definitely puts us on the high end of our skill sets and the understanding level of Laravel we provide.

## Laracon eu Lisbon 2023
The company promoted visiting gatherings like that to gain new ideas and inspiration, so we found Laracon EU in Lisbon, which was happening in a month or two. So the unplanned team-building, brainstorming, and lots of fun were waiting for us in one way or the other.

## the day before
Nothing special was happening in the team the day before. However, some small plans were made about how we should travel to the airport and how independent we wanted to be in the preparations.

## trip happening
Trying not to hurry things, we plan to arrive a day before Laracon starts, taking the flight as soon as 6 in the morning to have a complete rest day and the whole evening. None of us was ever in Lisbon before.
Some started the journey at midnight, whereas most of us gathered around 3 in the morning to catch the flight. We even had sandwiches and coffee as we had back in school, so a total nerd trip.

This was our first flying experience for one of us, so a trip's fun was guaranteed.

# day 1
The atmosphere was just as I remembered it, and it triggered the developer part of me with a feeling of enthusiasm and a "things are gonna happen!" voice in my head. It was nice to see Jeffrey Way, with whom many developers grow. The hard truth by Stefan Bauer describes a story of struggle. A must-new tool presented by Nuno Maduro that will change the whole merge review flow requirements.

And thanks god for the food they prepared for us there as things in Lisbon were not playing out well for us. We may be the unluckiest visitors, but here we were.

# day 2
Backend guys already love tailwind, as it allowed us to update our CV to a full-stack developer now. The topic of Termwind by Francisco Madeira made us want to do our own websites in the terminal from now on. As it is hard to imagine anything better than a website in the terminal, we were awakened by the shock of chicken on pizza presented at Batchable Jobs by Bobby Bouwmann, but we still need to say huge thanks to that guy as he gave us the solution we were craving for at the time. I am talking about "you can add jobs to batch as you go."

All the evenings ended with late coffee, smoking, and lively conversations, and that one was no different, no matter that it was the last day.

# going home
It was a circus of its own. Flights being late, connected flights waiting for us, lost luggage, and no smoking time. All were happening to the guy flying for the first time. Nothing stopped us even for a second, as it was still a full-blown, relaxed gathering, no matter what happened, with lots of new inside jokes

The image tells a lot of stories, but only we know what really happened :)

![He was not so generous that day](/media/blog/laracon-eu-lisbon-2023-story.JPG)

Till next time, stay sexy and hydrated.


Laracon EU Lisbon 2023


[//]: # (TODO add content index component here)

# Application requirements
Let's start by defining what an application usually needs so the idea can start and step into the real world. Not even going into the long-term project that grows.
- API data endpoints
- user sessions, authentication, and authorization
- queues/background workers
- application UI, usually SPA
- homepage/application presentation page (for not logged users)
- about page
- blog posts
- news
- subscription managing
- SEO, robots.txt, and sitemap.xml
- other website-related pages and promotions like landing pages, mailings, etc
- deployment (and rollback)
- backups
- database
- persistent storage
- in-memory caching (Redis etc.)
- (sending) mails
- servers/hosting
- (local) development environment
- staging environment
- production environment
- code versioning

# How have things been done till now, and what needs an upgrade in 2023
## servers, deployment, hosting, and hosted environments
I got away from self-hosted servers a while ago and let it all be managed by [Laravel Forge](https://forge.laravel.com/), as it helped me remove most of the self-managed LAMP stack from the previous stack and also added some new ideas I wanted to implement. In the end, it is a fantastic tool that helped me grow to the next level as a freelancer, but with time, it has become (just) an automation of managing LAMP stack servers. Therefore, I am still promoting it as an excellent tool for beginners, freelancers, small project teams, and smaller projects. But I need more now.

Review of current/old flow:

Pros:

- simple push to deploy
- servers are managed by Forge
- security auto-update services
- adding (buying) servers thru the dashboard
- letsencrypt automation
- repository (branch) based deploy integration

Cons:

- site setup overhead and missing auto-setup for some services (e.g., wrong Postgres port)
- hard to edit/manage project-specific Nginx config and some other services
- setting up multiple environments for the same project (stg, dev, ...)
- no scaling / single server application limitation
- risks of no proper backup or failover
- no zero-downtime deploys
- limitation to the shared database and redis services (be careful with redis db ids)
- no resource management / buying a dedicated server upfront based on predictions
- production includes services that are there just for the build time
- semi-solution for tests and build process
- no automatic solution for moving the application to another server
- deploy the whole application no matter how small of a change needed

```
Conclusion: the whole stack needs to change
```

## users, sessions, authentication, authorization, API endpoints
I have been sticking with the Laravel framework ecosystem for managing backend stuff for the past couple of years. It guided me well into the topics and patterns I now understand are a must for every larger project. I liked the idea of Lumen, but I still used it as a monolith.

Review of current/old flow:

Pros:
- great suggested patterns for growing as a developer on larger projects
- solves most application topics (workers, router, validation, ...)
- Test Driven Development of APIs
- I know it inside out / source code is my primary documentation
- fast-developing

Cons:

- cookie-based sessions (used it because of less security overhead as the browser took care of storing it properly)
- hard to target and handle needed performance improvements and monitoring in larger teams with lots of codebase and new features
- monitoring of applications, database, queues, ...
- low performance (not using proper approaches like octane etc.)

```
Conclusion: partial upgrades are needed, but sticking with the stack
```

## frontend framework, spa, blades, compiling assets, CSS framework, auth pages
I was switching my primary stack back when Laravel was version 5.6. When vue version 2 was the default language in the starter project, it seemed a natural next step from the jQuery world. I've tried angular, ember, and some other frameworks at the time, but vue felt the most natural way of doing things. For the CSS, there was bulma, bootstrap, and materializecss. SPA application was served thru url root html output from Laravel blades, and compiling was done thru Laravel mix. Everything is already bundled from the Laravel starting project.

Review of current/old flow:

Pros:
- it all came out of the box, easy to start
- known approaches
- all in one project/stack / single repository
- fast mockup using CSS frameworks

Cons:
- mixing things from blades to vue is a mess
- its hard to maintain/define the proper long-term structure of the app
- vue SPA inbound to Laravel loading things
- mixing Laravel rendering for some things and others in SPA is a mess
- hard to customize or add additional functionalities with CSS frameworks
- CSS frameworks usually require js logic out of the box

```
Conclusion: the whole stack needs to change
```

## webpage specific pages, blog, news, SEO
Using the same stack for web pages as I do for the applications is a nightmare. You can choose between having another stack, like WordPress, or developing new cms as part of your application. As I want to avoid ending up with multiple stacks just to make it look nice, I will focus on finding a better solution that will bring the website and application parts together.

Review of current/old flow:

Pros:
- (none found)

Cons:
- can solve (some) things by having a separate website-specific solution / new stack
- can solve (some) things by developing or including package dependency features needed for websites
- SEO / no proper html output for robots without javascript
- dual development to make the experience between website and application as smooth as possible
- maintenance of multiple systems
- hard to onboard developers onto the project
- ... (this can go on forever)

```
Conclusion: the whole stack needs to change
```

## local environment
Using docker-compose as part of the project, being project specific, was a go-to tool for some time.
Note: I have tried using valet with local npm (nvm), database, etc., but did not like that my system is full of services with multiple versions, etc. Startup scripts started to fail with upgrades or needed changes. Even a bigger mess that took much more time with new machines etc.

Review of current/old flow:

Pros:
- trust in the quick setup of the project environment
- encapsulated services required for a project
- good simulation and testing environment for production requirements

Cons:
- copy-paste from one project to another / no proper boilerplate from which to initialize
- manually editing hosts file for project-specific domains
- wildcard subdomains manual setup
- using a secure connection locally
- performance issues with the local filesystem
- running only a single instance / project at the time

```
Conclusion: some improvements wanted
```

# expectations for the new stack
- independent parts / each part of the application can be quickly replaced with a better solution
- best SEO practices
- scalability
- portability
- result-oriented / quick start with the new app
- long-term maintainability

```
Conclusion: let's do this shit
```

Till next time, stay sexy and hydrated.
