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.
Why?
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.
Problems
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 .js, .json and .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.
Solution
I was trying to find ways to solve it, and realised that Chokidar inherently has a lot of rich event streams.
I ditched Nodemon, created a quick wrapper around Chokidar (specifically for watching GraphQL files along with Javascript). I used the 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!
Journey
I was inquisitive about Typescript but having seen and read Typescript code before, was too daunted by it.
We were completely reliant on Javascript internally for this very reason. Everyone was very apprehensive of Typescript. I had even started another project 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.
I spent an entire week mulling over and going through Typescript docs and code. Then one weekend, I just started porting it. Soon, I realised the brilliance of Typescript. It just flows so beautifully. The layers it adds on top of Javascript are just absolutely simple and idiomatic. The types help massively in code discovery. When I got back to some piece of code I had written, Typescript reminded me what was there. The integration with VS Code is the one of the best things that's happened to the Javascript ecosystem.
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.
Conclusion
I know Typescript is daunting to look at for beginners. I understand the arguments that say that it adds a lot of "clutter" to your code. But what I also believe, is that the clutter is needed clutter. Without that, Javascript is a blackbox. This clutter provides information to you and anyone working on it with you. Rather than calling it clutter, a better phrase would be to call Typescript "informative". You can't really say no to information, can you?
I would strongly advise all the Javascript devs to learn Typescript. The ecosystem is brilliant, the tooling is GREAT! Overall it becomes a breeze once you get grooving. I have not created a single project in Javascript since I moved to Typescript, and honestly, I don't think I want to.
Top comments (0)