Dev Portfolio

DEVELOPMENT PORTFOLIO

The Unending Journey James Song Development Portfolio Last Updated — 2023. 12. 31.

TABLE OF CONTENTS

TABLE OF CONTENTS

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - Greetings!

Frontends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Xometry: Partner & Sta Capability Frontends - EAN Technology: ZECO

Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - Xometry: Email Lambdas and Pipelines - EAN Technology: DynamoDB with GraphQL

System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - EAN Technology: Architecting a Building Energy Management System (BEMS)

Afterword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - There’s a person behind every feature - What’s Next?

ff

2

FOREWORD

FOREWORD Greetings!

Name’s James - and if you’re reading this, chances are you’re probably reviewing my resume for one or more reasons! I really appreciate your time and effort in doing that. I know it’s probably not the most exciting part of your day, so I tried to make it a little more interesting than it otherwise would be. I hope I can succeed in putting a smile on your face—and none of this is written using ChatGPT! (No, really. Trust me!)

A bit about myself.

I was born on October 20, 1998 in Seoul, South Korea. I rst stepped foot in the United States around 2008 at the ripe age of ten and became a US Citizen around 2017—just after I graduated from high school.

Though I majored in neuroscience while I was a student at Boston University, I quickly fell in love with computational neuroscience and promptly discovered my passion for software engineering.

After some months of self-study and side projects, I became a junior software engineer at Xometry creating frontends UIs and backend APIs for the world’s largest 3D manufactured parts marketplace. Then, I moved to Korea for a bit to rediscover my roots, all while having a blast building cloud native systems for building management working for EAN Technology (yep, my English and Korean are both native.) Now armed with two years of experience working with React, NextJS, Express, Fastify and the awesomeness AWS has to offer, I’m seeking new adventures with a group of passionate folks building stu that will change the world (bonus points if that involves me using Kubernetes!)

In my spare time, I play tennis, take photos of birds with polaroid cameras, play chess, build wooden models of ships, and read Haruki Murakami. Yes, there’s more, but that’s probably enough… I think.

My Tools of the Trade.

I’m primarily a Typescript dev with a pronounced interest in writing highly scalable, readable, and reusable code. I feel right at home with React-based frameworks, state management libraries, PostgreSQL, GraphQL, Linux-based networking, HTTP protocols, and most importantly, containerized system design. I’ve also picked up Rust fairly recently, dedicating an hour every day to learning the language.

Beyond being an individual contributor, I also strive heavily to ensure that my contributions function smoothly and responsibly as part of a larger distributed system. Methods such as multistage docker builds, rolling deployments and GitHub Actions are all within a day’s responsibility for me.

fi

ff

3

FRONTENDS

FRONTENDS [Xometry] Sta and Partner Capability Frontends Overview During my time at Xometry, our most signi cant initiative was “ful ll everything” - to, ful ll all of the orders placed by our customers by matching them to our outsourced partners. As part of this initiative and as part of marketplace services, the ful llment squad started creating an entirely new experience named Workcenter.

In this context, I delivered signi cant contributions to both the Partner Capability Frontend (“PCF”) and Staff Partner Capability Frontend (“SPCF”), which 1) showed manufacturers the capabilities they were “approved” for, meaning certi ed by Xometry as being able to produce said part, 2) allowed manufacturers to apply for any new capabilities, and 3) allowed Xometry staff to revoke existing approved capabilities.

Outcomes A fully dynamic frontend allowing for end users (partners, customers and xometry staff) was developed.

Major features include: • API-based fuzzy search with dropdowns, and paginations.

• Dynamically rendering tables.

• Tab-based sorting • Ability to submit / revoke applications.

From top left, clockwise: 1) main page, 2) remove dialogue, 3) fuzzy search, 4) selected option displayed under search bar

fi

fi

fi

fi

fi

fi

ff

4

FRONTENDS

[EAN Technology] ZECO Frontends Overview At the heart of every software lies a desire to automate and abstract tedious tasks into meaningful interactions and ef cient commands. ZECO embodies that tenet by providing its end users the ability to assess the environmental friendliness of buildings even before they’ve built. Traditionally, getting “green certi ed” used to be a very laborious task with hundreds of calculations and paperwork involved—with ZECO, users can see whether they meet the criteria de ned by the Korean Environmental Protection Agency with just a few clicks.

Outcomes A fully dynamic frontend allowing for end users (architects and construction planners) to assess the feasibility of being “green certi ed” was created. Major features include: • A fully dynamic, resizable sidebar.

• Table and tab-based sorting.

• Lightning fast search provided by AWS Elasticsearch.

• Cookie-based login scheme with key pairs in environment variables.

• Dynamically rendering graphs and metrics on a per-entry basis.

fi

fi

fi

fi

5

BACKENDS

BACKENDS [Xometry] Email Lambdas

Top: An architecture diagram documenting the relationship of various services in this rearchitecture project.

