DEV Community: Markus Siering

Solved: How to bundle Python apps within AWS CDK

Markus Siering — Mon, 28 Sep 2020 11:21:00 +0000

Hi 👋

💡 Solution at the end 🙈

So I've setup a basic TypeScript project with the AWS-CDK by running cdk init app --language=typescript. Now I'd like to use some lambda functions written in Python because… math 🤓

I am using @aws-cdk/aws-lambda-python to declare these functions like so:

import * as cdk from "@aws-cdk/core"
import * as lambdaPython from "@aws-cdk/aws-lambda-python"

export class MyStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    new lambdaPython.PythonFunction(this, "MyFunction", {
      entry: "lib/lambda/my_function",
    })
  }
}

And within the lib/lambda/my_function folder, there is the index.py with a handler function which are both the defaults for the package.

But running cdk synth results in this:

$ cdk synth
[Status 1] stdout:


stderr: Cannot connect to the Docker daemon. Is the docker daemon running on this host?

I have no idea about how Docker needs to be setup. Unfortunately, I cannot find any info on this within the AWS documentation. Does anyone know what I'd have to do to get the (correct? 😅) Docker container running?

Solution

Use the latest Docker version, maybe? 😅 I had a very old one (1.11.XX) running and now it works by installing the latest Docker Desktop (19.X.X) 🤷

So overall: This is really nice, you can very easily mix TypeScript and Python in such a setup. Awesome! 🚀 😄

A modern build for CSS

Markus Siering — Wed, 04 Mar 2020 19:39:55 +0000

This is a post I wrote about a year ago on my website. I'm removing the posts from there (since I only wrote one other post), so I figured I'd move this piece here :)

A modern build for CSS

In the last few days, I thought about how we could future-proof and optimise CSS builds for today's web applications. You may be familiar with the idea of a modern build for Javascript. Phil Walton outlined this in "Deploying ES2015+ Code in Production Today". We should adopt this for CSS as well.

Why would you want a modern build for CSS?

While using some of the latest CSS features, I noticed how dreadful it can be to optimise for older browsers. Where "older browsers" means IE11 most of the time. Building with this browser in mind creates some problems.

Resorting to non-optimal language features

This affects mainly the usage of CSS Custom Properties and CSS Grid. Both have quite some implications on how you architect your CSS – and your HTML.

With CSS Grid, your markup can be way simpler while creating your layout than you're used to with e.g. flexbox or floats. You'll write that differently when IE11 comes into play.

Maybe you decide to use CSS Grid, providing fallbacks for IE11. With auto-placement not working in that browser, I'm pretty sure you wouldn't use it to it's full potential, though.

With Custom Properties, you'll need some PostCSS tooling that takes care of transforming the properties into "real" values. Which either robs the Custom Properties of their original strength. Or doubles the lines of CSS for them if it provides a fallback value.

Also, you probably won't even start to think about e.g. the "logic fold" Mike Riethmuller lines out. Similar to the grid auto-placement, this robs you of great opportunities to write cleaner code.

The "weakest" browser determines the speed for all

If you build any web project with IE11 in mind, you're bound to build non-optimal CSS for other browsers. Catering to legacy browsers, your HTML and CSS code will include unnecessary parts. You could omit these parts when caring for evergreen browsers only.

Also, your project might at some point drop support for IE11 because the usage fell below a certain threshold. Let's be honest: No one will refactor the code to apply the latest & greatest CSS features and remove the unnecessary just-for-IE11-parts. Ever. So your product will still be kind of optimized for IE11, even though you actually do not support it anymore.

Bundle size for CSS increases

As you probably got from the first two points, building HTML/CSS with IE11 in mind will not only hold you back regarding features. Autoprefixing the new stuff will also grow your CSS bundle. You'll have browser prefixes in there. Quite some additional rules for satisfying CSS Grid requirements. And maybe also doubled declarations for Custom Properties.

Now, CSS "normally" has bundle sizes way smaller than whatever Javascript you ship. Nevertheless, why should we shrug that off as a "necessary evil"? It would be good to optimize here as well.

Separation of concerns pain

