Daniel Gent

When I started at Sesamy, there was only a Shopify store for single purchases of our vendor's digital products. This had a few issues: the Shopify checkout required all the fields needed for a physical delivery, and we want to write our own backend as we scale up.

The solution I chose was to fork a Vercel eCommerce Next.js demo project. This project had basic Shopify connection functionality and allowed me to save a lot of development time - I had to do significant customization, but I didn't start from scratch.

As the lead Next.js developer, I explained and demonstrated the hot Next.js terminology to the rest of the company: SSR, SSG, and ISR.

Using Next.js also improved SEO ranking by achieving an 80+ ranking in Google's page speed insights.

This also allowed us to migrate to our back end incrementally by creating adapters, allowing the site to display products from multiple data sources.

The end result to the customer? A seamless transition (with speed improvements!)

Recently, I moved our Next.js login forms over to server-rendered JSX on Cloudflare workers, a very modern stack!

We had our login pages on a Next.js app on a third-party domain. Logging in using a third-party domain and client-side JavaScript has many issues.

I could mitigate all these issues by rendering HTML directly from our auth system (running on Cloudflare workers). Hono runs on this and supports JSX, so I could "almost" copy-paste JSX from Next.js to Hono.

The end result was no change to the user flow.

Having the most testing experience at my startup, I took the lead on setting up Playwright tests for our multiple Next.js projects. I set up GitHub Actions against Vercel preview deploys on each commit and daily on a cron job (results posted to Slack). This gave us more confidence and allowed other developers to write their Playwright tests. I frequently helped the other developers fix their broken tests (the broken window theory is fundamental!).

On an influencer marketing platform, there were several legacy multistep forms. These were built in PHP and jQuery. The code was very brittle and hard to reason about (large event handlers, many ways of changing state); as such, it was challenging to add new features without introducing bugs.

I was tasked with migrating to React. This involved reverse-engineering the existing functionality to work with existing APIs and cloning existing functionality to React. I recreated our existing text editor using Draft.js, used Airbnb's React dates to mimic a calendar input, created a similar tag input, and so on. The result was functionality identical to the previous (meaning no retraining for staff), but afterward, we had full code coverage and could confidently implement new business requirements.

This was a massive benefit of using React. It was declarative and functional and also blisteringly fast.

On a rental web app aimed at luxury homes, there were performance problems on the listing page. Due to infinite scrolling, there were many React components, and the page was slow, especially on mobile devices.

My task was to improve the page's performance. I used the latest React tooling to identify issues and rectify them. React recently incorporated flame graphs into Chrome's profiling, allowing me to identify unnecessary re-renders, fix them, and create before-and-after reports to show to stakeholders.

When I started at Whalar, we were still using Enzyme, the standard in React testing in 2018. This was then superseded by the React Testing Library, which fundamentally differs in its approach to testing. Enzyme focuses on unit tests, and RTL focuses on integration testing and testing like a real user.

We took the plunge after we had a few severe production bugs that would have been detected with integration testing. I was tasked with the initial migration of our most essential components. I picked the areas where we'd had the most bugs (the most modules interacting) and then wrote different tests: extensive and long happy path tests and more detailed edge case testing. There were definite trade-offs regarding the test speed and reliability (much slower and much flakier), but I mitigated this by pushing for a move to AWS's CodeBuild CI/CD.

In the end, we had much more code confidence and much less severe and obvious production bugs.