Overview I contributed to the architectural designs and implementations of an AWS-based email system listening to multiple trigger types (perhaps due to a piece of code that was triggered as a result of a customer order) and enacting an email payload.

Outcomes I implemented an email service using AWS lambda handlers as well as a AWS SNS//SQS event queue.

• In the original architecture, a Python backend that read HTML email templates executed a bash script / Linux Cron Job which periodically sent batches of emails.

• This was suf cient for a limited number of emails, but as the types and of emails and their respective traf c increased, scaling and elasticity issues quickly became evident.

• To assuage these issues and to also provide better observability, a separate service dedicated solely to emails was created. Said service triggered a lambda function whenever a speci c business requirement was met (such as a customer placing an order), which in turn sent an email powered by Sendgrid.

• Over 2M users were detected to be using the email service with minimal errors detected.

fi

fi

fi

6

BACKENDS

Top: A datadog screencap of the job offered email handler user metrics.

The email lambda scored over 2M hits (!!!) as of June 16 2022, and has proven to be both error-resistant and responsive even under high loads.

Top: A datadog screencap of the job offered email handler overview.

This speci cally shows user metrics for email handlers which are triggered when we send out job offers to our wonderful customers.

fi

7

BACKENDS

[EAN Technology] DynamoDB with GraphQL Overview I architected and implemented a noSQL (DynamoDB) database from the ground up to support an independent frontend application hosted using AWS ECS. I then developed a eet of Express APIs using prepared graphQL Queries to access said database using AWS SDKs for JavaScript.

Top: An architecture diagram documenting the relationship of various services in this rearchitecture project.

Outcomes A fully stateless backend API was deployed for production use.

• Only prepared queries with sanitized inputs were used to guard against database injection attacks.

• Custom middlewares (express.json, cognito authentication, rate limiting, etc) were implemented for shared logic between each route handler.

• Average query latency is shown to be on the scale of several milliseconds!

• A custom API documentation site powered by Redocly was created.

Top: A redocly site detailing API speci cations. Also includes a search feature and sample requests / responses.

fl

fi

8

BACKENDS

Top to Bottom: AWS metrics demonstrating backend query latency against DynamoDB.

9

SYSTEM DESIGN

SYSTEM DESIGN [EAN Technology] Architecting a Building Energy Management System (BEMS) Overview Samsung C&T (henceforth “Samsung”), a subsidiary of Samsung Electronics, commissioned EAN Technology to create a highly scalable, elastic building management system (BEMS) for its headquarters. Primarily, BEMS would monitor various environmental metrics measured within the HQ itself such as temperature and CO2 as well as energy usage metrics such as electricity, and gas consumption. Furthermore, Samsung desired a way to gain datadriven insights such as excess energy wastes and future energy demand predictions based on their current energy consumption.

To meet these business requirements, a BEMS task force was created within EAN Technology. I served as the Principal Full-Stack Engineer responsible for systems architecture and project delivery, while Younghyun Ji served as the lead backend engineer responsible for feature development.

Initial Assessment While at the drawing board, I rst met with the product owner (PO) to identify the key requirements of the project and to create a bare-bones analysis of the data ow. During our initial meetings, my most important questions were as follows: • Where is the data coming from, and where is it going?

• How is the data being provided?

• How is the data being consumed?

• What are the scalability and elasticity requirements of the overall system?

• Is the expected traf c normalized or sporadic?

• What parts of the system are considered mission-critical?

• What observability metrics should be gauged to assess the readiness of the system?

System Architecture Based on the above day-one meetings, I arrived at an initial bare-bones blueprint which looked something like this:

fl

fi

fi

10

SYSTEM DESIGN

Top: A rst draft of the BEMS system architecture.

While iterating on this rst draft to accommodate the scalability and elasticity requirements Samsung desired, some new and more detailed requirements presented themselves: 1. All of the data would be provided from physical sensors located inside Samsung HQ every 15 minutes.

1. There are hundreds of thousands of sensors per oor, with 10K+ sensors across the entire building.

2. The data science team desires real-time access to the data being collected to re ne and train their AI models. Ultimately, Sagemaker or Kube ow on EKS should have access to the raw data.

3. The backend APIs the servers expose will be queried once every 15 minutes by a separate frontend created by another company to refresh and access the data.

4. All of the API routes need an authentication scheme to guard against unwanted access.

5. The incoming data needs to be validated (not assessed for irregularity—the scope of this validation scheme is limited to whether the data is actually being collected or not.)

These requirements, with expert advice from Mr. Younghyun Ji, led us to a more re ned architecture:

fi

fi

fl

fl

fi

fi

11

SYSTEM DESIGN

Top: A nal draft of the BEMS system architecture.

