In this article I’ll explain the tech stack I’ll be using for Data Blade. Of course this can, and probably will change in the future when I get more users, so I might do an update to this article in the future.
PHP and Laravel
Data Blade is written in PHP using the Laravel framework. I chose PHP because I write PHP daily and I’m fluent in it.
Despite my knowledge of the Symfony framework I chose Laravel for this project mainly because of the amazing developer experience. Using Facades and helper functions greatly speed up development. Also the vast amount of libraries like Laravel Cashier or Livewire reduce development time even further, making it possible to put more of my time developing the core of Data Blade.
You have a lot of options for building the frontend. Use a clientside rendering library like React or Vue or just use the Blade templating system of Laravel.
I chose to use Livewire using the Filament framework. Using Livewire I can create interactive applications writing only PHP, so I don’t have to maintain an API and a separate frontend codebase like when using React or Vue.
For Data Blade I’m using two types of databases. A regular relational database and a NoSQL database for storing the transformed output of the tunnel.
The relational database is running on a PostgreSQL server. But I could have easily chosen a MariaDB or a MySQL server for this project because at the moment I’m just using the basic features of PostgreSQL which are also available in MySQL and MariaDB.
The NoSQL database is an instance of MongoDB. I chose a NoSQL database because I wanted the transformed output of a tunnel to be searchable using the API of Data Blade and because of the schemaless nature of MongoDB. This makes MongoDB a great choice to store the transformed output and provide fast access to the data.
In the next post I’ll do a deeper dive into the core of Data Blade and how all these components string together.