This is part 3 of the Pet Project series about building a small web application from scratch.
The road so far
Check the other posts to see where we are coming from:
After some time off and handling some other responsibilities, here is a new post on building a small web application from scratch. With this update we went pretty far on the implementation road, and we are now one step closer to having a functional backend. Just as a reminder, the application we are building is a shopping list application with the help of which the user can manage their shopping experience by keeping track shopping lists and their items.
This is what we have achieved with this iteration:
Endpoints for handling items and shopping lists
Following endpoints are now available(textual description):
- create an item
- get the items, either all of them, or by name
- create a shopping list
- get the shopping lists, either all of them, or by name
- get items belonging to a shopping lists
- add item to a shopping list
Embedded H2 database
To store the application’s data we use for now an embedded H2 database, configured to save its files on the file system (see
H2 compliant script
schema.sql, is a script which is executed when the app starts and creates the database objects required by the application (a complete wipe takes place beforehand).
Not so dummy data
To populate the database with real-life data we use a
CommandLineRunner bean, which reads a
.csv file and inserts the data into the database.
requests.sh is a test script, which depicts a real life scenario.
I actually used the IntelliJ feature Generate HTTP Request to generate the requests and then I packed them all in an executable file.
Java 11 support
The project uses now Java 11 (keeping up with the Java LTS versions).
Technical implementation aspects
I tried to keep things as simple as possible and to follow good software development practices.
NOTE: This is a work in progress and things will definitely change.
That being said, here is a summary of the development experience and status quo.
I went with a slightly different version of package by feature approach for organizing the code. With this approach we have two packages, which bring the attention to the domain of the application. Each package contains everything related to the feature in question. The Domain comprises currently items and shopping lists.
The constituents of each feature package follow a layered architecture. This dictates that one layer should only communicate with the layer directly below it. In this case we have something similar to the following diagram:
Enums to group different related values under the same name, Data Transfer Objects (DTOs) to move data between boundaries,
Mapstruct to convert one object into another, Lombok to get rid of that annoying boilerplate code, validation using
javax.validation.* to insure
data validity, Jackson to easily process JSON data. As I am using Spring Framework and Spring Boot, a huge part of the heavy lifting is done by the framework,
which includes dependency injection, database access and so on.
The diagram below depicts a part of the model:
You will be seeing more of this kind of diagrams as the project advances (I created them using PlantUML and a plugin for IntelliJ and exporting them as .svg). Think of them as diagram as code, which means, one writes some special code, which is then transformed into a .svg or image of even .pdf, code which can be versioned.
Another interesting thing was how to take a peek inside the embedded H2 database from the terminal. Please note that the database has to be shut down in order to connect to it, we are basically having a look into the database file, which is locked as long as H2 is running.
java -cp <path-to-h2-jar> org.h2.tools.Shell \ -url "<h2-connection-string>;ifexists=true" \ -user "<user>" \ -password "<password>"
<path-to-h2-jar>is something like
/home/vlad/.m2/repository/com/h2database/h2/1.4.200/h2-1.4.200.jar, in my case I am using maven
<password>is the information to connect to the H2 database, usually found in the
After connecting to the database we can query it by running commands like:
show tables; select * from item;
This post is more of a status report, and a bird’s-eye view of the current project iteration. We are now at the point where we could start building a fancier kind of client, other than some .sh scripts, and send requests to the backend to create and get items and shopping lists. As necessary, the business logic will change to make room to other features as I discover them from my own shopping experience. There is still a lot of work ahead - new client, a more stable backend, CI/CD process, Infrastructure etc., so stay tuned for the next update.
The current state of the project is available on GitHub.
Take care and ‘til next time!