Forem: Elad Ben-Israel

Local simulation of serverless function concurrency

Elad Ben-Israel — Wed, 01 May 2024 18:09:20 +0000

The 9th issue of the Wing Inflight Magazine.

I am pleased to share another issue of the Wing Inflight Magazine with recent updates and news
from the Winglang project.

So what is Wing again?

Wing is a new programming environment for the cloud. It makes it easy for developers to build and test distributed systems that leverage a variety of powerful cloud primitives such as queues, topics, API endpoints, buckets, websites, topics, and a growing ecosystem of winglibs.

Wing comes with a visual cloud simulator which can be used to interact and test complete cloud applications on your local machine, with fast hot reloading and without having to deploy a single
resource to the cloud.

One of the unique capabilities of Wing is that it supports what we call pluggable platform
providers. This means that applications can be cloud- and provisioning-engine agnostic, so they can be deployed to multiple cloud providers using multiple provisioning engines.

There is already support for Terraform/OpenTofu, CloudFormation, AWS, GCP, and Azure, and discussions about

Check out the compatibility matrix, add your 👍 to the relevant issue, and share your use case to help us prioritize!

Check out the compatibility
matrix, add your 👍 to the
relevant issue, and share your use case to help us prioritize!

Platform teams can also create their own custom platforms using CDK constructs. This offers central
control over best practices, compliance policies, security, deployment strategies, and any other
aspect of how Wing applications are implemented in an organization's cloud environment.

Wing is still in active development, but we are starting to see some really cool stuff being
built with it. If you are up for a really fun (yet possibly bumpy) ride, we encourage you to take
Wing for a spin on your local machine or in the Wing
Playground and let us know what you
think.

We are designing Wing to be familiar and friendly for developers who come from modern
object-oriented background such as TypeScript, Swift, C#, and Java, so it will take you 5
minutes to learn.

In today's issue

🐛 Debugging with breakpoints
📊 Local simulation of serverless function concurrency
💁 A new project template for React with Vite
🔘 Adding UI to Wing classes through bring ui
🪝 Exposing cloud endpoints for webhook development
🏋️‍♀️ Explicit lifting of preflight objects
🤞 Changes to default object identifiers
💼 Implicitly loaded platform extensions
🕑 Standardize cron expressions
🎥 Goodies from the Wingly Update
🦁 Wing in the Wild
👯‍♂️ Community Events

Debugging with breakpoints

It is now possible to set breakpoints and fully debug your Wing applications!

The Wing VS Code extension, breakpoints can be added to .w files, both for preflight and inflight
code and simply hit F5 to debug. The built-in debugger can now be used to inspect and step through
the code.

See PR by Mark

Local simulation of serverless function concurrency

We've made improvements to how cloud.Functions are executed in the Wing Simulator so they
functionally behave like FaaS providers. We are now running each function within an isolated child
process and manage its concurrency limits.

The concurrency option that can be passed to cloud.Function or any resource that takes an
inflight closure can be used to control these limits.

For example:

bring util;
bring cloud;

let queue = new cloud.Queue();

let handler = inflight (x) => {
  log("only one at a time: {x}");
};

queue.setConsumer(handler, concurrency: 1);
//                         ^^^^^^^^^^^^^^

test "push 10" {
  for i in 0..10 { queue.push("{i}"); }
  util.waitUntil(() => { return queue.approxSize() == 0; });
}

When running this with concurrency: 1, the code finishes after ~1.5s
When running with concurrency: 10, the code finishes after 0.5s

See PR by Chris

A new project template for React with Vite

We are continuing to add new project templates for various types of projects, and we've recently
created one for the infamous combination of React with
Vite tooling.

Check out this guide
for a detailed tutorial or just get started with:

mkdir my-project && cd my-project
wing new react-vite

Adding UI to Wing classes through `bring ui`

It is now possible to associate simple user interface elements with Wing preflight classes through
the ui module. These elements can dynamically interact with your system via simple implementations
of inflight closures:

