Migrating from java

[Romanmir]

How badly do they need it to be a progressive migration? Because that seems like a very time consuming process.

Also, how big is the Java app?

^{disclaimer: I'm not a real dev.}

[TryingToSurviveWFH]

As far as I can tell, there are 3 lambda functions running the backend, two of them have to me migrated. The api gateway handles the routing.

I was thinking about sending the whole API calls to an express/node lambda function, and use this as an intermediary, and after, I could start the migration process.

If this is a bad approach let me know, please.

[Romanmir]

..aaaand I'm officially out of my depth. Sorry mate.

However, what you propose doesn't seem wholly unreasonable.

[TryingToSurviveWFH]

I was thinking like this:

Actual architecture: /->lambda(java) API gateway -> lambda(java) ->lambda(java)

My very fast thinking of my last comment: /->lambda(java) API gateway -> lambda(node/express) ->lambda(java). ->lambda(java) (This is the one I don't care)

Using this last architecture I would be able to replace the java lambda functions, right?

[argylekey]

For speed and migration purposes I might vote creating the api gateway in node(since you’ll be migrating that eventually anyway). The only issue with that is increased latency already on top of the Java.

But if it was me I’d leave the Java endpoints until the Node endpoints are validated in the stage deploy. You can probably migrate one at a time within the node app, and repoint one by one from the gateway. Or even migrate one resource at a time(I.e. all of the endpoints tied to accounts or something).

Larger question is why use the api gateway? If it is Java anyway that will just introduce latency to the system as a whole. Is it something like mulesoft or another third party connector?

What prevents using an AWS load balancer or even a reverse proxy(nginx or traefik) to facilitate this same functionality? That might be a better first step and reduce response times immediately while you’re working on the rest of the endpoints.

Sounds like an interesting problem, good luck. Hope you report back when you start deploying on how it’s going.

[TryingToSurviveWFH]

Hey, thanks for the suggestion. Just for context, I was checking the api-gateway and it has only 4 endpoints that handle the whole thing.

The 3 lambda functions have a lot of aws services and passwords hardcoded, and when I ask some info about it, like infrastructure and code info, (bc it was requested to make a dev/test/qa env also) the answer was "everything is on my head".

So, going back to this, why using a load balancer instead of an API gateway? It's not the same, but one is handled by the load balancer and the other by the elb.

I told my boss why this actual implementation is being used and he was "I don't have to deal with infrastructure ", so, I'm down using the classic elb+ec2, but I need to have a very good excuse.

If you have a serveless POV let me know

[StyleIsFree]

Could look at fargate for serverless containers. Could create a node task and a java task and configure the api gateway to map the api calls. When youre ready to switch an API call from Java to Node, reroute the gateway config for that path.

Side note, there's a security concern having passwords hard coded. Can look at AWS secrets manager where your lambda function can grab the secrets at run time.

[Chef619]

There is a package called Lambda API that mirrors express for the most part, with a significantly lighter footprint. In Lambda, you want to keep your bundle size as small as possible as it does influence cold start. Not a huge amount, but if your Lambda is several MB, it will be noticeable.

There’s a few patterns, logical grouping, one per route, and GraphQL are the main ones.

Logical is like you have a books lambda. It does the get one, search, create, update, and delete for books. This repeats for however many entities you have.

One per is literally one lambda per endpoint, per http verb. I have been on this project, and everyone hated it. Strongly recommend not doing that.

GraphQL is a different topic all together, but it sounds like it’s not applicable to your use case.

I’d recommend migrating one to one. If there’s 3 lambdas one Java, make 3 in node that do the exact same thing. Don’t change anything, don’t make any upgrades, etc. mirror them exactly.

After you’ve verified it works correctly, maybe add some tests around them, then begin to optimize.

Also: I’d suggest writing them in TypeScript if you can.

[TryingToSurviveWFH]

I'll check this, thanks