My little piece of internet

I’ve built a new website for myself and I’d like to share some geeky insights of it with you.

In the past year I wanted to do and learn many things.

One of them was to create some space for myself on the internet. A space where I could put together photographs from my trips and couple of sentences about it as some kind of travel diary.

I wanted to learn more about web apps, more about working with various APIs, perhaps build one myself. Keep improving it over time and adding a new things to it.

With my own rules, with my own web development, googling and stackoverflow searching skills.

So I combined all these and voilà..


I started with the API. Ever since I got to work with Laravel at my workplace I fell in love with it. Where I work, we use Laravel on all kind of bigger projects. I decided to go with Lumen as it’s better for purpose of serving as an API. Thanks to Jeffrey Way and Laracasts, it was not hard to learn and get good insight of how to build an API from scratch.

My main priorities while working on different projects is that if there is something I can code myself instead of using a library. I do it. Of course if it’s something more complicated and if it will make my life easier, then I use trusted library. Sometimes going with library is definitely the safer option to avoid hours of coding or frustration. Or even potential security flaws.

But, sometimes if you are using library like VueJS which I used for the front end, lot’s of bits where you could use a library, you can do yourself. Good example would be Modal component. In VueJS its very easy and it works great.

But now, lets get on to some features I’m quite pleased about.

Photo Upload

Photo upload for the trip pages and process behind it.

Photo upload flow

So on upload, the photos are being resized using fantastic library Intervention Image. Images are resized to max 700px in height. Then the thumbnails are generated which are served in the admin area.

The next step is quite important. Cache all the important information and EXIF before image optimisation which are then saved in to the database.

After that the photos go through kraken for optimisation and are being uploaded back to S3 overwriting the previous file with optimised file. So if there is problem with kraken, the photo is still there. Unoptimised.

This way I can get good optimisation of the photos and keep information about the photo in the local database.

Also because I’m optimising already resized images, I can easily do with a free tier of which gives you 100mb quota. Although, I’m more than happy to upgrade my account as soon as I reach the top of the free quota as I think is fantastic and deserves my support.

Rest of the API is quite straight forward. You can have a look at the rest of the code here.

Front End

For the front end, my first steps were pretty much setting up my web-starter and start building on top of it. Design it along while coding where I had some ideas in my mind of what I wanted to do and what I wanted it to look like.

Along the way I could improve web-starter with missing or broken bits and pieces.

It’s built on VueJS with intention of not using jQuery at all. Which I managed successfully. I choose Vue is lately I’ve been working with it more than before and it’s pretty amazing framework. I’m sure the latest growth will continue.

There might have been an easier ways in terms of my setup. For example I could have used webpack, even fantastic vue-cli which would give me great setup to start with. But for quite some time I’m interested in Rollup and I always want to use Rollup whenever I can. Especially after reading The-cost-of-transpiling-es2015-in-2016 and others.

Some of the copy is hard coded as I’m not going to change it much and it would be generally good to have some content not api dependent. At least, that’s easy solution for now.


This is the main section that was probably where most of the work went into. Especially the single trip page.

I wanted to list pretty much all trips, even the ones that were smaller ones and maybe don’t deserve entire page. These you can’t click through. The big ones that have some content in you can click through, they stand out a bit more.

Lazy loading for items is implemented across the site, so if you reach botttom of the page with trips, the “next page” is being loaded automatically. In case that the browser height is greater than items that fit within the viewpoint, the second, third.. etc. page is being loaded right away on load.

For the single trip layout I wanted it to look a bit like If I would stick photos in the notebook and write a caption for each photo. Generally the layout repeats:


..image, caption..

..caption, image..


but with three different orientations: portrait, landscape and square. In addition to this, to make them a bit more “messy” there is randomly generated transform: translate() on each photo to move them slightly out of the “box”. This makes the layout always, on every refresh unique because it’s never really the same. Caption is aligned accordingly based on transform: translate() value.

For the images, generally across entire site I’ve added lazy loading which benefits both sides, me and the visitor. Me saving on requests from S3 and visitor on data.

All the image data (camera etc.) is coming from pre-optimisation exif data that I saved to the database on upload.

Manage Trips

The site has also admin area which is mainly for the trips, to manage or add new ones.

Some of the features implemented there are:

Medium like editor for the trip content as well as photo caption:

Medium Like Editor

Photo manager — upload, order, remove or mark photo as featured image:

Photo Manager


This section is more experimental as I have some bigger plans what to do with it but for now there is not much to it.

The data itself are pulled from Discogs API via my api which might not be the best way but I’m transforming the data in to more prefered format. So if in the future the source api changes, I can keep the same format by filtering it via my own api.

When you click on a record — you get the track list as well as Spotify link if the particular album is available on Spotify. Again, to save on data and extra request quotas, the requests to obtain track list, bigger cover image and Spotify lookup is done “on click / tap” of the record.

There is a lot more one can do with brilliant Spotify API, my thoughts were even things like songs for the trips but that might come later..

For now when viewing a single record modal, if the piece you are viewing is available on Spotify, you will see an icon which links to the album on Spotify. As well as preview for each track. I would like to do some more fancy stuff like this in the future. In fact I’ve a little project going on which will connect both services, Discogs and Spotify together. But about that later.. 😊


There is so much about code and practices and what’s right and what not. At the end it’s important that one feels good about his code and have a reasonable thinking behind it. I’m sure If I would start with this site again, it would be different. Perhaps much better than it is now but that tells me, that I progressed and learned something new again.

Feel free to have a look at the (api & front-end) code, I’m open to suggestions, even some pull requests.

Thanks for reading!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.