100thAirhacksQ&A.md

100thAirhacksQ&A.md

Ask questions and see you at July, 4th, 8.PM. CET: youtube.com/c/bienadam

Also checkout recent episode:

Please keep the questions Jakarta EE-stic. Means: as short and as concise as only possible. Feel free to ask several, shorter questions. Upcoming airhacks.tv events are also going to be announced at meetup.com/airhacks

Dear @AdamBien

I have tried the lambda-java17-layer to enable jdk17 in a CDK deployment and like to hear you idea on how to reuse the Java17Layer across multiple CDK deployments.

I do not like the idea of uploading java17layer.zip in every CDK deployment.

public class Jdk17Layer {
	Construct scope;
	public Jdk17Layer(Construct scope) {
		this.scope = scope;
	}
	public LayerVersion getLayer() {
		LayerVersion java17layer = new LayerVersion(scope, "Java17Layer", LayerVersionProps.builder()
		        .layerVersionName("Java17Layer")
		        .description("Java 17")
		        .compatibleRuntimes(Arrays.asList(Runtime.PROVIDED_AL2))
		        .code(Code.fromAsset("java17layer.zip"))
		        .build());
		return java17layer;
	}
}

public class QuarkusLambdaJdk17 extends Construct {
	static Map<String, String> configuration = Map.of("message", "hello, quarkus as AWS Lambda");
	static String lambdaHandler = "io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest";
	static int memory = 1024; // ~0.5 vCPU
	static int timeout = 10;
	IFunction function;
	public QuarkusLambdaJdk17(Construct scope, String functionName) {
		super(scope, "QuarkusLambda");
		this.function = createFunction(scope,functionName, lambdaHandler, configuration, memory, timeout);
	}
	IFunction createFunction(Construct scope, String functionName, String functionHandler, Map<String, String> configuration, int memory,
			int timeout) {
		Jdk17Layer java17layer = new Jdk17Layer(scope);
		return Function.Builder.create(this, functionName) //
				.runtime(Runtime.PROVIDED_AL2) //
				.layers(singletonList(java17layer.getLayer())) //
				.code(Code.fromAsset("../lambda/target/function.zip")) //
				.handler(functionHandler) //
				.memorySize(memory) //
				.functionName(functionName) //
				.environment(configuration) //				
				.timeout(Duration.seconds(timeout)) //
				.build();
	}
	public IFunction getFunction() {
		return this.function;
	}
}

Hi Adam. The 99th meeting you remarked how most all the questions were based on cloud technology. So I'll ask a question that not cloud related. -:)

I am using Quarkus to build a backend jax-rs application that accesses a Postgresql database. The jax-rs is accessed via a web client.

Could you explain some pro and con of the following deployments:

1. Deploy with Docker compose (jax-rs, db, web client)
2. Deploy as Executable jar (web client would be included in resources/META-INF/resources)
3. Deploy as native executable (web client would be included in resources/META-INF/resources)

Hi Adam, What is your opinion on database schema migration in plain Jakarta EE? How do you add tables and change columns. Liquibase, Flyway or manuel scripts? Should Liquibase(6,6MB) be included in the war file?

@AdamBien Hey! Can you pleeeeeeeeeeease help me with this question? Since Jakarta EE is a set of specifications, is it true that an application built using only Jakarta APIs, rather than Spring for instance, is better for cloud as it allows me to deploy only my business logic?

— Douglas (@Douglas61121623) June 17, 2022

Hi, Adam.

Feel free to ask several, shorter questions.

Ok, so here I go. And I'm sorry if there's a lot of misconceptions on my questions though. I'm new to Jakarta.

First question:

