Building a Flutter application (for Web) with AWS Lambda Function URL backend using AWS CDK Pipelines (written in Java)

Wow, this is a long title 😉

In this post I am going to use CDK Pipelines to build a demo Flutter application hosted on AWS S3 with a Backend powered by AWS Lambda (using Function URLs).
The CDK code will be in Java, the Lambda functions in Typescript and the WebApp in Dart. Why? Because I love trying out things 🙂

The code used here is not production ready and does not fulfill required security best practices! 🙂

The CI/CD pipeline

The CI/CD pipeline for this project uses CDK Pipelines and that means it is build on top of AWS CodePipeline (which under the hood uses CodeBuild, CodeStar and other services to be functional).

It consists of different stages that build and deploy the corresponding part of the application:
– one stage for each lambda function
– one stage for the build and deployment of the Flutter application

The stages required by the CDK Pipeline to update itself are automatically added but not part of our code:

public CdkPipelineStack(final Construct parent, final String id, final String branch, final StackProps props) {
		super(parent, id, props);

	String connectionArn = "arn:aws:codestar-connections:eu-central-1:xxx:connection/xxx";
	final CodePipeline pipeline = CodePipeline.Builder.create(this, getCodepipelineName(branch))
					.input(CodePipelineSource.connection("lock128/cdk-codepipeline-flutter", branch,
					.installCommands(List.of("npm install -g aws-cdk" // Commands to run before build
					)).commands(List.of("mvn test", "mvn package", // Language-specific build commands
							"npx cdk synth", // Synth command (always same)

	pipeline.addStage(new CheckAgeLambdaStage(this, "DeployCheckAgeLambda"), getCheckAgeStageOpts());
	pipeline.addStage(new PaperSizeStage(this, "DeployPaperSizeStage"), getPaperSizeStageOpts());
	pipeline.addStage(new CalculatorStage(this, "DeployCalculatorStage"), getCalculatorStageOpts());

	PolicyStatement flutterDeployPermission = getDeployPermissions();
	CodeBuildStep buildAndDeployManual = CodeBuildStep.Builder.create("Execute Flutter Build and CodeCov")

	pipeline.addStage(new FlutterBuildStage(this, "FlutterBuildStage"),


This is the definition of the CI/CD pipeline, it uses our Github repository as the source of the code and automatically starts after a push to the repository on the main branch.
The “Flutter Build Stage” is the one that currently builds the Flutter web application, deploys it and makes it available to the end user. Going forward, to make best use of Flutter, we would need to expand this stage to also be able to build an iOS application, an android application or an application for any other platform supported by Flutter. As a “goal” I would personally also want to extend this stage to be able to publish the apps to the corresponding stores (App Store, Play Store, Windows Store, …) – Thanks to my friends at cosee for the help and guidance around this process!

The architecture diagram of the application

What we are using to show-case the usage of AWS CodePipeline, Flutter as an application and AWS Lambda Function URLs as backend is not really an “application” – but it can do dynamic things and it can easily be extended to include a database backend, etc.

Infrastructure as Code using AWS CDK in Java

In this section you are going to have a look on the CDK code required to provision the infrastructure on AWS.
We are using AWS CDK written in Java – and because of that Maven as a build tool (Maven is the default tool for CDK projects – I’ve already used Gradle as build tool and that works in the same way.

The possibility of writing Infrastructure Code in Java is a great thing because it gives us the option to build on top of our existing skills – and I’ve written enough lines of Java in my career to feel comfortable using it to provision the infrastructure.
This is one of the best things in CDK: You can write your Infrastructure code in Java, Typescript, Python, … – and that helps us to build teams that only have “one” language as a “core skill” – one team might choose to develop in Java, anotherone in Typescript, another team could use Go – this allows the teams to build up mastery in a specific language!

In our example however, we are not making use of this possibility – I’ve choosen to rather go the opossite way: Combine a few languages, just to show that it works 😉

Stacks in the Example Project

The CDK code consists of four “stacks” – each of the Stack representing one “component” in this application.
In our example these four stacks are part of one CDK Application & one CodePipeline. In bigger projects, you might want to split these out into seperate applications – which introduces a lot tof things to consider (e.g. how do they fit and work together, etc.).

While writing this post, the four stacks combined are 129 lines of source code. With the help of the CDK Constructs that are being used this translates to over 1k lines of code in CloudFormation. We are only using L2 constructs here – there is way more constructs available that you can use in the Constructs Hub and also a lot of guidance regarding the usage of CDK over at CDKPatterns.

CDK Stack that provisions the infrastructure for the Flutter hosted website

Making a S3 bucket available to host our Flutter application becomes a very short piece of Java code as shown in the picture above.

Lambda functions behind Function URLs in Typescript and Python

This was definately one of the most awaited announcements in the Serverless space this year: The GA of the “Function URLs” for Lambda on AWS – and this is the reason for me using these as a backend in this showcase.
With this announcment, it is possible to directly expose your application running on AWS Lambda behind an HTTPs endpoint! Without an ApiGateway, Proxy, …
Provisioning the infrastructure for the lambda function with the function URL functionality activated is only a few lines in CDK:

CDK Stack for the Check Age Lambda function with the activation of the Function URL

These Lambda functions will now horizontally scale without us as a developer getting involved. More details on function URLs – there is a lot of good posts on it around like this one or this one.
Around scalability, fellow community builder Vlad has written up a great guide around scalability for containers on his website.

Web Single Page Application built using Flutter and the benefits of using Flutter

Flutter as a multi-platform, developer driven tool gives a lot of flexibility. With a single code base, you are able to publish your application to various targets. In this example, we are using the target platform “web” – which compiles the Dart code to a single page application.

This application is automatically aware of the size of your screen and is interative – which is another cool thing that Flutter takes away from you as a developer. A lot of organizations use Flutter today and the cookbook gives you an easy and good start into developing Flutter applications.

Our example application has three input fields that take input and pass it back to our Function URLs – and then automatically update a Text Widget with the results of the Function URL call. This implementation will work on all platforms.

What did you learn in this post?

You have learned how easy it is to provision AWS infrastructure using AWS CDK. You have also seen that you can easily combine different programming languages in a single CDK application and got an experience on how a CI/CD pipeline can help to automatically deploy our application using AWS CodeBuild.
In addition to that, you have looked at Flutter as a multi-platform development tool.

I’d be glad to get your inputs into my Github repository as a pull request or just as comments on the project itself.

Next steps

Further expansions needed to this project:
– use the CloudFormation Exports of the Lambda functions in the Flutter application instead of hardcoding the URLs for the Lambda Function URLs- enhance security for Lambda Function URLs
– add CloudFront in front of S3 to allow HTTPs connections to the Flutter App
– enhance CI/CD pipeline to package Android App using Flutter
– enhance CI/CD pipeline to package iOS App using Flutter
– enhance CI/CD pipeline to package Windows App using Flutter
Feel free to contribute and add your contributions to this project.

Listen to Werner Vogels talking about the benefits of CDK

Hits: 1123

AWS SWAG that is used and not just grabbed – sustainable SWAG :-)

Ever since I’ve attended my first AWS re:Invent in 2017 one of the SWAG items that I received is part of close to every trip that I do, regardless if its a business trip or a personal trip, this AWS bottle always joins me in traveling:

This bottle does not only look good, it also keeps the water cold when we go on longer, warm hiking trips.
What is your favorite SWAG item? Do you have any SWAG that you regularly use?

I have a lot of other SWAG, but this is really the only item that I regularly use.
Do you have some SWAG that you like to carry on?

Here’s the AWS Community Builders SWAG kit that I receveid a few weeks back:

It’s also cool, but I’m not yet using either of the items on a daily basis 😉

Hits: 133

Why CDK changes the everything for building DevOps teams that own something end-to-end

Software Engineers, Developers, etc. are all “Builders” in my mind. Builders try out a lot of things and most of them are eager to try out new technologies and possibilities.
While doing that, a lot of them behave like these engineers “in real world”:

people working on building during daytime

What does that mean?

They go to the top of something, climbing somewhere and taking risks, but a lot of times they forget what is “below” what they are building.

For these workers in real life, it will most probably obvious that they are not risking their life by climbing up there – because they can see what is below and are aware of the groundwork below the wall they are climbing on.

How is that different in our “Cloud-Software/SaaS-industry”?

I believe that the main difference to day is, that most of our “Engineers” (= Software Developers) are not aware of the infrastructure components that are required to bring their application or microservice up and make sure that it can consistently run.

Why are they not aware?

One of the challenges that I am seing in my day to day job is that we have a lot of “abstractions” that we have build for software developers to make it “easy” to develop and test software. Think of “Docker” or “Kubernetes” (k8s) as making it easy to test applications or microservices locally and make them look, feel and behave the same as in the “target environment”.
However, that is not essentially the truth.
During the development cycle, the engineer will test locally – or maybe within a Continuous Integration environment – but both of these environments will usually not have “production like” data assets and thus will never be comparable to a production environment.

So – it is a real problem, because engineers test against infrastructure (and maybe even deployment strategy) that is not even close to how the service will run in a production environment.

How do we change that?

It should all start with a plan…and everyone that is part of a products lifecycle should be part of it.

person working on blue and white paper on board

CDK changes everything

CDK – and for me this includes awscdk, cdktf, cdk8s – gets the engineer where they feel “home”:

We can describe and write infrastructure in “the developers native language” – Java, Typescript, Go, .NET.

With this, everyone can be empowered to write infrastructure code and feel responsible for it. No more excuses: I don’t like YAML / JSON, I dont know HCL, I don’t know the services, etc.
If you are a developer, you can now write infrastructure code.

This opens up new possibilities for building DevOps teams

Now, with CDK “in the game”, we can empower “developers” and “operators” to talk to help each other “in one joined language”.
Operators can help Developers understand the infrastructure required to bring their service up to speed – and Developers can help Operators to develop infrastructure code.

On the other side, if you start a new DevOps team, you can directly start building out the infrastructure “as it would look like in production” using CDK!
This really makes the developers think about how the service should be running in the production environment later and that will help to drive the correct architecture decisions right from the start.

If you want to learn CDK – look at the CDK Workshop:

More to follow around why I believe CDK is making every cloud developers and DevOps engineers life better soon!

Hits: 172

There is nothing like a “perfect” DevOps engineer!

In my last post I wrote about the “T-shape” model of a “great DevOps engineer” – but does that person actually exist?

I understand the DevOps team that builds & operates “something” in a complex environment. This includes the required software development aspects of it, the CI/CD pipeline, the monitoring tools required, the database or persistence layer, the infrastructure, … – everything that you need to be able to successfully operate what you have built as a team.

Wait… is it only that?

Everything mentioned above is technical, isn’t it?
The “software development” might be Java, Typescript or Go code (or anything else), the CI/CD pipeline is a technical thing. – but is this “enough” for the DevOps team?
I think that we need to add a business view into the team aswell – at the end, anything the DevOps Team builds needs to produce business value or needs to be compared to it.
A “defect” needs to get a dollar value, a new feature needs to produce new revenue and an update to our tools (e.g. monitoring) needs to be translated to costs or time&effort saved.

So what is the perfect DevOps engineer?

Skills shape


A “T-Shaped” DevOps engineer would need to change his skills to have a “Square-Shaped” Skills matrix!

What else does he need?

In additon to the “technical skills”, he will also need to have the business view on the microservice or component he and his team owns.
In an outage, he also needs the communication skills to be able to talk and communicate to clients and a sense of the urgency of the problem.

While I believe that there are a lot of great DevOps engineers around, I have not yet met one that was close to the “target” of being “perfect” in all of the points mentioned – and I am sure I forgot a few…. Feel free to comment!

A perfect DevOps engineer does not exist. It’s the perfect combination of different T-Shaped engineers that act as one team that makes a great DevOps team.

Johannes, March 2022

What are key enablers for a great DevOps team?

Everyone in the team has its skills he is really good at. The really good DevOps engineers are able to “bend” their T-Shaped skills to something that is closer than to the square – maybe not in “all” parts of it but in a few of them.

But what a “great” DevOps team needs, more than anything else is Vision, Trust & Collaboration.

Recent experience from my professional career

Telescope, Insight, Outlook, View, Binoculars, Optics

In my professional career I recently joined a newly formed Development Team as part of a project. We quickly got up to speed with each other and created an atmosphere of trust in all of our (remote-only) meetings.
This made it easy to start collaborating and jointly work on the tasks we had in our backlog.
What we did not have right from the start was a vision, on what we wanted to achieve as a team. Once we had one, or at least a sprint goal for the next two sprints, we where able to quickly deliver value.

A team needs visionary engineers

Hitech, Art, Concept, Digital, Psychedelic, Design

If you want to create a great DevOps team, you will also need visionary engineers, that are brave enough to try out new things by themselves and empower the rest of the team to follow them towards their ideas.

What do you think about how to form a great DevOps team?
Please share your throughts in the comment section!

Hits: 33

DevOps and the T-Shape expert

Last year I attended and internal meeting with our UX team and while talking to the team, we touched on a very interesting question:

How do you define a “great DevOps engineer”?

If you ask five different people, I am sure you would get at least six different answers 🙂

So, without trying to “answer” the question but still covering parts of it, let’s try to look at what DevOps actually is and means. 

The conversation on the meeting started with a colleague asking for some support around “DevOps” tasks that were needed to perform certain activities around release activities. I pushed back on him, pointing out that for me, everyone should have a little bit of “DevOps” knowledge – but re-defining these “DevOps” tasks as being “Automation Tasks”.

I very much enjoyed the conversation, and it reminded me of something that I’ve leared during my DevOps master certification in 2019:

A “great DevOps engineer” has a T-shaped skills profile.

So what does that mean?

A “T-shaped skills profile” is easily explained: Think about the “old” traditional way of combining an engineering team, you had “Analysts”, “Programmers” (Developers), “Test Engineers”, “Web Designer”, “System Engineer” (build automation, scripting, etc.).

In that case, you had the problem that you hit the “bottle neck” with certain skills during different phases of the project, e.g. the “Test Engineers” needed to work vey long hours right before the next release of your piece of software. That was obviously bad for the overall outcome of the team.

However, if you manage to compose your team with people that have a very broad knowledge base for different skills and a small amount of skills where they are experts, your team becomes more efficient because you can support each other in these “clunchy situations”, e.g. “developers” can pick up a bit of “QA work” right before the release date.

1*vVaOjA-Ty1rPRccNsHCb2w.png (444×251)

So, what does this mean for you?

  1. Be aware of your “expert” skills
  2. Practices the skills, where your team is “weak” at, to become better at it and broaden your teams capabilities

Why do we need teams that consist of “T-shape-skilled” engineers?

Because in the “DevOps culture”, its all about “collaboration” – and that is easier, if every team member understands what the “expert” is talking about, at least high level.

Hits: 39