Skip to main content

Our Tech Stack

VH has many active projects, and for the sake of maintenance and knowledge transfer, we'd like all projects to share a common stack. While the critical components of our projects are mostly the same, advances in technology have caused projects to diverge a bit over time. This page serves as a living document meant to help make sense of those divergences.

Main stack(s)

Shared Technologies

Hosting

With the exception of VeganHacktivists.org, all of our projects are hosted on a DigitalOcean server managed by Laravel Forge.

The server is backed up by Digital Ocean once per week.

Local Development

Laravel has a wonderful Docker setup called Laravel Sail, which should be the only choice for running our projects locally.

A number of our projects were built before this was available, so we are all over the place with this one. Our older projects collectively use custom Docker setups, Gitpod and Laravel Homestead, and some people are even using Laravel Valet to develop locally. All of these methods should be considered legacy, and if time permits, we should be moving over to Laravel Sail.

Admin Panel

With the exception of Vegan Bootcamp, all projects that require an admin panel should be using Backpack. To set this up, follow the guide for setting it up.

CSS

All new projects should use the Tailwind CSS framework. A number of our older projects use Bootstrap for legacy reasons, but this should not be considered for future projects.

JavaScript Build Tool

Vite is currently the recommended build tool for Laravel projects and is set up by default. Most of our projects were started before this was the case, so they use Laravel Mix which is a wrapper around Webpack. It is recommended to switch to Vite if possible.

Package Management

We use Yarn for managing packages in our projects. Originally, this was the default choice for Laravel, but as of Laravel 8 or so, it has switched to NPM. To keep things consistent, we will continue to use Yarn.

Code Formatting

This is another fragmented part of the stack, but as of now, the recommendation is to use Laravel Pint for PHP, and Prettier for everything else. For the latter, please refer to our base Prettier config.

Some projects are using Prettier or PHP-CS-Fixer to format PHP code, and others are using nothing at all. It is recommended to set up Pint for PHP and Prettier for everything else if possible.

Laravel / Inertia.js / TypeScript / React

As of now, this should be considered the go-to stack for most new projects.

Why Choose This?

Typically, building a single-page app requires you to build an API, which introduces a lot of overhead to the development process. However, with Interia, all of that overhead disappears.

With Inertia, you are able to build a single-page app without the API. In essence, you build your back-end the same way you normally would with a plain server-rendered front-end, but your data gets sent to a React app instead.

There are several reasons for choosing React for the front-end. React is easily the most popular front-end framework, which makes it easy to find people who can work on VH projects. It also has an extremely rich ecosystem as a result, which makes building complex apps much easier.

Other technologies we've used in the past (e.g. Alpine and Livewire) made things a bit more difficult because of the smaller ecosystem. Whenever we needed more complex components, such as comboboxes, we usually had to reach for clunky solutions or implement them ourselves. By using React, we don't have to do that anymore.

As for TypeScript, the reason for it is pretty simple: a type system gives us more confidence in our code, especially during things like refactors. Static typing also lends itself to more powerful dev tools and helps make certain functionality even better (e.g. autocompletion in your text editor).

Why Not Choose This?

Under very specific circumstances, it may not make sense to choose this tech stack. Mainly, it has to do with the size and complexity of the project.

If the project is complex enough that it needs some sort of server-side logic (i.e. Laravel), but is simple enough that the front-end wouldn't require or even benefit from even a moderate amount of JavaScript, then it probably isn't worth using this stack, since it would lead to unnecessary complexity and a much larger JavaScript bundle.

Notes

Relevant Projects

Laravel / Alpine.js / Livewire

This stack should be considered legacy, but it is still permissable to use it under certain circumstances.

Why Choose This?

The main reason to use this stack would be to enhance apps built using an even more legacy tech stack. This is because it's much easier to introduce Alpine and Livewire in small bits, whereas Inertia would require entire pages to be rewritten, and they'd also come with JavaScript bundles that include all of React.

A good candidate for this would be something like Vegan Bootcamp, which was built before these libraries existed. If a project has had unanticipated changes in requirements that now demand more interactivity, it would probably make sense to introduce Alpine and/or Livewire to the project instead of rewriting everything using Inertia/React.

Why Not Choose This?

The main reason is the smaller ecosystem/community. While the technologies are great at what they do, there are far fewer off-the-shelf solutions for common UI problems, thus making it more likely that you'll be writing a lot of custom code. The solutions that do exist are much less likely to be maintained for a long time, also due to the small community.

Relevant Projects

Laravel / Intercooler.js

This is an ancient tech stack used for only one project: Vegan Bootcamp. The combination of Alpine and Livewire are far more powerful, and in the case of the latter, much more deeply integrated into Laravel, rendering Intercooler useless for our projects.

Relevant Projects

Plain Laravel

There's not much to say about this. It's just Laravel with pages rendered by the server using Blade templates.

Why Choose This?

You may look into this if you are building a very simple website that is just complex enough to require server-side logic.

Why Not Choose This?

If the project is going to require even a moderate amount of client-side interactivity, you are likely going to be served far better with the Inertia/React stack.

Relevant Projects

Plain PHP

This is even simpler than using Laravel. It's PHP without the framework.

Why Choose This?

There's not much of a reason to choose this, especially for future projects we're likely to build. However, it's permissible if an application is so simple that it only requires a little bit of server-side code, maybe 1-2 pages, and no database.

Why Not Choose This?

If you have a multi-route website that requires more than a couple hundred lines of server-side logic or anything moderately complex (e.g. authentication, database interaction, etc.), then Laravel is likely going to be the better choice.

Relevant Projects

Plain React

Short of plain HTML, this is the simplest stack of all.

Why Choose This?

This should of course only be used for projects that require no server component, but require rich interactivity in the client.

Why Not Choose This?

If you need server-side logic, of course, don't choose this tack.

If you can get by easily without access to React or its ecosystem, it might be best to go with plain HTML.

Relevant Projects

Radix UI

This is a React library that makes it very easy to built complex UI components that adhere to accessibility standards.

Thanks to Stephan for the recommendation!

Laravel Query Builder

This is a Laravel library that reduces the need for boilerplate when implementing common functionality related to database querying, such as sorting and filtering.

Thanks to Joaquín for the recommendation!

Laravel TypeScript

This library parses your Laravel models and creates TypeScript interfaces out of them, which eliminates a lot of work in Inertia/TypeScript/React projects.

Thanks to Joaquín for the recommendation!

VeganHacktivists.org

[To be continued by Tobi or someone else from Team Avocado]

Data Projects

[To be written by Stephanie or someone else from Team Strawberry]