bring ui;

class MyResource {
  counter: cloud.Counter;

  new() {
    this.counter = new cloud.Counter();

    new ui.Button("Cool Button", inflight () => {
      this.counter.inc();
    });

    new ui.Field("Counter", inflight () => {
      return "{this.counter.peek()}";
    });
  }
}

Now, when a MyResource node is selected in the Wing Console, you'll see this in the inspector
pane:

We are adding more UI elements and can't wait to see what people will build with this!

See PR by Cristian

Exposing cloud endpoints for webhook development

When developing applications that react to requests from other services via webhooks such as bots
and extensions, it is often very valuable to be able to accept requests from these external systems
during development.

So now, every cloud.Endpoint in your application (either explicitly or implicitly defined via a
cloud.Api, cloud.Website, etc) can be exposed and requests will be tunneled into the local
simulator:

This is an experimental feature and still needs some ironing out, and we would love to hear what
You think about it.

See PR by Elad

Explicit lifting of preflight objects

When inflight code is referencing a preflight object, the object is lifted and the operation
performed on the object is qualified in order to be able to determine things like IAM permissions.

In many cases, the Wing compiler can automatically qualify the lift. For example, in the code below,
it is clear that the inflight closure performs a push operation on the lifted queue object:

bring cloud;

let myQueue = new cloud.Queue();

inflight () => {
  myQueue.push("hello");
};

But since the Wing compiler currently does not perform symbolic execution, there are cases where
it's currently impossible for the compiler to qualify the lift. For example, if I assign myQueue
to a new variable called (yourQueue), we will get the following error:

bring cloud;

let myQueue = new cloud.Queue();

inflight () => {
  let yourQueue = myQueue;
  yourQueue.push("hello");
//^^^^^^^^^ Expression of type "Queue" references an unknown preflight object, can't qualify its capabilities.
};

To overcome this limitation, a new builtin lift() can be used to explicitly qualify the lifts:

bring cloud;

let myQueue = new cloud.Queue();

inflight () => {
  lift(myQueue, ["push"]);

  let yourQueue = myQueue;
  yourQueue.push("hello");
};

New builtin lift function allows you to lift preflight objects for the current inflight closure.

This syntax is still under discussion, but we wanted to make sure this is not blocking users.
Check out the RFC and join the conversation.

See PR by Yoav

Changes to default object identifiers

When creating preflight
objects in Wing, each object
gets an identifier which is unique to its scope of definition. These identifiers are essential for
producing deterministic unique addresses for cloud resources when they are provisioned.

The default identifier for objects in Wing is the name of the class. In the following example, the
identifier of the bucket is simply "Bucket":

new cloud.Bucket();

Previously, the default identifier included the namespace of the class, so in the above example the
identifier was "cloud.Bucket", but since namespaces can now be aliased (bring cloud as my_cloud), this resulted in unstable defaults, which can have dire implications on infrastructure.

By the way, Wing also has dedicated syntax (as ID) to determine the identity of an object in case
there are multiple instances of the same type or you want to be more explicit:

new cloud.Bucket() as "my_bucket";

We are discussing potentially changing this
syntax, so let us know what you think.

See PR by Elad

Implicitly loaded platform extensions

Platform extensions are one of the most powerful
capabilities of Wing. They can determine how cloud resources are implemented in your cloud
environment, validate that your application adheres to an organizational policy or inject best
practices and common patterns "under the hood".

So far, it was possible to configure Wing to use a platform provider using an explicit --platform
switch passed to the Wing CLI, but we've seen a need for modules or libraries to be able to provide
platform extensions without having to require explicit configuration.

To that end, as Wing compiles your code, any wplatform.js files found will be loaded automatically
as a platform. This occurs after explicit ones like -t tf-aws and also applies to any winglibs
used by your applications.

One of the currently explored use cases is the ability for libraries to expose their own platform
parameters.

