The core requirements for an API are pretty standard here, and listed as follows:
Keep in mind, the point of the project is to implement all API calls in both Java and Node stacks in order to illustrate the common concepts and how they are applied to each stack.
API instances are intended to be deployed onto a cloud environment. For scaleability purposes, we will be supporting the ability to
Authentication will be minimally addressed in this project. For most most part we are just conceearned with the presence of a header with an auth token which just establishes the fact the user has completed some prior authentication step, and allows us to pull up user details and permissions. The core concept here is that checks are performed in a central location, and applying to all incomming requests prior to servicing the requests.
1Sample source code....1Sample source code....In a similar manner to the approach for authentication, we also centralize exception handling. The goal is to not only standarding exception reporting in the respone payloads, but also to provide for exception reporting to a third party application for more enhanced alerting. From a Node perspective, this is applied via middleware. As for the Spring implementation, we make use of the @ControllerAdvice annotation, however the concept is similar across both stacks.
1Sample source code....1Sample source code....From a Java perspective, we will be working with the Log4j framework, fairly standard stuff. From a Node perspective, there are a few more options, however winston appears to lead the pack, it is what I have used in the path, so it seemed like a natural fit.
In both cases, I will be wrapping each of the libraries into wrappers. The idea here is to support the ability to pass a transaction id along with all messages so all events may be correlated with the same unique transaction id.
In addition to standard logging operations, support for logging and structuring certain log related information for certain calculations for auditing purposes. I had previously shared an article on this approach which can be located at: https://www.matthewdalby.dev/articles/software-engineering/business-process-auditing
For the Java stack I will be using the Spring framework, specifically Spring Boot, which is almost a defacto standard. In the Node ecosystem I will be using the Express framework. Widely supported, and more than capable of meeting the requirements for this effort.
For the Spring based stack, we will be using JPA (Java Persistace API). This is an formal API specification. The API provides an impressive set of functionality.
From a Node perspective, things become a bit more complicated. Unlike the walled garded in a Spring stack, there are a few more options from which Sequelize and TypeORM. I ultimated decided on this implementation to select TypeORM. Given the fact that it is typescript based, and supports the use of decorators for defining mapping rules, it seemed like the natural choice. I am a big fan of annotations/decorators and am exited to see them finally beging to materialize in the Javaascript ecosystem.
In both cases we will &pos;mostly' be working with the data via the ORM layer, however we will be making exceptions in cases where applying performance operations make sense.
In both stacks we will be using the same messaging solution, which is RabbitMQ. I decided to use this as I have worked with it in the past, and have no strong requirement to use another package. AmazonMQ is another potential option, that would makes sense since we are deploying to an AWS environment. In either case, the application will be architected in such a manner that it is decoupled from the actual messaging implementation.
1Sample source code....1Sample source code....For all API interactions, I will be performing the calls via the Tankstack useQuery hook. I am a big fan of this approach, and have shared an previous article on this approach (Performing API calls with Tanstack).
After carefull review of options, I decided to implement an CSS framework in place of hand rolling the entire effort.
State management was an interesting decision point. I have worked with Redux on many projects in the past. Due to the fact we are using the Tanstack approach to retrieving data, I am taking a different approach towards persisting data as the library has it&s own global store for caching purposes.