I’m very excited about learning Go, and I’ve already read many success stories from those who are using Go in production.
However, how do you start when you have a massive NodeJS monorepo?
I believe that every microservice could benefit from using Go, but replacing a single microservice might require months of work due to the utility libraries (“wrappers”) we have implemented to work with Kafka, MySQL, and MongoDB, etc.
I was thinking to call these library written in NodeJS from GoLang - and replace them once I’ve time but I’m not sure if this is going to work.
First of all, I think you need to clarify why you want to change the technology. Is there maybe a problem you have now, for which you identified Node as the limiting part (i.e., maybe your application - or a part of it - has to perform CPU-intensive operations and Node cannot keep up)?. Or maybe the main reason for the change is for you / your team to learn a new technology. That’s as good a reason, as well.
Next, I would go over the architecture of the current Node application. Is there anything you could first adapt there, to address your problem from above? Put the fires out, so you can plan the migration to Go without pressure. While reviewing the architecture, can you identify one small part of the application you could decouple in its own service - maybe something off the critical path of whatever your application is doing. That would be a great candidate to start your migration - you bring in a new component written in Go which collaborates with the current Node application to offer the same features to the users. Potential examples would be importing data from outside world; report generation; asynchronous communication with users - of course, these may not apply to your app, but hopefully you get the point I’m trying to make. Going forward, you cut off other parts of the application - rinse and repeat.
Regarding the wrappers you mentioned that you or your team have built around different technologies - I wouldn’t consider those roadblocks for the migration necessarily. The Node and Go ecosystems are different, the way you interact with various techs is different. I would venture that you may not need to migrate as-is the way your Node app is doing things. Going back to the architecture of your app, maybe you could re-design the way you interact with the external world - if you could adopt, for example, a “ports and adapters” style for your application, you could decouple handling, for example, Kafka. This way, you could write an idiomatic Go adapter to interact with Kafka, which has nothing to do with how you Node app is doing that.
Happy to dig deeper if you can / are willing to share details of your current app and your motivation for the change.
Or maybe the main reason for the change is for you / your team to learn a new technology
Improve CPU/Memory consumption. Ex.: GQL parsing operation takes time in nodejs.
While reviewing the architecture, can you identify one small part
Good point, I can isolate “a function” into a new microservice and gradually migrate the rest of the code.
The Node and Go ecosystems are different, the way you interact with various techs is different
Correct.
if you could adopt, for example, a “ports and adapters” style for your application, you could decouple handling, for example, Kafka
This is what we have, but the Adapter is doing a lot to abstract the underlying technology and simplify its usage. That’s why I was thinking to keep the adapter in NodeJS and call it from Golang and replace the adapters gradually. If Golang can call NodeJS and keep the Kafka and MongoDB TCP/IP connections up in the nodejs process it might be a easier for me. Rewriting all the adapters in Golang might take a while
