I recently worked on a small TypeScript project which I wanted to deploy as a Lambda to AWS.
My project had multiple files and some npm dependencies.

I found some resources online, but none of them really hit the spot. Some didn’t explain how to include the node_modules, some didn’t explain how to do it with TypeScript and some just handled a single file.

In this post, I’ll describe how to prepare the project for deployment and show a detailed example of doing it using Github Actions.

Project Structure

Let’s assume our project structure looks like this:

├── package.json
├── tsconfig.json
├── node_modules
│    ├── module_1
│    ├── module_2
│    └── etc..
└── src
     ├── index.ts
     └── utils.ts

This is our tsconfig.json :

And index.ts contains as the main handler, and uses utils.ts, something like this:

Problem

AWS Lamda can only run js files!
Also, AWS Lambda can’t install node_modules for us.

With the default settings, AWS Lambda supports either:

• Deploying a single index.js file directly.
• Upload a zip file containing all the project files, which has the index.js in the zip root. So we need to zip the project correctly, without including the parent directory.
  We also need to make sure the node_modules are part of this zip file.

Prepare for deployment

1. Build the project

We will use TypeScript’s tsc command to transpile the project into js files.
After building, this will be our project structure:

├── package.json
├── tsconfig.json
├── node_modules
├── dist
│    ├── index.js
│    └── utils.js
└── src
     ├── index.ts
     └── utils.ts

2. Move node_modules to dist folder

As mentioned before, AWS Lambda can’t install the node_modules for us, so we need to assure they are located correctly before creating our zip file.

3. ZIP

The project needs to be zipped in the required structure, without the parent directory. The easiest way I found to do it, is to run the following command from the project root:

$ (cd dist && zip -r ../function.zip .)

The zip is now ready for deployment.

Deploy using Github Actions

The deployment part will be done using appleboy/lambda-action, and can be easily substituted with a corresponding AWS CLI command, which comes preinstalled on Github Actions CI machines.

Here’s a detailed example of a Github action:

That’s it! Your Lambda is now ready for work.

Easily deploy TypeScript project to AWS Lambda using Github Actions was originally published in Aspecto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Wow, lot’s of abbreviations in the title, let’s get things straight first:
• EBS— Elastic Block Storage.
• CDK — Cloud Development Kit.
• ECS — Elastic Container Service.

I won’t go into long intros, if you’re here you probably know why.
This post will walk you through the required steps to get EBS working, the same way we achieved this at Aspecto.
I’d be using JS CDK snippets.
Notice EBS will only work with EC2 launch type (Fargate won’t support it).

Steps Overview:
• Install rexray/ebs docker plugin using “UserData”.
• Give your EC2 instance the required roles.
• Create and attach EBS volume.

First, we need the get a hold of the cluster AutoScalingGroup:

Install REX-Ray EBS plugin

Now that we have the AutoScalingGroup, we can attach “UserData” to it.
UserData is basically a bash script that runs when the EC2 instance is instantiated.
This script will install the REX-Ray EBS plugin and will reset our ECS after.

Give your EC2 instance the required roles

Your EC2 gonna manage your EBS, it gonna need some roles to do it:

Attach EBS Docker Volume to your TaskDefinition

Cool, our ECS cluster can now work with EBS, all that’s left is attaching the EBS volume and mount it to our container:

That’s it, you’re done!

Let me know in the comments below how it worked out for you, I’m here to answer every question.

Attach EBS Docker Volume to AWS ECS using CDK was originally published in Aspecto on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently worked on an npm package that is supposed to be consumed on both Node.js environment and the browser (using React/Angular/etc..).

Things started getting complicated when the node branch of the code needed to require native Node.js packages — like fs.

Consider the following (simplified) code:

When testing the module on my React + Webpack app, the app crashed:

This happened even though the node-handler file wasn’t executed, this is due to Webpack nature of creating a bundle containing all the code.

Step 1: Postpone your requires