For example, the eventbridge winglib
exposes a platform parameter called eventBridgeName to allow developers to connect to an existing
EventBridge bus:

wing compile -t @winglang/platform-awscdk -v eventBridgeName="my-bus" main.w

Here's a sneak peak on how this platform extension is implemented:

module.exports.Platform = class {
  parameters = {
    type: "object",
      properties: {
        eventBridgeName: {
        type: "string",
      },
    },
  };
};

See PR by Hasan

Standardize cron expressions

A cron expression like * * * * * is valid in a unix-based crontab, but not in AWS. On the other
hand, * * * * ? is valid in AWS, but not elsewhere.

Now, Wing will expect cron expression to match the standard syntax, and will automatically convert
it to the AWS syntax when deploying to AWS:

bring cloud;

new cloud.Schedule(cron: "* * * * *");

See PR by Marcio

Goodies from the Wingly Update

The Wingly Update is our corky bi-weekly stream where we share
the latest developments of the project, chat with folks from the cloud industry, geek out and
celebrate the beauty of the cloud.

If you haven't been able to catch our show, you can find the complete stack of all our episodes
here.

Here are a few goodies we curated from recent shows:

The recent CHANGELOG with @MarkMcCulloh
An overview of where we are in our journey towards Wing for TypeScript.
A chat with Allen Helton about Texas, life, conferences, cowboys and his love for serverless.
A fun chat with Michael Antonio from AWS about his journey at Microsoft and Amazon, IAC, CDK and computing nostalgia.

Wing in the Wild

This is a new section in our magazine where we curate content about Wing from the world wide and
wonderful web:

An awesome overview video of Wing by Amichai Mantinband.
Ayush Thakur wrote about his experience building a NextS app with a Wing backend.
Asher Sterkin's explored an implementation of production-grade REST APIs in Wing as well as used Wing to manage multiple AWS environments.

Community Events

You can find details for all our events in the Wingnuts
Calendar,
amongst them:

Winglang Community Meeting is our bi-weekly gathering where members of our community showcase cool apps, demos, and other projects.
Monday Office Hours is our bi-weekly opportunity for you to share your feedback, thoughts, and concerns, or simply drop by to say hi.

Summary

That's it for this edition!

You are invited to join the Wing Slack! Come say hello and hang out
with fellow Wingnuts! Give winglang.io a visit and take Wing out for a spin.
If you're not already, stay updated on the latest changes in our
repo.

Looking forward to entertaining you in your next flight!

- The Wing Team

Cloud, why so difficult? 🤷‍♀️

Elad Ben-Israel — Wed, 24 Jan 2024 17:07:13 +0000

A manifesto for cloud-oriented programming.

Don't get me wrong, I love the cloud! It has empowered me to build amazing things, and completely changed the way I use software to innovate and solve problems.

It's the "new computer", the ultimate computer, the "computerless computer". It can elastically scale, it's always up, it exists everywhere, it can do anything. It's boundless. It's definitely here to stay.

But holy crap, there is no way this is how we are going to be building applications for the cloud in the next decade. As the cloud evolved from "I don't want servers under my desk" to "my app needs 30 different managed services to perform its tasks", we kind of lost track of what a great developer experience looks like.

Building applications for the cloud sometimes feels like spilling my kids' bag of unused Lego blocks all over the living room floor and trying to build a castle. After going through torn up play cards, scary Barbie-doll heads, and leaking dead batteries, you read the instructions the millionth time, only to realize you ended up building basically the same thing you've built last time.

Sorting Lego blocks is fun! It passes the time with the kiddos. It even feeds my OCD… But hell, this is not how I want to build professional software!

Let me try to describe what I and my developer friends are struggling with.

I want to focus on creating value for my users

When I build professional software, I want most of my time to be spent within the functional domain of my application, instead of non-functional mechanics of the platform I use.

