A comprehensive REST API.
I have defined three models: bookings, users, and workplaces. Booking is used whenever a workspace is available for commuters to work off of. Thus, because a lot of consultants are working from home, they can essentially let their manager or superior know where they will be traveling to before getting there. Data generated here could be leveraged in the future, for example, to measure how many sites have a more flexible culture as far as allowing employees to work in a hybrid fashion. Users serve as a control parameter and for a rudimentary authentication protocol. Essentially, any user could sign in using their internal IBM address (namely W3 credentials). However, not everyone should be able to add a new workplace - this should be reserved for managers. Since every user entry onto the database gets assigned a unique ID, later data findings could be proven useful for metrics of the IBM population that adopted this commuter style, since there are employee-driven programs already in place that focus on a more flexible approach when it comes to working at the office (IBM Consulting Flex). Lastly, there is workspaces, which is the most essential part of this API. Perhaps this could be later made available for both internal and external use, once the data has been processed. With the advent of programs such as IBM Consulting Flex, these types of APIs could leverage the use of internal applications and processes for a better employee experience by streamlining the process of presential work. In Slack, there is almost a daily thread of employees asking whether their employee badges will function as expected when it comes to accessing different offices across North America.
While briefly touching on the topic of design patterns, a monolithic repository approach is what allowed me to deploy the same application using two different platforms for both the back and frontend. With scalability in mind, I decided to use a NoSQL database to store the different office locations, as well as other fields that could potentially be generated and analyzed in the future (e.g. branch specialty, pricing, and who added what).
Clone the project
Go to the project directory
cd air-ibmInstall dependencies
npm installSpin up a noSQL database (I've used MongoDB Atlas free tier for demoing purposes)
touch .env# MongoDB Atlas
MONGO_URI=mongodb+srv://<username>:<password>@airibm.gldqv.mongodb.net/<databse-name>?retryWrites=true&w=majority
# Node.js Routing
PORT=8080Start the server
npm start
A more in-depth wirte-up on end-to-end tests, and testing-driven DEVELOPMENT in general.
- Unit tests: usually used to test a given compononent in an isolated envinrement.
- Integration tests: usually used to test more than one component and how they interacted within the stack once those are running.
- End-to-End: programmatically simulates end user behavior. Usually has its own testing/mock database - which is what we've done during the scope of this project. See prisma-test-enviroment.ts for more details.
- In this instance, I've used a SQL database for testing purposes to simulate a real world scenario where there's a need to for not only testing suite, but also distinct databases; one for testing, one for production. For this example, and according to the pattern called Command/Query Segregation, CreateCleint.spec.ts isn't returning anything since it's a WRITE/UPDATE/DELETE command as opposed to a query where the expected behavior would be to return something. See IBM's Architecture Center article for more information on CQRS.
- Prisma, Jest, TypeScript, SWC/core and SWC/Jest, among others.
Clone the project
git clone https://github.com/carlosblanc0/ibm-tddGo to the project directory
cd tdd-e2eInstall dependencies
npm install Start the server
npm run startSpin up a PostgreeSQL database (I've used https://cockroachlabs.cloud/. Make sure to pick the free tier for demoing purposes)
touch .env# Environment variables declared in this file are automatically made available to Prisma.
# See the documentation for more detail: https://pris.ly/d/prisma-schema#accessing-environment-variables-from-the-schema
# Prisma supports the native connection string format for PostgreSQL, MySQL, SQLite, SQL Server, MongoDB and CockroachDB (Preview).
# See the documentation for all the connection string options: https://pris.ly/d/connection-strings
DATABASE_URL="`postgresql://${dbUser}:${dbPass}@${dbHost}:${dbPort}/${dbName}?schema=${this.schema}`;"