Instead of requiring fs in the global scope, we can require it only where we actually need it, that way we won’t require it when running in the browser:

Cool! Our React app is not crashing anymore! But we do get an annoying compilation warning right now:

While we can live with a warning ⚠️ , our end users will probably won’t like this too much and will end up not installing our package.

Step 2: eval your require

This is not the most elegant solution (to say the least..), but it’s keeping Webpack quiet and your end users happy. Instead of using require('fs'), we’re gonna use eval('require')('fs'):

Good luck! May you be blessed with tons of stars 🌟

Make your npm package work on both Node.js and browser was originally published in Aspecto on Medium, where people are continuing the conversation by highlighting and responding to this story.

I gave a talk during a recent meetup at Soluto HQ — Intro to React Hooks.
While preparing for the presentation, I fell completely in love with Hooks.
Although I was skeptical at first glance, I quickly realized how easy it is to use them and how they make perfect sense.
You can really tell how much thought was put into the API and how it solves real life problems.

You can find a video of my talk attached to this post (Hebrew only… Sorry!).
In my talk I explained why we need Hooks, how they work, went over the core Hooks (useState, useEffect, useRef and useContext) and showed how to convert some of the class features into Hooks.
I also covered some other new features — memo, lazy and Suspense.

If you don’t speak Hebrew or just prefer reading over watching, I made a TL:DW (kind of a cheat sheet) on class features vs. Hooks. Enough intros… Let’s jump right to business!

Class features vs. Hooks equivalents

State

ComponentDidMount

ComponentWillUnmount

ComponentWillReceiveProps \ ComponentDidUpdate

DOM refs

this.myVar

useRef has another cool usage besides DOM refs, it is also a generic container whose current property is mutable and can hold any value, similar to an instance property on a class.
Handy, for example, to keep an interval id:

Comparing with the previous state\props

Some lifecycle method, like componentDidUpdate, provide the previous state and props.
If you really need the previous values for your Hooks, this can be imitated the following way (using yet again our good friend — useRef):

ShouldComponentUpdate

We gonna use memo for this one, while this is not a Hook, it’s still part of the class-to-functional-component migration plan:

And that is React Hooks in a nutshell. I hope you will find this helpful when writing your next functional component.

Needless to say (but I’ll say it anyway), there are a whole lot more interesting and cool ways to use Hooks. I urge you to read the awesome overview the React team posted. Don’t miss out the FAQ section!

Last but not least, here’s me in my meetup video about React Hooks.

Watch, Like, Subscribe 😉

React Class features vs. Hooks equivalents was originally published in Soluto by asurion on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every example on this post can be found here.

Have you ever had your designer hand you a cool design for your React Native app that you developed on, say, an iPhone 7 - and when you try to run it on a tablet, it looks like it was left in the dryer for too long?

That’s probably because the design was created using pixels whereas all dimensions in React Native are unitless, represented by ‘dp’ (density-independent pixels).

Simply put — the bigger your device is, the more ‘dp’ it’ll have.

When working with React Native, the iPhone 7 has a 375dp width and 667dp height and a Galaxy Tab A 8.0" Tablet (the one I’m using) has a 768dp width and 1024dp height.

So while a <View style={{width: 300, height: 450}}/> will cover most of your iPhone's screen, it will cover less than half of your tablet's screen.

So how can I make my app beautiful on the tablet as well?

Glad you asked. In this blog post, I’ll show several methods for scaling your components to different screen sizes, and which one I found to work best.

To do this, I created a small example app, and after every scaling method I’ll attach the code along with screenshots for both a tablet and an iPhone.

How it looks without scaling

So this is the component:

This is the stylesheet:

As you can see, all my stylesheet sizes are in dp units and no scaling was done.

It will end up looking like this:

That’s definitely not how we want our component to look like on a tablet (did I say dryer already?).

Method 1: Flex

If you’re not familiar with flex I urge you to read about it. For starters check this flex playground or read about it on the RN Docs.

