DEV Community: Filip Pýrek

Cloud Coding Live - Let's learn Rust basics - Can senior developer learn Rust?

Filip Pýrek — Mon, 15 Apr 2024 20:40:27 +0000

In this episode of Cloud Coding Live I took a look at Rust, one of the recently most hyped languages.

Rust is a multi-paradigm, general-purpose programming language that emphasizes performance, type safety, and concurrency.

Many people say that Rust is the future? But is it? Let's try and see how hard it is to work with.

Can senior developer learn Rust?

Follow me on

Cloud Coding Live - Exploring Wing Lang - Future of cloud development?

Filip Pýrek — Fri, 05 Apr 2024 07:44:42 +0000

In this episode of Cloud Coding Live I took a look at Wing Lang.

Wing combines infrastructure and runtime code in one language, enabling developers to stay in their creative flow, and to deliver better software, faster and more securely.

Is Wing Lang - Future of cloud development?

Follow me on

Build your own little AWS Console in CDK with Buttonize

Filip Pýrek — Mon, 18 Mar 2024 16:00:00 +0000

We are proud to announce the launch of Buttonize.io, the easiest way to hook up UI components directly to AWS Lambda functions.

Buttonize is a fully managed SaaS platform connected directly to your AWS environment, providing you with an Infrastructure-as-Code abstraction, such as an AWS CDK library with a rich set of UI components and actions for building internal tools on top of the cloud.

How Buttonize can help you

Buttonize helps developers and companies using AWS solve the painful problem of internal tooling.

Problems with internal tooling

Internal tooling is a perennial problem. We all have these "temporary" tools in our companies that have been around forever with so much tech debt that everybody is afraid to touch the code.

When deciding on internal tooling, companies usually have three options

Build the app from scratch - API + auth + frontend + indefinite maintenance
Use a drag-and-drop platform, such as Retool - all developers hate no-code tools
Create Slack bots - a text interface is sufficient for only a small number of use-cases

Buttonize comes to the rescue

We think these three principles are important when solving business problem via internal tools.

Minimize future maintenance
Build it quickly
Don't reinvent the wheel

Buttonize gives you a way to build and deploy internal apps with tools you already use. We provide you with CDK Constructs that have simple interfaces which allow you to define UI components and connect them to AWS. No need to worry about anything else. Just run cdk deploy. That's it.

Demo video

Join our Discord community and let us know how you like Buttonize.

Learn more at buttonize.io.

Awengers! New Discord Community for AWS-disrupting startup teams

Filip Pýrek — Sun, 02 Apr 2023 10:41:54 +0000

Join at: awengers.com/discord

AWS Unbundling

As both an AWS customer and a founder of early stage AWS-disrupting startup I'm seeing this trend of so called "AWS unbundling" to grow more and more recently. AWS has 250+ services and couple of them are awesome, some are okay and some are terrible. But there is a huge demand for awesome developer and user experience across the whole development lifecycle.

AWS has tough challenge ahead of itself which is "how to move forward?". AWS is infamous for it's operational excellence and not-killing the services, as opposed to for example Google and that's how AWS has built it's trust with customers who are running their production workloads on AWS.

But as every company grows, it becomes slower and less flexible and AWS is no exception and even though AWS has kind of a decentralised structure with it's two pizza teams, it's starting to hit the limits anyway.

Some of the services are stuck in status quo for years and don't add any new significant features and improvements because of corporate mess and ton of responsibility, like for example Cognito or CloudFormation. Don't take me wrong - they have tough job to do, they have millions of customers relying on them. But on the other hand they are blocking further development of the ecosystem.

AWS did a great job of building an open cloud platform because even internal AWS teams need to build the services on top of public APIs, which means that in the end, anyone can build the same service as AWS and just plug it into the ecosystem.

And AWS knows this could be a way forward and even if some startup builds a competition for some of their existing services, they know they will make a profit from it anyway because in the end even the competing startup is usually running on AWS.

// Detect dark theme var iframe = document.getElementById('tweet-1640907441347985409-879'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1640907441347985409&theme=dark" }

New era of Serverless Developer Experience

