updates 11th Jan, 2022

Developing GetCandy 2

Glenn Jacobs


We started the development of GetCandy 2 in July 2021 and we knew exactly what we wanted to create this time around - an e-commerce package for Laravel that we could extend easily.

We learnt a lot developing version 1 of GetCandy, which was more an e-commerce API than a true Laravel e-commerce package. We realised that developing everything as an API was extremely time-consuming and that most Laravel devs didn’t want the API, they wanted the underlying package. We also started making version 1 when Laravel was changing a lot - Sanctum didn’t exist, nor did Livewire, so it was difficult to keep up.

Our Approach

We had some rules we put down before we started developing version 2…

Document Driven Development (DocDD)

Documentation takes time and leaving it until the end of a project creates a massive chore. We wanted to write the documentation this time around before developing a feature. This way we focused on the developer experience and of course wrote the documentation when it was fresh in our minds.

We believe this approach should be applied to all projects. Documentation is so important.

To enable us to include documentation in our Pull Requests, we have an installation of VuePress in our monorepo in the “/docs” folder. This is then connected to Vercel which automatically creates a preview URL so it can easily be reviewed along with the code.

The Laravel Way

Whatever we developed for GetCandy 2 had to be done in a Laravel-way. We wanted to ensure the package used the same approaches we expected Taylor might take. By making it as “Laravel” as possible, we were future-proofing the project and hopefully going to get the best adoption we could.

One of the main approaches is “actions” which Laravel has started to recommend. We use these to perform specific routines which are encapsulated in a single class (very SRP).

Minimal Third-Party Packages

Packages are great, but if you rely upon them and they’re not maintained you have got issues you could do without. When selecting packages to use for GetCandy 2 we were very careful to only select those that we believed would be well maintained and not cause us problems.

Packages we have chosen to trust are as follows…

Test Driven Development (TDD)

It was important we put in place automated tests as we went. Every PR we made had to include tests (along with documentation). Sometimes, when time pressures build up it can be tempting to skip over tests - don’t.

Load Testing

An e-commerce package might be expected to handle 100,000’s of products and the same for orders. When building GetCandy 2 we ensured we pushed the limits of how many entries the system could cope with whilst still running fast. We’re happy to say, with suitable eager-loading, GetCandy 2 is more than fast enough, especially when coupled with a good search engine, such as Meilisearch.

No Caching

If an e-commerce platform has to rely upon caching to run fast enough (ahem, Magento), then it’s not been well architected. GetCandy uses zero caching and still performs rapidly. Of course, you’re free to add your own caching to your project, as you feel fit.

Easy to Install

Version 1 was NOT easy to install. You needed Elasticsearch installed, had to learn how to run Nuxt.js and configure Sanctum to connect to it. Far too complex.

Version 2 had to be really simple. Livewire offered the best solution to this, whilst providing a modern way to make dynamic interfaces. Along with Laravel Scout for search, with a MySQL driver to get started, made it super simple for Laravel developers.

Must Not Interfere

We didn’t want GetCandy to interfere with a developers code or existing tables. So we made sure we didn’t force Livewire upon developers and also (optionally) prefixed our database tables to avoid conflicts.

API Optional

Version 1 was an API first package. GetCandy 2 isn’t an API, it’s a Laravel package designed to be built upon and that was important for us.

However, we will be releasing a frontend API addon to support all those React and Vue fans out there.

Great Looking UI

A poor UI can ruin a project. We wanted GetCandy’s admin hub UI to be smart, simple and easy to use. And of course, we wanted to be proud of it.

Right now, the admin UI looks great and we especially enjoy the dashboard. However, this is only the start. We want the UI to look amazing and we will be constantly improving and adding further love to the admin hub to give it that feel we aspire to.


Now GetCandy 2 is released we can see how our initial objectives worked out and I'm pleased to say it all went well. There were naturally coding challenges along the way we had to overcome, but nothing that stopped us in our tracks.

Logo Twitter Share on twitter
Glenn Jacobs

Laravel Developer, Guitarist, Car Nut, DIY Enthusiast, Daddy