It doesn't make sense that every time I want to execute code inside an AWS Lambda function, I have to understand that it needs to be bundled with tree-shaken dependencies, uploaded as a zip file to S3 and deployed through Terraform. Or that in order to be able to publish a message to SNS, my IAM policy must have a statement that allows the sns:Publish action on the topic's ARN. And does every developer need to understand what ARNs are at all?

All that stuff doesn't have anything to do with the value I am trying to create for my users. It's pure mechanics. Can we get rid of it?

I want to be independent

One of the most frustrating and flow killing situations for me as a developer is when I have to stop and wait for someone or something in order to continue.

It's like gliding happily in the air, enjoying the view, beautiful music in the background, and suddenly, BAM! A concrete wall.

This concrete wall takes many shapes and sizes when you build applications for the cloud. It's the DevOps person with an endless ticket queue; it's the IAM policy that needs to be updated; it's the deployment failure that only the external part-time consultant knows how to debug; It's the endless backlog of missing knobs and APIs in the internal platform that we hoped will change everything.

These barriers are frustrating because they force me to switch context, to apply "temporary" security policies and to invent ugly hacks that I don't want to talk about. It's a broken world.

I want to be independent. I want to be able to get things done, to stay in the flow. I want to improve the world one commit at a time, and move on to the next thing after I am finished. I want that dopamine rush of completing a task, not the shameful feeling of yet another unfinished thread.

I want instant feedback

I said I want independence, but don't mistake that for a belief that I write perfect code. Which is why I want to write code with a pencil, not with a pen.

Some developers can spend a full day coding without even invoking their compiler, and at the end of the day, they compile and deploy, and it just works.

I admire them, but I am not that type of developer. No sir. For me it's about iterations, iterations, iterations. I start small, sketch with a light pencil, take a look, erase a bunch of stuff, draw a thicker line, take a step back, squint, draw more and erase more, and take another look, rinse and repeat.

This is why, for me, the single most important thing is iteration speed. The sooner I can run my application and test it, the faster I can go back and iterate. This is where my flow is.

When I started programming, I used Borland C++. It used to take about 100ms to compile and run a program on an IBM PC AT machine (TURBO ON). An average iteration cycle in the cloud takes minutes. Minutes! Sometimes dozens of minutes!

Here's how an iteration looks like in the cloud today: I make a change to my code; then I need to compile it; deploy it to my test account; find my way around the management console to actually trigger it; wait for it to run and go search for the
logs on another service. Then I realize there is an error response that tells me that I'm stupid, because how come I didn't know that I have to pass in Accept-Content: application/json, because otherwise I get some weird result called "XML" that I have no idea what to do with (just kidding, XML is great, no really). Now all over again...

So "write unit tests", you say, in a patronizing attempt to justify the current reality. "Great developers write unit tests". OK! So now I need to take my code, which makes about 20 external API calls, and somehow mock out the API responses by copying and pasting them from outdated documentation, only to figure out that my requests are rejected because I am missing some implicit action in my IAM security statement. We've all been there.