Like I mentioned above, should you ever kick IE11 out of your setup, you'll still be left with CSS and probably HTML that is unnecessary since you optimized for IE11 initially. From an architectural perspective, it would make way more sense to separate the special solutions for IE11 somewhere else than in your default CSS.

For the HTML markup, this of course poses some complicated if not impossible to solve problems. I guess that's a very, very good moment to mention this website

I'd argue to ship adjustments within separate IE11 files, making the interface work as good as possible within IE11.

How could this work?

I hope the reasons lined out above did convince you that a modern build for CSS is a useful thing. Now how could we get this to work? I haven't built anything so far, so I do not have a working example for this (yet). So please take these ideas with a grain of salt. In my head, they seemed logical and doable. Which of course doesn't mean anything, I don't trust my brain and neither should you. Still, let's have a look.

Bundling the CSS

Similar to the Javascript modern build, I could imagine having two different builds with different target browsers passed to the autoprefixer.

Regarding the separation of ~~concerns~~ pain explained above, you could use e.g. style.css for all browsers and something.ie11.css for additional IE11 CSS. That would contain the extra CSS necessary to make IE11 behave nicely. This is the structure I could imagine:

components/
--| button
---------| index.js
---------| style.css
---------| corrections.ie11.css

This naming convention would make it quite easy to target the different files for both bundles.

In the extra bundle step, heavy autoprefixing would be involved. For example, you'd probably need to use the rather "aggressive" postcss-css-variables instead of postcss-custom-properties which takes a more careful approach on resolving Custom Properties. The autoprefixing for CSS Grid has made great progress which should prove very useful.

The missing autoplacement functionality could be solved by using some rather elaborate nth-child selectors. This is currently discussed within the autoprefixer repo as well, so maybe even that part can be solved automatically someday.

Shipping the CSS bundles

If the bundling is setup, we'd need to make sure that one of these files only gets shipped to IE11 and other browsers won't use it.

In my naive mind (and in my VirtualBox), this syntax worked at least in Chrome and IE11 to load the second stylesheet only in IE11:

<link rel="stylesheet" href="style.css" />
<link
  rel="stylesheet"
  media="only screen and (-ms-high-contrast: active) and (-ms-high-contrast: none)"
  href="ie11.css"
/>

I only did a quick test for this, so I'm not sure if this is really working in the exclusive way I imagine it does. Also, I didn't have the time to check whether the CSS is downloaded anyways – which shouldn't happen due to the media rules. But again, that's currently only my naive mind without testing it.

If this would not work, I'd have no problem with injecting the extra IE11 CSS via JS. Detecting the browser in this case seems like an okay thing to do.

Cleanup in a future far far away

At some point, when you decide to stop shipping CSS for IE11, you would "just" remove all *.ie11.css files. Then remove the extra build step. And then you'd throw a giant party and of course invite me. Thanks already!

Now what?

This idea is very rough in it's current state. Since that's so, I have not setup any kind of project testing it. Still, I'd love to get feedback:

Is this a good idea? Is it not? Why?
What do you think would work?
Where does this approach fail?
How could the implementation look like?

Adventures in Vue's render function

Markus Siering — Wed, 08 Jan 2020 21:53:28 +0000

In the last days, I built my first Vue component using a render function instead of the common <template> tag.

Now, my impostor syndrome tells me that the things I've learned while doing so are totally obvious to anyone else using Vue.

Maybe that's the case – and maybe it isn't. I hope you can take something away from this story. Or tell me where I've overseen obvious flaws in the solution 🙈

Why did I use the render function?

What I've build is a tabs component. I had a look at different existing solutions for that. I also talked with colleagues about a nice interface for such a component. We all liked the way Vuetify handles the case. You just throw in some <Tab>s and the same number of <TabItem>s and the <Tabs> component magically takes care of toggling the content and active states:

<AwesomeTabs>
  <MyTab>Tab #1</MyTab>
  <MyTab>Tab #2</MyTab>
  <MyTab>Tab #3</MyTab>
  <MyTabContent>Content #1</MyTabContent>
  <MyTabContent>Content #2</MyTabContent>
  <MyTabContent>Content #3</MyTabContent>
</AwesomeTabs>

With a structure like this, you can't simply throw everything into the default slot of a Vue template. You do not want to render the <Tab>s and <TabItem>s next to each other. Instead, this needs some logic to toggle an active state for the currently selected <Tab> and only show the currently selected <TabItem>.

