An simple implementation for trip data querying & reporting use case
Prerequisite: Node LTS
-
Create a
.envfile with content:PORT=3000 TOKEN_USER=user TOKEN_PASS=pass JWT_SECRET=an-extremely-secret-string MONGO_URI=mongodb+srv://user9281:[email protected]/case MONGO_DB_NAME=case LOGGER_NAME=default
-
Install dependencies and run the project:
$ npm i
$ npm run dev- The application should be up on
http://localhost:3000now.
Check running on cloud for a more straightforward procedure.
Unlike local version above, this is easy as pie: Create a new release on the GitHub repository, and build & deployment processes will be triggered as a GitHub action right away.
AFAIK, the term dependency rule, was coined by Robert C. Martin in the book Clean Architecture. So, the outer layers (e.g. app) may depend on inner ones (e.g. domain), but not vice versa.
Although ES6 has class structure, it does not have Java-like interfaces. At this point TypeScript interfaces are here to rescue: We can make an ES6 class extend a TypeScript interface implementing the methods declared. Examples of this approach in this project can be observed at service.ts and repository.ts.
I used official MongoDB Node Driver to keep it simple. In cases which generating DB models seriously make sense Mongoose can be deemed.
The document states that TypeScript's type and interface can be used interchangeably: except the fact that type is not open for extension. So, I used interface where extensibility was needed or things were rather vague and type when thought that definition would not be inherited by any means.
Most of the use cases here require complex queries: at least two coordinate values, plus some optional arguments. So, a GraphQL endpoint which the query is sent in request body could be a fit. However, for simplicity, I stuck with REST.
I intended to put some spec (like tsoa), but it started getting cumbersome for a simple project. I guess I won't bring it into the game despite it is enlisted in the requirements 🤷
Instead, I am planning to hand a Postman collection of sample requests out.
One of my favorite 12-Factor Apps items promote externalized configurations (even dotenv library does so. So, I did not commit .env as the config base for the containerized mode. Instead, I made use of my AWS ECS task definition file since it is also a legit solution.
A monolith is not always evil, indeed it enhances time to market for smaller, one-man applications by eliminating the network concerns, separate configurations and deployments etc. That's why I dared to deny Single Responsibility Principle (at application level) and used a single deployable with authentication logic embedded.