There are popping up many startups recently focusing on Serverless Developer Experience and they want to make it right from A to Z across the whole development lifecycle.

For example:

There are also many startups focused on competing with individual AWS services like for example CloudWatch, ElastiCache, RDS, AWS Console, DynamoDB any many many other.

For example:

Let's join our forces Awengers!

Competing with multibillion dollar giant is no easy task and that's why I think the best way how to address this is to connect into a community and join our forces and that's why I created Awengers Discord Community.

Are you a startup founder? Are you a developer? Are you a product manager? Are you a developer advocate? In an AWS-disrupting startup? Size of the startup does not matter, it can range from one-man-show to Series-A startup with dozens of employes. Join us!

Join us at: awengers.com/discord

Why AWS Console desperately needs a competition?

Filip Pýrek — Sun, 30 Jan 2022 13:58:39 +0000

The motto of AWS Console is loud and clear.

Which requires AWS to build a monstrous web app which must cover thousands of use-cases of their 150+ cloud services and to be honest – they are really trying do their best.

What's the problem

The main advantage of AWS Console is at the same time its biggest problem – it must cover everything – from EC2 subnets management through Lambda code editor to IoT debugging tools.

Creating a UI which must cover so many completely different and abstract use-cases is a huge challenge and requires doing a ton of trade-offs which usually hurt the end user.

AWS Console is meant for DevOps teams

AWS Console is mainly targeted on DevOps experts and developers trying new AWS services and by visually representing a cloud service, AWS makes it look more understandable and less scary - as sometimes more complex services can look like.

The reason why AWS Console is covering almost all the use-cases is because it's part of the sales process.

When a DevOps team accepts to use the service they switch to some scalable Infrastructure as Code solution anyway and they get back to the Management Console only in case of some IaC disaster or when they need to discover some new features of the service.

New trends. New needs. New opportunities.

AWS Console showed us over the years that managed cloud services can have a simple but powerful user interface, through which we can build and manage big applications.

With rise of Serverless architecture the transition towards managed services is accelerating more and more and it brings many new challenges and opportunities.

That's where the new opportunities come into play – creating cloud consoles tailor made for given set of use-cases on top of AWS API.

AWS Console for non-technical teams

One of the main advantages of Serverless architecture is speed of development. Creating an API endpoint which can handle tens of thousands of requests per second is just a matter of couple clicks in AWS console or lines in IaC definition files.

Since developers are becoming more and more of a precious resource, companies want them to really focus on developing things which bring the biggest business added value.

Busy developers

After releasing the app developers suddenly need to start dealing with the operations perspective of the business. They need to change system configurations based on product decisions every now and then. They are required to change some values inside a database for a certain user because of the sales team special deals and the list goes on – and during all this, they need to continue with fixing the bugs and developing new features.

So they either burn out quickly or they need to slow down in order to handle all the load.

Non-technical teams coming to the rescue

The problem of developers shortage is being addressed by Low-code/No-code tools which help developers to offload some of the workload to non-technical team members.

Since only some of AWS use-cases would fit such a transition, it doesn't make sense to give those team members access to AWS Console directly, because they would get lost inside such a monstrous system – and they would see so many "Access Denied" error messages along the way.

Solution could be a SaaS. Which would handle all the important stuff like authentication, authorization, access auditing and it would provide a simple UI for those use-cases and also an easy way for developers to integrate it into their existing platform.

Example – Cognito

Problem

Support team needs to reset user's Cognito MFA settings because he lost his phone with the authenticator app and didn't backup his restoration codes.

Solution

Support team member goes to the SaaS, opens control panel called "User account" and sees there an input with button called "Reset MFA". He fills a "User ID" to the input field and clicks on the button.

Implementation

Developer opens the SaaS, enters "User Account" control panel and clicks on "Add new widget". Inside the wizard he adds "User ID" as required input parameter, then he selects that he would like the widget to call Cognito and selects the appropriate action, then he links the "User ID" input parameter to username attribute in Cognito API call and saves the widget.

Abstract example of the widget's AWS configuration:

