At my current company, moving to a GraphQL API proved to be challenging. What I didn't expect, is that one of the biggest challenge would come in the form of developer experience.
Namely - the watcher for our server.
Primarily because we kept getting
EADDRINUSE errors. We used GraphQL Yoga to develop our API. This combined with Prisma was a very smooth flow, but while developing the Yoga server, we ran into several developer experience issues.
Collectively, we preferred to have all of our queries, mutations and schemas in
.gql files. This was good as we could separate concerns and get proper linting. Now the issue was that to import these GraphQL files, we used a Babel plugin. We got the clean split that we wanted, but we hit another snag. Everytime we used to change the GraphQL files, we had to restart the server. Overcoming this was simple. We just used Nodemon and asked it to watch for changes to GraphQL files.
Nodemon was watching our
.gql files inside our
src folder. Developers, in general, use the save command liberally. What ends up happening is that you hit save after changing a single line, and hit save quickly after changing another. In between saves, while you server is restarting, Nodemon performs another restart. This ends up with your server trying to run on the same port again, and throws an
EADDRINUSE error. Sometimes, this stops the server altogether and the developer has to find the process and kill it manually.
I was trying to find ways to solve it, and realised that Chokidar inherently has a lot of rich event streams.
kill-port package to help me do port management between restarts. So now, I had something robust and simple, that started a child process, provided rich logging and managed process killing on start, restart and stop.
This proved to be very powerful as another problem we noticed was how Nodemon was consuming humongous amounts of CPU while watching and restarting our server. Switching to our implementation, the CPU load was non-existent and process management was smooth. The developers loved it!
I was inquisitive about Typescript but having seen and read Typescript code before, was too daunted by it.
enkel-ui but it was a very poor attempt at Typescript. I knew I had to do better if I want to learn and upskill myself.
Since the internal watcher project was a success, I decided to port it into a package and make it available to everyone.
I was too overwhelmed by the thought of it.
This project turned out to be Nodehawk. I was determined to make it work. I automated the building and publishing flows, added docs using TypeDocs, did a lot of work on this project. All around the Typescript ecosystem. I also ensured I packaged types with my project, so that anybody using the project via the API had access to types. Coincidentally, an ex-colleague of mine ended up using it via the API in his current job.