I'm not sure if this us the best place to ask this question.
I have web application, serving an app, and moderators applications, with some traffic.
This application is a microservice architecture based application based on graphql apis for interaction.
I am originally a java developer with quite some experience.
I built this application on typescript, express, typegraphql and typeorm.
The application is working fine, but it's laggy.
I am not sure how to fix the performance yet.
I am in a fix on how to scale my application to make quick changes and keep it fast and stable .
I have below options that I want to consider
Should I migrate to rust? I love rust , but I'm still noob, but I didn't know typescript when I started this project, either. I can catch up languages easy. So this is my first choice. But when I see package repository, I don't see packages getting updated that often, many packages re dormant and I am not sure of their support. I would take juniper, and diesel for base packages. I need packages for app monitoring, orm, web, jwt verification, dependency injection, analytics etc. One of the reasons I picked typescript.
. Should I migrate it to java? I have lots of experience, but the development is a bit slow and memory management is not impressive to me. I want to deploy it on cloud, but I am not sure if java would be this stable. I know java inside out. So that's just my opinion. Though packages are stable and I have experience in it.
Should I start using deno? Not yet stable , but still better than js, and I'm not using js.
Should I migrate my API to rest or protobuf? This is not mutual exclusive to options above. I would do this at last.
I hope some generous soul can answer this. I'm in a fix
First of all, find the primary motivation for whether you want to change something. Is it:
You want to improve the performance
You want to learn a new technology, and try to use it in your app
If you have a business depending on the app, migrating an application for reason 2) is typically a rather bad idea - so try to resist it if it's true.
Now assuming we are talking about option 1), I heavily would recommend you to figure out what makes it laggy before doing any changes. Otherwise you might change the underlying technology and still have the same issue. Or you could have achieved the same result with some small tweaks in the current implementation.
Typescript and node.js are certainly not on par with Rust on peak performance, but you might not need that. In exachange these technologies might be easier to work with, and you already have experience with them.
In order to find out what is slow, you can e.g. capture timing metrics for various parts of the app and determine the bottleneck. Start working on improving the biggest bottleneck.
Certainly you should consider Rust, as you are it seems, but if you have invested significant time in your project it perhaps makes no sense to waste time recreating it in Rust without a really good reason. As you mentioned "micro service architecture" perhaps new services could be created in Rust, or some of them recreated in Rust if they are shown to be irretrievably slow/broken.
I presume your micro-services are written created with node.js. As such I strongly suspect your problems with lag are not due to the Typescript or node.js. Perhaps your database, perhaps your algorithms/architecture. JS/nodejs performs very well. I know nothing of graphql but that smells like a performance problem area to me.
Your first step in tackling performance problems should be measurement. Find out what is causing the delays. No good wasting your life rewriting everything only to find out you have recreated the same problem in a different language!
No, you should not migrate to Java. If you were to invest all that time in changing language far better to move to something with performance that does actually offer compelling new ideas and benefits. Besides, Oracle.
We know nothing of what your system does so it's impossible to advise on rearchitecting it. A typical REST API served up by Express is going to be about as fast as you can get. Likely the lags are caused by the database behind it. For real-time, "push", data to the browser use web sockets.
I would not move to protobuf without doing some tests first to see if there is actually a performance benefit.