In a context where the deployment is layered and an application server is used, is there any significant advantage in having the application built using only Jakarta APIs rather than dependencies that are bundled in the artificat (like Spring's ones)?

Considering that the answer for my previous question was positive (or at least a "maybe"):

How using Quarkus instead of an application server would impact this possible advantage? I mean, considering that Quarkus puts all required runtime dependencies in a lib-folder which you can put into a Docker-Layer.

Spring Native is said to provide key advantages, like instant startup, instant peak performance, and reduced memory consumption. Is there a equivalent solution for applications built using Jakarta EE only?

If I use Payara as my application server but I want to use Hibernate instead of eclipselink, will I have to deploy Hibernate together with my application?

How does Quarkus provides to the application the dependencies from the lib folder? In terms of efficiency, how does this Quarkus strategy for providing dependencies compares to the one used by application servers to provide spec's implementations to the application?

Which application server do you recommend if I want to use Hibernate (I'm not intending to use Hibernate specific features though. I just prefer its logging)?

100? whoa!!
congradulations!
and, of course, a shout-out to kinga

Do you have any recommendations or "rules of thumb" on where to check roles/privileges declaratively? Basically, where would you use annotations like Spring @Secured: at the Controller (endpoint) level or at the business logic/"service" level? If "it depends", then what are the questions I should ask, before settling for one of these approaches?

My quarkus app running in jvm mode consumes about 200MB and less than 1% CPU and in native mode consumes 80MB and less than 1% CPU when I inspect them in activity monitor. Some online providers offer VM sizes like nano or micro with .25 vCPU to .5 vCPU and 512MB to 1GB. Would using activity monitor be a good test of what VM size to select?

Hi Adam

Thanks for sharing the code for CDK deployment to AWS - https://github.com/AdamBien/aws-quarkus-lambda-cdk-plain

Can't get LambdaAlbStack to do as I like. How do I get alb to return text/plan or application/json as Content-Type in the response and not ´application/octet-stream´ ?

$ curl -i http://AirhacksLambdaLB-1858173519.eu-central-1.elb.amazonaws.com/hello
HTTP/1.1 200 OK
Server: awselb/2.0
Date: Mon, 04 Jul 2022 07:25:02 GMT
Content-Type: application/octet-stream
Content-Length: 28
Connection: keep-alive

hello, quarkus as AWS Lambda

I have done two very small change to the code.

Change in lambda/pom.xml

- <artifactId>quarkus-amazon-lambda-http</artifactId>
+  <artifactId>quarkus-amazon-lambda-rest</artifactId>

Change in cdk/src/main/java/airhacks/CDKApp.java

- new FunctionURLStack(app,appName);
+ // new FunctionURLStack(app,appName);
- // new LambdaAlbStack(app,appName);
+ new LambdaAlbStack(app,appName); 

HI Adam,

dynamic import in JavaScript.
i want dynamicly import in JavaScript, because sometimes i let run my JavaScript-App local on my pc, sometimes in the Cloud

Example for run local:
import { content01 } from "http://localhost:8182/lib/env.js";
....

Example for run in Cloud:
import { content01 } from "http://www.meine-app.com:8182/lib/env.js";
....

I am searching for something like this:
import { content01 } from ${baseURI}:8182/lib/env.js";

My Application must only run on Google-Chrome.
Is there a new feature in new ECMA-Standard?

Congratulations on the 100th airhacks! Keep it going, Adam!

You mentioned on several occasions that cloud is like an "exploded application server". Do you think the same is also true of the cloud-native databases?

Do you have any experience using Amazon DynamoDB transactions - like here ? Have you used them on any of your projects requiring stronger consistency guarantees or you wouldn't bother?

On one of recent episodes you mentioned using caches (e.g. JPA L2 cache) in serverless (e.g. Lambda) deployments makes no sense. How about accessing static data (e.g. master data which very rarely changes)?

Hi Adam,

I have no question (for today) :-) I was there for the 60th, which was the 5th year anniversary so I cannot not give a shoutout for the 100th episode. It has been 8 years and 4 months, that's a milestone, thanks for keeping it up and not quitting. We went from the green and blue books to Java EE to BCE to Glassfish to Payara to Quarkus and now AWS Lamba... thrilled to know what's next down the line.

D.