How the render function works

Of course, you should check the Vue documentation on render functions. Quick TL;DR here:

The render function returns whatever you want to render, either within your <script> block of a .vue single file component (no <template> tag needed then) or from a pure .js file.
Into render, you'll pass (and use) the createElement function (often shortened to h) to create each VNode (virtual nodes) that Vue then handles.
Everything you normally do within the template tag is basically sugar coating for the actually used render function.

Simple example:

render(createElement) {
  return createElement(
    'h1', // the element you want to render, could also be a Vue component
    {
      // this is the options object which is… hehe… optional, e.g.:
      class: 'ohai-css',
      attrs: {
        id: 'mightyID'
      },
      on: {
        click: this.handleClick
      },
    }, 
    'Hello world!' // the content – a text string or an array of other VNodes
  ) 
}

So let's have a look at how I fought my way towards a working tabs component. We'll take my AHA moments as guideposts.

`this.$slots.default` is always filled!

Something I had never thought about (but makes sense): Even if you have a "closed" component, you can throw any content into it and it is available under this.$slots.default. Check the HelloWorld.vue in this code sandbox. The content is not rendered in the component, but it is there.

With that, you can easily filter the components as needed – in my case, it was enough to check for the name of the component:

const tabItems = this.$slots.default
  .filter(item => item.componentOptions.tag === "MyTab")

Don't manipulate, duplicate!

So I had access this list of components within my Tabs. My first though was: Nice, I'll just™ split this up into the tab navigation and the tab content, slap an index plus an onClick handler onto the tab navigation items and off we go.

That totally did NOT work 😄

What I had to do instead was to take the list of navigation items, create a new element for each one and add the necessary props to that component instance:

const tabItems = this.$slots.default
  .filter(item => item.componentOptions.tag === "MyTab") // filter for navigation items
  .map((item, index) =>
    h( // render a new component…
      MyTab, // of the same type
      {
        props: { // pass props
          index,
          isActive: this.selectedIndex === index // selectedIndex is declared within data
        },
        on: {
          onClick: this.switchTab // which takes the emitted index and sets selectedIndex to that
        }
      },
      item.componentOptions.children // use content from the original component
    )
  );

My uneducated, clueless guess here is: The components are already rendered. Vue doesn't let you touch them or alter their props within the render function because that will break… the internet? 😄

You have to render completely new component instances instead. This most certainly makes sense – if you know why, please explain in the comments 😉

Reading documentation carefully actually helps!

Having achieved all of this, I was very happy and wanted to render the tab navigation and the current content like this:

return h(
  "div", // render a surrounding container
  [ // with children
    h("ul", { class: "tabListNav" }, tabItems), // tab navigation
    h('main', tabContent) // current tab content
  ])

Aaaand… no content was rendered ¯\_(ツ)_/¯

So I re-read the createElement arguments part of the documentation again. And of course, it was a very simple fix: You can either pass a string as the child of an element. Or an array of items. Even if you just want to render one item, you have to put it into an array. Spot the difference:

return h(
  "div", // render a surrounding container
  [ // with children
    h("ul", { class: "tabListNav" }, tabItems), // tab navigation
    h('main', [tabContent]) // current tab content passed in an array
  ])

🎉 With all of this, we have a nice tab component that fulfills everything I needed:

Render a tab navigation
Render the correct content
Easy to use because state handling etc. is tugged away in <AwesomeTabs>

Of course, you could add a great deal of functionality, but I don't need to 😄

Here's a code sandbox with everything in it:

DEV Community: Markus Siering

Solved: How to bundle Python apps within AWS CDK

Solution

A modern build for CSS

A modern build for CSS

Why would you want a modern build for CSS?

Resorting to non-optimal language features

The "weakest" browser determines the speed for all

Bundle size for CSS increases

Separation of concerns pain

How could this work?

Bundling the CSS

Shipping the CSS bundles

Cleanup in a future far far away

Now what?

Adventures in Vue's render function

Why did I use the render function?

How the render function works

this.$slots.default is always filled!

Don't manipulate, duplicate!

Reading documentation carefully actually helps!

`this.$slots.default` is always filled!