[Achievement] Job Site DynamoDB Design & Backend Development

Overview

In this article, we introduce a contract development achievement regarding DynamoDB design and implementation for the backend development of a job site. In particular, we evaluate whether DynamoDB is appropriate as the DB for this project and explain the reason why we finally adopted PostgreSQL.

Background and Request

■ Target: New release project for a job site
■ New/Existing: New project
■ Client: Freelance Frontend Engineer
■ Situation: Frontend implementation was mostly complete. Backend development was outsourced but incomplete, and implemented in PostgreSQL instead of DynamoDB as specified by the customer.
■ Request: Fix backend code with DynamoDB & enable local environment / proper deployment

After carefully listening to the request, we could not judge whether selecting DynamoDB as the DB was appropriate until we saw the source code, so we proposed the following:

Create DynamoDB design draft
- → Interviewed use cases and created a design draft
Explain and decide whether DynamoDB or current PostgreSQL is appropriate
- → Explained that PostgreSQL is appropriate for the reasons described below and obtained agreement
Propose whether to rewrite backend code to DynamoDB or make it work with current PostgreSQL
- → Selected current PostgreSQL. Fixed code & implemented CD with GitHub Actions in local environment.

Use Case Hearing and DynamoDB Design

Use Case Hearing:
We interviewed specific use cases for the job site, and the following requirements became clear:
- Job list display (no filter)
  - Pagination to arbitrary page required
- Display of 1 job
- Job search
  - Filtering by Item 1 (multiple selection) x Item 2 (multiple selection) is mandatory
  - Pagination to arbitrary page required
DynamoDB Design:
Based on the use cases, we carried out DynamoDB table design and index design.

DynamoDB Suitability Evaluation

DynamoDB is designed to achieve high-speed reading and writing as a NoSQL database, but it became clear that it is not suitable for the use cases of the job site in the following points.

Filtering by multiple items x multiple items:
Since DynamoDB is not designed to efficiently perform filtering by multiple items x multiple items, query performance may decrease.
Arbitrary Pagination:
In DynamoDB, it is often difficult to implement arbitrary pagination, and it is particularly inappropriate for large datasets.

Conclusion and Adopted Approach

Based on the above evaluation results, we reached the following conclusion.

Continue using current PostgreSQL:
Based on the use cases of the job site, we proposed continuing to use the current PostgreSQL instead of DynamoDB, and obtained agreement. PostgreSQL is optimal for the requirements of the job site because it ensures data consistency and can efficiently execute complex queries, filtering, and pagination.

Backend Code Fix and Deployment

Code Fix:
We fixed the current backend code to work with PostgreSQL. We also fixed defects in the code for inserting initial DB data. Since we heard that essential files for operation such as .env files were not received from the outsourcee, we created them from the existing code.
AWS Environment and GitHub Actions Settings:
We configured GitHub Actions in the AWS environment to automatically deploy when code is changed. Following the existing Serverless Framework, we made it possible to deploy for each environment.

Results

Efficient Deployment:
By using GitHub Actions, we established a mechanism to automatically deploy when code changes, improving development efficiency.
Stable Operation:
By continuing to use the current PostgreSQL, we ensured data consistency and query performance, realizing stable operation of the job site.

Through this contract development, we demonstrated the importance of understanding the difference between DynamoDB and RDB and selecting the optimal database for project requirements.

If you are facing similar challenges in your project, please feel free to contact us.