Keeping in mind that we are creating dual implementations for the API components, this doubles the projects related to the API backend. The projects will be as follows.
We can see some similarities between the two stacks, most noticably the concept of packages in the Java implementation. In both cases, there is the concept of tiers (controller, service, and persistence). Source code is organized into folders accordingly. This is a default practice for ‘smaller‘ projects, whereas as a codebase grows you might find yourself beggining to break controllers/services/entities into functional named subfolders.
An alternate approach is to organize functions into more of a structure where code is placed into feature specific folders, whereas for example, given an ‘Customer‘ entity , a customer folder would be created, and all controller, router/controller, and associated logic would be packaged under the same folder.
This is a highly opinionated topic, with pros and cons for each approach. I would not even attempt to make a strong opinion here. It really boils down to your own opinion, and needs for your specific team and project. I am defaulting to this one approach. This may not be the best fit for every scenario.
I love working on new projects (most of us probably do), however this involves a lot of boilerplate work, which is necessary however redundant. I have typically use code generation techniques for various projects to streamline these types of tasks, and will be using one on this project.
A very common operation is where an entity is created, an API is required to support operations against it, logic to hydrate/persist the entity, and perhaps code related to a service tier. That gets old pretty quick so automating as much as possible adds value.
I believe it is especially important to establish a build environment as quickly as possible. It is pretty common place to establish a build pipeline, but not necessarily a safe assumption, I have seen cases where deployments were performed directly from a developers laptop.
I am a firm believer in testing from day one. Usually one the first tasks I attempt is to execute a small test case to support functionality as a flight check. This is also a required task as we are planning on establishing unit level tests at deployment build time. For Java we will be using JUnit, and for React Jest.
The associated source code is publicly available on GitHub with the following links. All projects may be located at the following location.