To be honest, give me the developer experience of the 90s. I want to make a change, and I want to be able to test this change either interactively or through a unit test within milliseconds, and I want to do this while sitting in an airplane with no WiFi, okay? (we didn't have WiFi in the 90s).

So this is just a rant?

Hell no! I am a programmer. I sometimes feel like I've been writing software since birth. I've been doing it in socially perilous times, when being a computer geek was not cool.

What I have always loved about being a developer is that if I was not happy with my tools, I could make my own. Building tools is in our DNA, after all - humans have been building tools for over a million years.

And I am not happy with my tools.

In April 2022, I joined forces with Shai Ber, a good friend and a former Microsoft colleague, and we founded [Wing] with the mission to unlock the cloud for developers. We've assembled an incredible crew of beautiful geeks who share our passion for developer experience and open-source and started our journey to empower developers (i.e. ourselves) to solve these fundamental problems.

Compilers to the rescue

So how are we going to solve all of these problems at once?
We are building a programming language for the cloud.

"A programming language!?," you ask. "Doesn't the world have enough programming languages?," "Isn't it really hard to write a compiler?," "What are the chances that developers will want to learn a whole new language?," "Why can't you hack into an existing language toolchain, squint your eyes tight enough and call it a day?"

I am not one to build programming languages on a whim. In fact, I've spent the last five years building the AWS CDK, which is a multi-language library that addresses some of the challenges I am talking about by allowing developers to define cloud infrastructure using their favorite programming language.

To "meet developers where they are" is a beautiful tenet of AWS, and of the CDK, and inspired us to create awesome technology such as JSII and constructs.

But sometimes, "where they are" is not a good enough model for creating the desired experience.

Defining infrastructure with code does enable us to create a higher-level of abstraction, but as long as my application code needs to interact with this infrastructure, the abstraction becomes too leaky. I'm yanked back down to having to understand more than I need to, and I have to be an expert in things like IAM, VPC, ALB, EBS and basically more TLAs than I would ever want to keep in my head.

The languages we use today are all designed around the idea that the computer is a single machine. They've reached the point in which they are able to offer us solid abstractions over these machines. They abstract away the CPU, memory, file system, process management and networking. As a developer, I don't have to care how a file is laid out on disk, or even how much memory I need for my hash map. I simply write readFile() or new Dictionary() and go about my day. Yes, it's not a bad idea for me to have some sense of what's happening under the hood, but I am not forced to.

Most of these languages also offer me type-safety. When I call a function with the wrong number of arguments, I get yelled at by my compiler. I don't have to wait until my application is running only to realize I forget an argument, or passed in the wrong type.

In the cloud, I'm on my own. Every time my code needs to interact with a cloud resource or a service - and that's happening more and more as the industry evolves - I have to leave the comfort and safety of my programming language. I must jump outside the boundaries of the machine and into the wild wild west of the internet, and my compiler is none the wiser.

And suddenly, it's almost painfully obvious where all the pain came from. Cloud applications today are simply a patchwork of disconnected pieces. I have a compiler for my infrastructure, another for my functions, another for my containers, another for my CI/CD pipelines. Each one takes its job super seriously, and keeps me safe and happy inside each of these machines, but my application is not running on a single machine anymore, my application is running on the cloud.

The cloud is the computer.

Wing, a cloud-oriented programming language

When new programming paradigms emerge, it takes languages time to catch up. I used to love building object-oriented code in C, but it was a leaky abstraction. I had to understand how objects are laid out in memory, how V-tables work, and remember to pass the object as the first argument for each function. When programming languages started to support object-oriented concepts as first-class citizens, this paradigm was democratized, and today most developers don't even know what V-tables are, and the world keeps spinning.

Wing, or winglang if you want to be cute about it, has all the good stuff you would expect from a modern, object oriented, strongly-typed and general-purpose language, but it also includes a few additional primitives designed to support the distributed and service-based nature of the cloud as first-class citizens.

Check it out

We have been working on Wing for almost a year now, and I am excited to invite you to check it out and let me know what you think. While still in Alpha and not yet ready for production use, it's already possible to build some real applications with it.

Please star ⭐ Winglang

Forem: Elad Ben-Israel

Local simulation of serverless function concurrency

So what is Wing again?

In today's issue

Debugging with breakpoints

Local simulation of serverless function concurrency

A new project template for React with Vite

Adding UI to Wing classes through bring ui

Exposing cloud endpoints for webhook development

Explicit lifting of preflight objects

Changes to default object identifiers

Implicitly loaded platform extensions

Standardize cron expressions

Goodies from the Wingly Update

Wing in the Wild

Community Events

Summary

Cloud, why so difficult? 🤷‍♀️

I want to focus on creating value for my users

I want to be independent

I want instant feedback

So this is just a rant?

Compilers to the rescue

Wing, a cloud-oriented programming language

Check it out

Adding UI to Wing classes through `bring ui`