shadow VS Previous Serverless Version 0.5.x

So: I am making a JavaFX application to act as a remote console for my server. I'm the only person that will have a copy of it, so it doesn't need to be snazzy or 100% efficient. I have turned the project into a jar via ShadowJar, turned that into an EXE via Launch4j, and yesterday turned that into an installer via Inno.

I’ve never tried this and I I’m not libgdx expert, but you can try running a Uber jar with shadow. it’s the Gradle equivalent of the shade plug-in for maven builds.

When you get into a situation where you need to sandbox a dependency within another, including this example, where you want each of your dependencies to get its own unique instance of their dependency, you can "shadow" the dependency that is to be sandboxed this way. Look into https://github.com/johnrengelman/shadow.

Try using the shadow plugin for gradle https://github.com/johnrengelman/shadow

and also apparently, it's a problem with shadowJar itself https://github.com/johnrengelman/shadow/issues/713

Behind the scenes, Shadow creates a FatJar with all the things we may need in the future.

Note: **According to Serverless documentation you can use the command **serverless deploy -v. However, with Java-based-projects that’s not true because it needs to create a Fatjar with all the needed requirements (so the command will fail). By default, Serverless will set **shadow** as a dependency in the gradle file for those purposes. The deploy command will generate a build file called -all.jar that is the one that’s going to be uploaded to the AWS Lambda function.

The result .jar is going to submitted to Apache Spark cluster (e.g. spark-submit command). So, it should contain all runtime artefacts. Unfortunately, the standard Spring Boot packaging does not put the dependencies in the way Apache Spark expects it. So, we'll use shadow-jar Gradle plugin. Take a look at the example below.

I've writen many Kotlin+Gradle projects that produce jars without the shadow plugin. They're not fat, shaded, standalone executable jars though - is that what you need?

Github | Website

i deployed a lambda and http api gateway using a serverless.com (sls) template as a start. I get the following error when it processes a specific request:

Have you tried serverless.com ? It lets you have infrastructure as code.

- With Lambda, you manage creating and building the container yourself, as well as updating the Lambda function code. There are tools out there such as sst or serverless.com which help streamline this.

If you'd like to use Lambda, usually you need to engineer FOR it, from day one, you don't (often) get to choose some other framework and shoehorn it into Lambda and Serverless. There's some great frameworks to help deploy code into Lambda easily and create REST endpoints for things, one such frameworks is serverless.com that helps easily deploy to it, but it lacks a framework for doing REST that also supports local emulation (as easily). For that, I recommend a framework by AWS called Chalice. This is an amazing REST framework that runs a proxy that works locally and deploys exactly the same on Lambda, it is Python however.

I use serverless.com for AWS stuff.

After knocking out a README with a set of goals and a list of TODOs to check off as I made progress, I spent about 10 hours over a weekend trying to get something to work. I used serverless for making Lambda easier, Github Actions for the deploy pipeline and store my credentials; and sadly I rolled my own access_token refresh logic because I couldn't find a helper that just did that for me! wtf!?

Does everyone who uses Workers just use wrangler cli and the cloudflare console UI for everything or is anyone using other tools like serverless framework (https://serverless.com) instead? Looks like they added some support for cloudflare but haven't tried it yet.