Knowing when to keep it simple

We take pride in building things "the right way", but there is a balance to strike with simplicity.

Joel Clermont
Joel Clermont

We already discussed how we pushed back against building an import feature and instead built a one-time user import command. While building the command, the question arose: How do we provide the file to be imported?

There were two aspects to this question:

  1. Where should the file be stored?
  2. How should the command know which file to process?

First, for file storage, we would typically never store user-provided files on the server. We would instead use Amazon S3 to keep file storage separate from our app server. This improves resiliency and scalability. But in this case, this was a file we'd use one time, then delete. So we decided to not use S3, and instead to just scp the file to the server, run the import, and then delete it.

Next, how would we tell the command which file to process? We could have introduced an input argument to our command, but keeping in mind this was going to be run only one time, why not just hard-code the file name? This might feel "dirty", especially when it's so simple to add an argument, but it kept things simple and still solved the problem.

Honestly, if this command wasn't going to be deleted immediately, or if I knew I had more than one file to import, I would have likely gone with our typical approach of using S3 and an input argument. But in this case, simplicity was a better choice for the work we needed to do.

Here to help,


P.S. Laravel is pretty secure by default, but Aaron published a course to go even deeper on Laravel security.

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼

Level up your Laravel skills!

Each 2-minute email has real-world advice you can use.