// Velocity VTL template
{
  "region": "eu-central-1",
  "service": "CognitoIdentityServiceProvider",
  "method": "adminSetUserMFAPreference",
  "params": {
    "UserPoolId": "eu-central-1_x1X1Ock9c",
    "Username": "$attributes.userId", // "User ID" input value
    "SoftwareTokenMfaSettings": {
      "Enabled": false,
      "PreferredMfa": false
    }
  }
}

Serverless native

A big advantage of such tools would be that it is "Serverless native". Meaning that it would support the same way of thinking that the Serverless developers already have. I would support triggers for validating or modifying the data. I would support AWS Service Integration Pattern to empower developers with the power of whole AWS cloud. I would support integration to CloudFormation through Custom Resources. And the list goes on.

Conclusion

In upcoming years the community will see a lot of innovations coming up in the Serverless space. Since me and my team have 5+ years of experience with developing and operating Serverless applications, we see many opportunities in the space and creating such competitor for AWS console is one of them – and we definitely don't want to miss out on this one.

Make sure to follow me on Twitter @FilipPyrek to keep up-to-date with the latest Serverless news and let me know in the comments what you think about this idea.

// Detect dark theme var iframe = document.getElementById('tweet-1453034585659527169-132'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1453034585659527169&theme=dark" }

Serverless Architect Filip Pyrek in podcast on current challenges in Serverless space

Filip Pýrek — Fri, 13 Aug 2021 21:44:20 +0000

On this episode of the Talking Serverless Podcast Ryan Jones is joined by Filip Pyrek, an AWS Community builder and Serverless Architect. Described as “one of the youngest people to know the most about serverless in Europe” Filip began working for Purple Technology at only 18. Purple Technology specializes in developing software for FinTech companies; an emerging industry that leverages technology to make financial services more accessible. Their journey with Serverless started in the fall of 2017 with only 4 developers and since then have grown to 25+ with all their newly built software being Serverless.

Episode available also on:

Lessons learned: AWS AppSync Subscriptions

Filip Pýrek — Wed, 26 May 2021 10:06:32 +0000

AWS AppSync

AWS AppSync, simply said API Gateway for GraphQL since it allows you to connect your GraphQL schema to different data sources like RDS, DynamoDB, Lambda, HTTP endpoint etc.

We are using AppSync in our Purple Apps to power application APIs.
Learn more in Purple Stack API docs.

The AppSync Subscriptions

First we were excited to see that AppSync supports GraphQL subscriptions. But the excitement went down slightly when we discovered that they are tightly coupled with mutations.

This feature seems to be nice when working on some super simple CRUD system, but when you start building a bigger application which has a lot of business logic hidden in asynchronous background processes like Step Functions, it starts to fall short.

We solved that problem by creating dummy mutations with pass-through lambda resolvers which can be invoked only by IAM users.
Later on we discovered "local resolvers" which can do the same job with no need for invoking lambda function.

Along the way we've stumbled upon some specific AppSync behaviours which are not obvious at first sight and information about them is "hidden" deep down in the documentation within complex sentences.

Lessons learned

1. Subscription arguments are matched against the mutation response fields, not against the mutation arguments.

Nowhere in the documentation is it said how exactly the subscription arguments matching magic works. It’s unclear whether the matching is done against the mutation arguments or the mutation response fields.

type Mutation {
  addItem(argA: ID!, argB: String!, argC: Int!): AddItemResponse!
}

type Subscription {
  # filtering by "argA" ❌
  onAddItem(argA: ID!): AddItemResponse 
  @aws_subscribe(mutations: ["addItem"])

  # filtering by "fieldF" ✅
  onAddItem(fieldF: String!): AddItemResponse 
  @aws_subscribe(mutations: ["addItem"])

}

type AddItemResponse {
  fieldD: String!
  fieldE: Int!
  fieldF: String!
}

2. The subscription response must be optional

I don't understand exactly why, but the subscription response must be optional. AppSync allows you to successfully save the schema with a required subscription response, but when you try to connect to the subscription from a frontend client, it starts throwing some shallow error which doesn't explicitly tell you that subscription responses must be optional. And then you spend several hours trying to figure out where the problem is.

type Mutation {
  addItem(argA: ID!, argB: String!, argC: Int!): AddItemResponse!
}