When developing a scalable component with flex you need to convert your view’s size and its margins with proportion to the parent component. If for example your container’s width is 375 and your box’s width is 300 — the box’s width is 80% of the parent (300/375) and the margins are what left — 10% on the left and 10% on the right.

Alternatively, you can keep your margins static (represented by dp) and spread it across the available space using flex: 1.

Here’s an example of how I flexed my component. I only flexed the white box and skipped flexing the buttons because I’m lazy, but you get the point (Stylesheet stayed the same except width and height were removed from box and container):

And the result:

Flex is your best friend when creating a scalable layout, especially when wanting to spread it across the entire width or height (i.e. a list item) or when dividing a component to different sections with defined ratio. It will keep the same proportions among different devices, even when changing orientation.

While flex is an amazing tool for scaling, it’s not always enough. With flex, some components won’t scale easily and it’s limited to certain properties like width, height, margin and padding. Stuff like fontSize, lineHeight or SVG size can’t be flexed.

With that said, let’s continue to our second method.

Method 2: Viewport Units

With this method you basically convert every number you’d like to scale in your StyleSheet to a percentage of the device’s width or height.

If your device’s width is 375dp then 300dp will become deviceWidth * 0.8 (since 300/375 = 0.8), and you can also do it with smaller numbers, for example fontSize: 14 will become fontSize: deviceWidth * 0.037.

A nice and straight-forward library that can simplify this method is react-native-viewport-units.

This is the stylesheet after viewporting stuff around (Irrelevant parts were removed, component is exactly the same as the first example):

And of course, what you have all been waiting for… the result:

Note: You’ll be able to achieve more or less the same result using the new percentage support (RN 0.42 and up) or by multiplying everything with PixelRatio.get().

Besides needing to do some calculation and having weird numbers around, pretty neat and easy, right?

…but still not perfect. What if you show your designer how it looks on the tablet and he thinks the buttons are too big and the box’s width should be reduced. What can you do? If you reduce the viewports it will affect the iPhone as well.

One option is to do something like HTML’s media-query using PixelRatio. But as I said, I'm lazy and I don't want to write everything 2 or more times, what can I do?

Method 3: Scaling Utils

Here at Soluto, we wrote these 3 simple functions that make our scaling so much easier:

The purpose of these functions is to be able to take one design (from a standard mobile phone) and apply it to other display sizes.

scale function is pretty straight forward and will return the same linear result as using viewport.

verticalScale is like scale, but based on height instead of width, which can be useful.

The real magic happens at moderateScale. The cool thing about it is that you can control the resize factor (default is 0.5).

If normal scale will increase your size by +2X, moderateScale will only increase it by +X. Or if the resize factor is 0.25, instead of increasing by +2X it will increase by +0.5X.

If you want to scale a View with 300dp width, on the iPhone 7 you will get:

• scale(300) = 320
• moderateScale(300) = 310
• moderateScale(300, 0.25) = 305

On the Galaxy Tab Tablet:

• scale(300) = 300 + 360 = 660
• moderateScale(300) = 300 + 360/2 = 480
• moderateScale(300, 0.25) = 300 + 360/4 = 390

This allows us to write only once, keeping stuff roughly the same size across mobile phones without looking massive and bulky on tablets.

Anyways, enough talking. Here are the results after applying scaling utils on the original dp sizes until your designer is pleased:

Result:

As mentioned, the iPhone keeps its proportions and the tablet gets a nice, fitted feel.

You can easily add the scaling utils to your repo using my library.

To sum up, there are many different ways to scale your component, what I found to work best for me was creating the layout with flex when possible, and scaling all other parts like margins, buttons, texts and SVGs using the scaling utils.

What I didn’t cover is scaling images and handling orientation change. We’ll keep that for a different post.

I hope you found this post useful. Scaling is super important, even if your app is not for tablets. Friends don’t let friends skip scaling!

Size Matters was originally published in Soluto by asurion on Medium, where people are continuing the conversation by highlighting and responding to this story.