Sample REST API Project

Update note: Because of recent workload and shifting priorities, I wasn't able to carry this series forward the way I'd planned. Since then, though, I've built plenty of new full-stack projects using AI-assisted workflows. These days I write here often about the architectures of those newer projects, modern software practices, and my experiences building with AI. Even though this particular series was left unfinished, I'd strongly encourage you to follow the current technical posts and the newer project architectures on the blog. And if you have questions, you can always reach me through my social media accounts. :)

💡 TL;DR:

• What the series is about: An archival, end-to-end walkthrough that plans how to build a supermarket-focused price search engine (web, admin panel, and API) on a from-scratch infrastructure running on a DigitalOcean VPS.
• Technologies used: PHP (Slim Framework / Laravel / Lumen), Vue.js, Tailwind CSS, Docker, Redis, RabbitMQ, and Monolog.
• Status: Although the series was left unfinished due to my workload in 2021–2022, the general API architecture, logging design, and asynchronous queue plans laid out here still hold up as a current full-stack roadmap.

My blog is relatively new, but it already covers plenty of topics across frontend, backend, and DevOps. Now it's time to set the introductory posts aside and actually start doing. :)

I'm going to bring to life a project that has been on the shelf for a long time. I figure writing about it here will be a real push for me, too. I'll start the project completely from scratch and document every step right here. In fact, I won't even use my existing server on AWS — I'll spin up a separate server on DigitalOcean just for this.

What Am I Going to Build?

The project I have in mind has three parts: a RESTful API backend that serves mobile and web clients, an "admin" panel I can use to manage everything, and the frontend interface that opens the project up to the world. A complete full-stack project, in other words. The mobile side will only begin once all of this is finished, so it won't be part of this series. Mobile isn't my area of expertise anyway, so I can hand that part off to someone else. :)

At its core, the project is a price search engine. Unlike comparable services such as Cimri and Akakçe, it will focus only on supermarket products: it'll show how much a product or a basket of products costs at which market, along with its price history.

What Am I Going to Share?

The project's business logic — the actual brains of it — won't appear here directly. What I will explain in detail is a general-purpose API skeleton you could use in this or any other project: what each piece does, and how you can extend it. Beyond that, I'll share parts of the project here and there — for example, how I solved the caching problem, how I got the web interface to talk to the API, and how I used queue management. By explaining what I did, how, and why, I hope to give you ideas you can apply to the needs of your own projects.

What's in the Project?

VPS Server

We'll start by setting up a VPS server. If you prefer, you can work locally on your own machine without one. I'll go with a VPS both to build a cloud development environment and to see how the things I build actually perform on a cloud server.

I already have a VPS on AWS, but I bought a separate one on DigitalOcean for this project. If you go through my referral link, DigitalOcean gives you $100 in credit valid for 60 days. A $10 server is enough for my setup, but with that credit you could go for a bigger one.

PHP Framework

As I mentioned, this project has been on the shelf for a long time, so I already had an API skeleton I'd built with PhalconPHP and had moved on to the management side. Since the PhalconPHP extension is going to lose its "runs as an extension" advantage in future versions, I decided to throw that work out and rewrite it from scratch with a new framework.

For that, I did a lot of research into Yii, Slim, and Laravel. Laravel is a framework I poked at and liked back when it first came out, but I hadn't used it since. I'd never used the other two — so you could say I was starting all three from scratch. From that angle, none of them gave me a head start.

That said, in my research into Laravel (and Laravel's micro framework, Lumen), both the articles written on the subject and the benchmark results showed it to be very hungry in terms of resource usage. As much as I wanted to use Laravel for its strong ecosystem and developer-friendly design, the performance question gave me serious pause.

Later, when I saw that Laravel and Lumen's performance climbs considerably with a Swoole server (and even then they only just about close in on the others), I decided to start with Lumen, lean on Swoole when needed, and — if it still became unmanageable even then — rewrite the code from scratch in another framework (maybe even another language). So I decided to go with Lumen and Laravel.

Correction: Despite the decision above, starting with Lumen didn't sit right with me, so I started with SLIM instead. I'm building a nice API skeleton with it. Once it reaches a certain stage, I'll push it to GitHub and start the step-by-step write-ups.

API Design, Documentation, and Testing

I haven't done the project analysis yet, I don't know the API's requirements, and I'm not sure whether I'll get into the analysis side in this series. But for API design, documentation, and testing I'll use the Swagger platform, and I'll publish what I do both during setup and in everyday use. Even though I've used Swagger before and have a solid technical grasp of it, learning the details of the OpenAPI specification will be a good opportunity for me too.

Frontend Elements

There's no need to write things out as HTML, CSS, JavaScript, and so on, but on the frontend this will be a project where I use Vue.js and Tailwind CSS. I may not go very deep into Tailwind CSS on the admin panel, but on the web interface I should use it both more effectively and more efficiently — looking good while taking up little space.

Container System and Additional Services

I'll build my development environment on Docker containers. I don't know whether my Laravel/Slim experience will shape this differently, but alongside MariaDB I may add Redis and RabbitMQ to the project. In the project I did with PhalconPHP, I used a generational caching approach for caching, with APC and Redis as the cache engines. We'll see where Laravel/Slim takes me.

Logging

Logging is both the simplest and the most complex part of this whole thing. Logs need to be collected from many sources, and it all has to be designed to work in a distributed system, too. It's a given that file-system-based logging won't be healthy. And since this isn't really what databases are for either, we should use a professional logging solution. I know I'll use Monolog as the PHP library, but beyond the theory I have no real experience with how to solve the server side. We'll work through that part together as well.

CLI

Finally, I need to gather data from some external (online) sources and integrate it into my own database (that's the whole idea behind the project). Since the sources I'll be collecting from — Instagram, Facebook, and the like — aren't stingy about sharing data, I can solve this with a simple Python or PHP CLI script. Even though it's not directly project code, I may share posts explaining how data collection is done.

Planned Project Tech Stack

Code Name: Full Stack

This series may run to dozens of posts, and I'll tag them all with the Full Stack tag so they're easy to find. I hope these posts are useful both for me and for anyone who wants to learn something about these topics.

I keep the series' table of contents in a separate post that links out to all the other articles in the series.

Edits Made to This Post

• 2022-05-11: Article summary revised.
• 2026-06-21: Typos fixed; the update note revised to point to modern AI-assisted projects; TL;DR summary and tech-stack table added.