type Subscription {
  # AddItemResponse is optinal  ✅
  onAddItem(fieldF: String!): AddItemResponse 
  @aws_subscribe(mutations: ["addItem"])

  # AddItemResponse is required ❌
  onAddItem(fieldF: String!): AddItemResponse! 
  @aws_subscribe(mutations: ["addItem"])

}

type AddItemResponse {
  fieldD: String!
  fieldE: Int!
  fieldF: String!
}

3. A subscription message contains only the fields which were requested by the mutation - other fields will be null

After some time I've found out that this is explained in three big paragraphs in the docs.

The point is that even though your lambda resolver is returning values for all the mutation fields, an AppSync subscription is only seeing the mutation fields which were selected in the mutation request. This is probably caused by the fact that resolver doesn't have to return values for fields which are not requested in the mutation request.

GraphQL Schema

type Mutation {
  addItem(argA: ID!, argB: String!, argC: Int!): AddItemResponse!
}

type Subscription {
  onAddItem(fieldA: String!): AddItemResponse 
  @aws_subscribe(mutations: ["addItem"])
}

type AddItemResponse {
  fieldA: String!
  fieldB: Int!
  fieldC: String!
}

Mutation called on backend in some asynchronous process

mutation AddItem {
  addItem(argA: "valueA", argB: "valueB", argC: 123) {
    fieldA
    fieldC
  }
}

Subscription statement on frontend

subscription SubscribeOnAddItem {
  onAddItem(fieldA: "valueA") {
    fieldA
    fieldB
    fieldC
  }
}

Resulting subscription message

{
  fieldA: 'valueA', 
  fieldB: null, // fieldB is null because it was not requested in the mutation
  fieldC: 123
}

4. If the filtering field is not specified in the mutation response, the subscription is not fired

This feature could be inferred from the first point, but still it's an important thing to realize.

GraphQL Schema

type Mutation {
  addItem(argA: ID!, argB: String!, argC: Int!): AddItemResponse!
}

type Subscription {
  onAddItem(fieldA: String!): AddItemResponse 
  @aws_subscribe(mutations: ["addItem"])
}

type AddItemResponse {
  fieldA: String!
  fieldB: Int!
  fieldC: String!
}

Mutation called on backend in some asynchronous process

mutation AddItem {
  addItem(argA: "valueA", argB: "valueB", argC: 123) {
    fieldB
    fieldC
  }
}

Subscription statement on frontend

subscription SubscribeOnAddItem {
  onAddItem(fieldA: "valueA") {
    fieldA
    fieldB
    fieldC
  }
}

In this case the subscription doesn't get fired because the mutation is not requesting fieldA which is used for filtering in the subscription data.

Even though your lambda resolver also returned a value for fieldA, it's not going to work because matching happens after selecting the requested fields - not before.

5. The subscription resolver is optional - but it can be used for authorization

When I was testing subscriptions, I asked myself, "what happens if I create a lambda resolver for the subscription?" So I tried and I discovered that the subscription resolver is called every time before a new subscription connection is established.

It seems like the subscription resolver is meant for authorization, because it doesn't really matter what you return as an output for the resolver. Only thing that matters is if the resolver function succeeds or fails. If it succeeds, a connection is established; if it fails, an error is sent to the frontend.

GraphQL Schema

type Mutation {
  addItem(owner: ID!, text: String!): AddItemResponse!
}

type Subscription {
  onAddItem(owner: String!): AddItemResponse 
  @aws_subscribe(mutations: ["addItem"])
}

type AddItemResponse {
  owner: String!
  text: String!
}

Subscription resolver

'use strict'

module.exports.handler = async (event) => {
  if (event.identity.username === event.arguments.owner) {
    return null
  }
  throw new Error('Access denied')
}

Conclusion

AppSync is a nice and useful service but it still has some space for improvements and new features which we are definitely looking forward to.

Hopefully this article made your life easier in case you've been struggling with AppSync and you have a better overview of what you can do with it.

With ❤️ made in Brno, Czech Republic, Europe.

In case you have any questions, feel free to contact me at Twitter @FilipPyrek.

Checkout more of our articles on Purple Technology blog.