(Note: The above is also viewable in snazzy 3D at https://app.cloudcraft.co/view/434edcd8-499b-4cdb-b4fdaa448104db2b?key=85a13115-1860-4496-8742-49ae448af2b0 — go and check it out!)

While this architecture wasn’t foolproof, it also addressed most business requirements - old and new.

1. “Hundreds of thousands of sensors” translates to dense traf c. However, “every 15 minutes” translates to periodic, predictable traf c. Thus, Fargate autoscaling capabilities mixed in with Fargate spot instances at a low ratio should provide the scalability needed while sacri cing some elasticity for a cost bene t.

2. Since a Postgres database is being used, I decided to roll two schemas - a production schema and a schema just for the data science team. Incoming data will be written to both schemas simultaneously, 3. An application load balancer should be suf cient to accommodate for routing logic and authentication schemes. It can also rate limit malicious requests though that doesn’t seem to be necessary here.

4. A network load balancer would be able to provide a xed IP to ingest incoming data.

5. A periodic cron job against current database entries to see if a large number of consecutive requests are returning “bad values” (0, null, unde ned etc) should be suf cient to detect any high-level anomalies.

fi

fi

fi

fi

fi

fi

fi

fi

fi

12

SYSTEM DESIGN

A Lesson in Tradeo s Every system has its tradeoffs—but that’s what makes architecture fun. BEMS was no exception.

1. Tradeoff: Do we need a service mesh?

• Fundamentally, I advocate for a single-service, single-database architecture. As in, each microservice should own its own database, with no (or as few as possible) database being coupled to multiple microservices. This not only ensures that the database can scale with the microservice, but also allows for each microservice to use a different kind of database (SQL vs. noSQL).

Due to budgetary constraints, a database-per-service model wasn’t considered to be feasible. Hence, we instead ensured that each service was only coupled to one table in the shared database. As such, interservice communications weren’t initially necessary—but as coarse-grained features with layered functionality becomes necessary, a service mesh (App Mesh for AWS) may indeed be necessary.

2. Tradeoff: Do we need a message queue?

• As the system will have an in ux of different types of data hitting a single VPC endpoint, I felt it would serve us well to use a SNS//SQS or Apache Kafka to logically sort those data and pair them with their end consumers (most likely microservices or lambdas writing to databases.)

However, it was actually decided that all of the incoming data would be provided in a much more uni ed fashion with each data category having a unique HTTP API header as part of its POST request. Therefore, we instead opted to front the entire ETL pipeline with a Data Collection Microservice written in Rust, with concurrent operations writing to the backend database. When and If the data complexity became too excessive, the Rust microservice could easily publish an event to a AWS SNS Topic instead using the Rust SDK. 3. Tradeoff: Can we sacri ce some system performance for cost optimization?

• S3 is much cheaper than RDS, but deserializing long and complex JSON les would increase latency.

I strongly considered establishing some date / time thresholds to extract old data from our RDS and store them in S3 or even S3 glacier. Because it would be criminally expensive to store tens of thousands of rows in Aurora Serverless, a Lambda function to periodically read from the database and drop the X oldest rows (and storing them in S3 / S3 glacier instead) could result in signi cant cost savings.

This idea is… on our back-burner. There just wasn’t enough manpower to get this done correctly while shipping new backend features to accommodate for all the incoming data.

fi

fi

fi

fl

fi

ff

13

AFTERWORD

AFTERWORD There’s a person behind every feature Déjà vu I’ve spent a year working in the states. I’ve spent a year working in Korea (with a visa designated for professionals - the E-7 visa.) Something I noticed across both cultures was that people are more productive when they’re happy. Generally, my teammates wrote the best code when they were well rested, and were given the autonomy to own and make architectural decisions. They thought more creatively when they were given autonomy and responsibility, regardless the size—and their growth became exponential when provided with the emotional and social support they needed.

Leading by Example As I was no longer a junior when I began working in Korea, I began mentoring and supporting juniors.

Something critical I found during my time at Xometry was the value of leading by action—most signi cantly, the senior engineers Aaron Johnson and Chris Morris would consciously spend their time reading books and studying new technologies as part of their regular workday routine. I brought the same habits and openmindedness when I came to Korea while advocating for a more equitable, transparent decision-making process—especially with regards to architectural decisions and coding standards.

What’s Next?

Kubernetes Kubernetes. Yep, I want to learn Kubernetes. I’ve already read Kubernetes: Up and Running and tried some basic sandboxes with miniKube, but I that’s no substitute for real experience. I want to work with Istio, Harbor, Karpenter, EKS, ArgoCD, Helm, Datadog… none of which I had a chance to work in production with due to budgetary (and organizational) constraints.

I get a blast out of seeing huge amounts of traf c being distributed well. I really do.

The Everlasting Horizons I want to learn more about how networking and DNS works. I want to learn more about how site reliability is conducted on a daily basis. But most importantly, I want to keep gaining experience building elastic, scalable systems resilient under even the most sporadic traf c spikes.

What matters to me the most as a full stack engineer is the ability to abstract complex business requirements into architectural designs, while also retaining the implementation skills necessary to quickly x any missioncritical bugs.

fi

fi

fi

fi

14