Setting things up - Devlog #003

7th Jan, 2023
Share

Modular Approach

I've decided to go for a modular approach, trying to isolate each feature, so that they don't become too intertwined as the codebase grows.

This also allows me to work on features independently from each other. If I wanted to outsource some development work in the future, an external developer could hop onto a feature branch and get started.

This approach also allows me to be a bit more clear about what each feature's requirements are, and their dependencies on each other. Some core features, like "Contacts" will be a dependency of all of the additional features.

Setting up Laravel

I'm trying to focus on the business logic of the app, rather than doing everything myself. If there's a well-maintained library or framework out there, I'd prefer to use it over writing custom functionality myself - my main goal is to get to an MVP.

That being said, I'd like to use as few third-party libraries as possible. If the app becomes too complex, I won't be able to maintain it or update it without a lot of effort.

For Laravel, there's a few additional libraries I've decided to use:

  • Sanctum - Authentication for the React.js client, and future API
  • Magic Link - Passwordless sign-up using magic links sent via email

Development Environment

Frustrations with my current development environment

For the second half of 2022, I've been learning Docker and experimenting with WSL2.

I've been doing most of my development in PhpStorm, running on Windows, but via Docker running on an Ubuntu VM inside WSL2. It does work, mostly…

I had a few issues with this set-up that kept cropping up that kept eating into my development time:

  • Docker Desktop on Windows - I wanted to try working with Docker Desktop initially, rather than WSL2, but there was an issue with the volume mounts changing, and not being recognised. I quickly gave up with Docker Desktop, opting for Docker on the Ubuntu VM via WSL2.
  • Getting Xdebug working - I was really struggling to get Xdebug to work reliably. Combining PhpStorm on Windows, Ubuntu on WSL2, and PHP/Xdebug running in the Docker container was making it really difficult to debug why I wasn't able to connect to the debugger. I spent days trying to figure this out.
  • PhpStorm with WSL2 & Docker - I tried to set up PhpStorm on Windows to work properly with WSL2 and Docker, but I couldn't get everything set up just right. Indexing was taking a long time, I couldn't get PhpStorm to recognise binaries installed on Docker/WSL2, I couldn't validate Xdebug was working, etc.
  • PhpStorm remote development - The latest version of PhpStorm has a beta remote development feature, which looked amazing. I tried setting this up but didn't get very far. It's still early stages, so I think I'll check it out again in a few months.

Setting up a fresh development environment

I've given up with WSL2 and Docker for the time being. They're great tools, but I was spending so much time debugging issues with tools, and not writing any code.

I decided to re-install a Linux Mint VM and run everything from there. Aside from a couple minor performance issues (now resolved), it's been a breeze.

I've got one machine running all of the tools, servers, etc. It took a bit of set-up installing and configuring the various packages, but I would have done the same writing a docker-compose.yml file.

One thing I forgot about - which I really love - is being able to pause a VM. It's so nice to pause your VM at the end of the day, shut down, then come back to exactly where you left off the next day, with all of your terminal windows and IDE exactly as you left them.