Noemi  Sanford

Noemi Sanford

1596108960

Cloudflare Launches Workers Unbound, Serverless with Unthrottled CPU Usage

It has been three years since Cloudflare first introduced its Cloudflare Workers, which it now describes as serverless code deployed to data centers across 200 cities in 95 countries. At the time, the focus was instead on how these JavaScript-based “service workers” ran at the edge and offered unmatched speed. Now, the company is releasing Workers Unbound, a serverless platform that it says delivers “unparalleled” flexibility, performance, security, ease of use, and pricing, and the focus has changed.

“Edge computing, that’s the icing on top of the cake. That’s not what people wanted to start with. What they really wanted was just a simple platform where they could write code, not think about it, and it just worked,” Cloudflare CEO Matthew Prince told The New Stack. “What we got wrong three years ago, and I think what almost every edge computing platform has gotten wrong over the years, was they lead with speed. That’s, again, the icing on top, it’s not what a really great serverless platform is.”

Instead, Prince said, what teams and developers really want from serverless is cost efficiency, ease of use, and most importantly, compliance.

“The thing that is actually even more important than ease of use is actually compliance. Not very sexy, it’s not very fun to talk about, but if your general counsel or your CIO says you must do X or you can’t do Y, that really ties the developers hands,” said Prince. “So compliance is a really important piece. And I actually think that that’s going to be the killer feature of any edge computing platform going forward.”

Whereas Cloudflare Workers were limited with certain restrictions regarding things like CPU time, memory usage, and program size, Workers Unbound are left comparatively unrestrained, with unthrottled CPU usage, automatic scaling, and the ability to “run heavy workloads without having to worry about overly restrictive CPU constraints.” This allows users to perform more complex tasks than with Workers, while at the same time spending less. According to the company, Workers Unbound, for the same workload, “can be 75 percent less expensive than AWS Lambda, 24 percent less expensive than Microsoft Azure Functions, and 52 percent less expensive than Google Cloud Functions.”

Prince explained that there were a couple factors that made Workers Unbound so much cheaper than its competitors.

#serverless #news

What is GEEK

Buddha Community

Cloudflare Launches Workers Unbound, Serverless with Unthrottled CPU Usage
Leonard  Paucek

Leonard Paucek

1656280800

Jump to Local IDE Code Directly From Browser React Component

React Dev Inspector

Jump to local IDE code directly from browser React component by just a simple click

This package allows users to jump to local IDE code directly from browser React component by just a simple click, which is similar to Chrome inspector but more advanced.

View Demo View Github

Preview

press hotkey (ctrl⌃ + shift⇧ + commmand⌘ + c), then click the HTML element you wish to inspect.

screen record gif (8M size):

Jump to local IDE code directly from browser React component by just a simple click

Installation

npm i -D react-dev-inspector

Usage

Users need to add React component and apply webpack config before connecting your React project with 'react-dev-inspector'.

Note: You should NOT use this package, and React component, webpack config in production mode


 

1. Add Inspector React Component

import React from 'react'
import { Inspector, InspectParams } from 'react-dev-inspector'

const InspectorWrapper = process.env.NODE_ENV === 'development'
  ? Inspector
  : React.Fragment

export const Layout = () => {
  // ...

  return (
     {}}
      onClickElement={(params: InspectParams) => {}}
    >
     
       ...
     
    
  )
}


 

2. Set up Inspector Config

You should add:

  • an inspector babel plugin, to inject source code location info
    • react-dev-inspector/plugins/babel
  • an server api middleware, to open local IDE
    • import { launchEditorMiddleware } from 'react-dev-inspector/plugins/webpack'

to your current project development config.

Such as add babel plugin into your .babelrc or webpack babel-loader config,
add api middleware into your webpack-dev-server config or other server setup.


 

There are some example ways to set up, please pick the one fit your project best.

In common cases, if you're using webpack, you can see #raw-webpack-config,

If your project happen to use vite / nextjs / create-react-app and so on, you can also try out our integrated plugins / examples with

raw webpack config

Example:

// .babelrc.js
module.exports = {
  plugins: [
    /**
     * react-dev-inspector plugin, options docs see:
     * https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
     */
    'react-dev-inspector/plugins/babel',
  ],
}
// webpack.config.ts
import type { Configuration } from 'webpack'
import { launchEditorMiddleware } from 'react-dev-inspector/plugins/webpack'

const config: Configuration = {
  /**
   * [server side] webpack dev server side middleware for launch IDE app
   */
  devServer: {
    before: (app) => {
      app.use(launchEditorMiddleware)
    },
  },
}


 

usage with Vite2

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/vite2

example vite.config.ts:

import { defineConfig } from 'vite'
import { inspectorServer } from 'react-dev-inspector/plugins/vite'

export default defineConfig({
  plugins: [
    inspectorServer(),
  ],
})


 

usage with Next.js

use Next.js Custom Server + Customizing Babel Config

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/nextjs

in server.js, example:

...

const {
  queryParserMiddleware,
  launchEditorMiddleware,
} = require('react-dev-inspector/plugins/webpack')

app.prepare().then(() => {
  createServer((req, res) => {
    /**
     * middlewares, from top to bottom
     */
    const middlewares = [
      /**
       * react-dev-inspector configuration two middlewares for nextjs
       */
      queryParserMiddleware,
      launchEditorMiddleware,

      /** Next.js default app handle */
        (req, res) => handle(req, res),
    ]

    const middlewarePipeline = middlewares.reduceRight(
      (next, middleware) => (
        () => { middleware(req, res, next) }
      ),
      () => {},
    )

    middlewarePipeline()

  }).listen(PORT, (err) => {
    if (err) throw err
    console.debug(`> Ready on http://localhost:${PORT}`)
  })
})

in package.json, example:

  "scripts": {
-    "dev": "next dev",
+    "dev": "node server.js",
    "build": "next build"
  }

in .babelrc.js, example:

module.exports = {
  plugins: [
    /**
     * react-dev-inspector plugin, options docs see:
     * https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
     */
    'react-dev-inspector/plugins/babel',
  ],
}


 

usage with create-react-app

cra + react-app-rewired + customize-cra example config-overrides.js:

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/cra

const { ReactInspectorPlugin } = require('react-dev-inspector/plugins/webpack')
const {
  addBabelPlugin,
  addWebpackPlugin,
} = require('customize-cra')

module.exports = override(
  addBabelPlugin([
    'react-dev-inspector/plugins/babel',
    // plugin options docs see:
    // https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
    {
      excludes: [
        /xxxx-want-to-ignore/,
      ],
    },
  ]),
  addWebpackPlugin(
    new ReactInspectorPlugin(),
  ),
)


 

usage with Umi3

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/umi3

Example .umirc.dev.ts:

// https://umijs.org/config/
import { defineConfig } from 'umi'

export default defineConfig({
  plugins: [
    'react-dev-inspector/plugins/umi/react-inspector',
  ],
  inspectorConfig: {
    // babel plugin options docs see:
    // https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
    excludes: [],
  },
})


 

usage with Umi2

Example .umirc.dev.js:

import { launchEditorMiddleware } from 'react-dev-inspector/plugins/webpack'

export default {
  // ...
  extraBabelPlugins: [
    // plugin options docs see:
    // https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
    'react-dev-inspector/plugins/babel',
  ],

  /**
   * And you need to set `false` to `dll` in `umi-plugin-react`,
   * becase these is a umi2 bug that `dll` cannot work with `devServer.before`
   *
   * https://github.com/umijs/umi/issues/2599
   * https://github.com/umijs/umi/issues/2161
   */
  chainWebpack(config, { webpack }) {
    const originBefore = config.toConfig().devServer

    config.devServer.before((app, server, compiler) => {
      
      app.use(launchEditorMiddleware)
      
      originBefore?.before?.(app, server, compiler)
    })

    return config  
  },
}

usage with Ice.js

Example build.json:

// https://ice.work/docs/guide/basic/build
{
  "plugins": [
    "react-dev-inspector/plugins/ice",
  ]
}


 

Examples Project Code


 

Configuration

Component Props

checkout TS definition under react-dev-inspector/es/Inspector.d.ts.

PropertyDescriptionTypeDefault
keysinspector hotkeys

supported keys see: https://github.com/jaywcjlove/hotkeys#supported-keys
string[]['control', 'shift', 'command', 'c']
disableLaunchEditordisable editor launching

(launch by default in dev Mode, but not in production mode)
booleanfalse
onHoverElementtriggered when mouse hover in inspector mode(params: InspectParams) => void-
onClickElementtriggered when mouse hover in inspector mode(params: InspectParams) => void-
// import type { InspectParams } from 'react-dev-inspector'

interface InspectParams {
  /** hover / click event target dom element */
  element: HTMLElement,
  /** nearest named react component fiber for dom element */
  fiber?: React.Fiber,
  /** source file line / column / path info for react component */
  codeInfo?: {
    lineNumber: string,
    columnNumber: string,
    /**
    * code source file relative path to dev-server cwd(current working directory)
    * need use with `react-dev-inspector/plugins/babel`
    */
    relativePath?: string,
    /**
    * code source file absolute path
    * just need use with `@babel/plugin-transform-react-jsx-source` which auto set by most framework
    */
    absolutePath?: string,
  },
  /** react component name for dom element */
  name?: string,
}


 

Inspector Babel Plugin Options

interface InspectorPluginOptions {
  /** override process.cwd() */
  cwd?: string,
  /** patterns to exclude matched files */
  excludes?: (string | RegExp)[],
}


 

Inspector Loader Props

// import type { ParserPlugin, ParserOptions } from '@babel/parser'
// import type { InspectorConfig } from 'react-dev-inspector/plugins/webpack'

interface InspectorConfig {
  /** patterns to exclude matched files */
  excludes?: (string | RegExp)[],
  /**
   * add extra plugins for babel parser
   * default is ['typescript', 'jsx', 'decorators-legacy', 'classProperties']
   */
  babelPlugins?: ParserPlugin[],
  /** extra babel parser options */
  babelOptions?: ParserOptions,
}


 

IDE / Editor config

This package uses react-dev-utils to launch your local IDE application, but, which one will be open?

In fact, it uses an environment variable named REACT_EDITOR to specify an IDE application, but if you do not set this variable, it will try to open a common IDE that you have open or installed once it is certified.

For example, if you want it always open VSCode when inspection clicked, set export REACT_EDITOR=code in your shell.


 

VSCode

install VSCode command line tools, see the official docs
install-vscode-cli

set env to shell, like .bashrc or .zshrc

export REACT_EDITOR=code


 

WebStorm

  • just set env with an absolute path to shell, like .bashrc or .zshrc (only MacOS)
export REACT_EDITOR='/Applications/WebStorm.app/Contents/MacOS/webstorm'

OR

install WebStorm command line tools
Jump to local IDE code directly from browser React component by just a simple click

then set env to shell, like .bashrc or .zshrc

export REACT_EDITOR=webstorm


 

Vim

Yes! you can also use vim if you want, just set env to shell

export REACT_EDITOR=vim


 

How It Works

Stage 1 - Compile Time

  • [babel plugin] inject source file path/line/column to JSX data attributes props

Stage 2 - Web React Runtime

[React component] Inspector Component in react, for listen hotkeys, and request api to dev-server for open IDE.

Specific, when you click a component DOM, the Inspector will try to obtain its source file info (path/line/column), then request launch-editor api (in stage 3) with absolute file path.

Stage 3 - Dev-server Side

[middleware] setup launchEditorMiddleware in webpack dev-server (or other dev-server), to open file in IDE according to the request params.

Only need in development mode,and you want to open IDE when click a component element.

Not need in prod mode, or you just want inspect dom without open IDE (set disableLaunchEditor={true} to Inspector component props)

Analysis of Theory


Author: zthxxx
Source code: https://github.com/zthxxx/react-dev-inspector
License: MIT license

#react-native #react 

Noemi  Sanford

Noemi Sanford

1596108960

Cloudflare Launches Workers Unbound, Serverless with Unthrottled CPU Usage

It has been three years since Cloudflare first introduced its Cloudflare Workers, which it now describes as serverless code deployed to data centers across 200 cities in 95 countries. At the time, the focus was instead on how these JavaScript-based “service workers” ran at the edge and offered unmatched speed. Now, the company is releasing Workers Unbound, a serverless platform that it says delivers “unparalleled” flexibility, performance, security, ease of use, and pricing, and the focus has changed.

“Edge computing, that’s the icing on top of the cake. That’s not what people wanted to start with. What they really wanted was just a simple platform where they could write code, not think about it, and it just worked,” Cloudflare CEO Matthew Prince told The New Stack. “What we got wrong three years ago, and I think what almost every edge computing platform has gotten wrong over the years, was they lead with speed. That’s, again, the icing on top, it’s not what a really great serverless platform is.”

Instead, Prince said, what teams and developers really want from serverless is cost efficiency, ease of use, and most importantly, compliance.

“The thing that is actually even more important than ease of use is actually compliance. Not very sexy, it’s not very fun to talk about, but if your general counsel or your CIO says you must do X or you can’t do Y, that really ties the developers hands,” said Prince. “So compliance is a really important piece. And I actually think that that’s going to be the killer feature of any edge computing platform going forward.”

Whereas Cloudflare Workers were limited with certain restrictions regarding things like CPU time, memory usage, and program size, Workers Unbound are left comparatively unrestrained, with unthrottled CPU usage, automatic scaling, and the ability to “run heavy workloads without having to worry about overly restrictive CPU constraints.” This allows users to perform more complex tasks than with Workers, while at the same time spending less. According to the company, Workers Unbound, for the same workload, “can be 75 percent less expensive than AWS Lambda, 24 percent less expensive than Microsoft Azure Functions, and 52 percent less expensive than Google Cloud Functions.”

Prince explained that there were a couple factors that made Workers Unbound so much cheaper than its competitors.

#serverless #news

Hermann  Frami

Hermann Frami

1655426640

Serverless Plugin for Microservice Code Management and Deployment

Serverless M

Serverless M (or Serverless Modular) is a plugin for the serverless framework. This plugins helps you in managing multiple serverless projects with a single serverless.yml file. This plugin gives you a super charged CLI options that you can use to create new features, build them in a single file and deploy them all in parallel

splash.gif

Currently this plugin is tested for the below stack only

  • AWS
  • NodeJS λ
  • Rest API (You can use other events as well)

Prerequisites

Make sure you have the serverless CLI installed

# Install serverless globally
$ npm install serverless -g

Getting Started

To start the serverless modular project locally you can either start with es5 or es6 templates or add it as a plugin

ES6 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es6 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular serverless-webpack webpack --save-dev

ES5 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es5 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular --save-dev

If you dont want to use the templates above you can just add in your existing project

Adding it as plugin

plugins:
  - serverless-modular

Now you are all done to start building your serverless modular functions

API Reference

The serverless CLI can be accessed by

# Serverless Modular CLI
$ serverless modular

# shorthand
$ sls m

Serverless Modular CLI is based on 4 main commands

  • sls m init
  • sls m feature
  • sls m function
  • sls m build
  • sls m deploy

init command

sls m init

The serverless init command helps in creating a basic .gitignore that is useful for serverless modular.

The basic .gitignore for serverless modular looks like this

#node_modules
node_modules

#sm main functions
sm.functions.yml

#serverless file generated by build
src/**/serverless.yml

#main serverless directories generated for sls deploy
.serverless

#feature serverless directories generated sls deploy
src/**/.serverless

#serverless logs file generated for main sls deploy
.sm.log

#serverless logs file generated for feature sls deploy
src/**/.sm.log

#Webpack config copied in each feature
src/**/webpack.config.js

feature command

The feature command helps in building new features for your project

options (feature Command)

This command comes with three options

--name: Specify the name you want for your feature

--remove: set value to true if you want to remove the feature

--basePath: Specify the basepath you want for your feature, this base path should be unique for all features. helps in running offline with offline plugin and for API Gateway

optionsshortcutrequiredvaluesdefault value
--name-nstringN/A
--remove-rtrue, falsefalse
--basePath-pstringsame as name

Examples (feature Command)

Creating a basic feature

# Creating a jedi feature
$ sls m feature -n jedi

Creating a feature with different base path

# A feature with different base path
$ sls m feature -n jedi -p tatooine

Deleting a feature

# Anakin is going to delete the jedi feature
$ sls m feature -n jedi -r true

function command

The function command helps in adding new function to a feature

options (function Command)

This command comes with four options

--name: Specify the name you want for your function

--feature: Specify the name of the existing feature

--path: Specify the path for HTTP endpoint helps in running offline with offline plugin and for API Gateway

--method: Specify the path for HTTP method helps in running offline with offline plugin and for API Gateway

optionsshortcutrequiredvaluesdefault value
--name-nstringN/A
--feature-fstringN/A
--path-pstringsame as name
--method-mstring'GET'

Examples (function Command)

Creating a basic function

# Creating a cloak function for jedi feature
$ sls m function -n cloak -f jedi

Creating a basic function with different path and method

# Creating a cloak function for jedi feature with custom path and HTTP method
$ sls m function -n cloak -f jedi -p powers -m POST

build command

The build command helps in building the project for local or global scope

options (build Command)

This command comes with four options

--scope: Specify the scope of the build, use this with "--feature" tag

--feature: Specify the name of the existing feature you want to build

optionsshortcutrequiredvaluesdefault value
--scope-sstringlocal
--feature-fstringN/A

Saving build Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    build:
      scope: local

Examples (build Command)

all feature build (local scope)

# Building all local features
$ sls m build

Single feature build (local scope)

# Building a single feature
$ sls m build -f jedi -s local

All features build global scope

# Building all features with global scope
$ sls m build -s global

deploy command

The deploy command helps in deploying serverless projects to AWS (it uses sls deploy command)

options (deploy Command)

This command comes with four options

--sm-parallel: Specify if you want to deploy parallel (will only run in parallel when doing multiple deployments)

--sm-scope: Specify if you want to deploy local features or global

--sm-features: Specify the local features you want to deploy (comma separated if multiple)

optionsshortcutrequiredvaluesdefault value
--sm-paralleltrue, falsetrue
--sm-scopelocal, globallocal
--sm-featuresstringN/A
--sm-ignore-buildstringfalse

Saving deploy Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    deploy:
      scope: local
      parallel: true
      ignoreBuild: true

Examples (deploy Command)

Deploy all features locally

# deploy all local features
$ sls m deploy

Deploy all features globally

# deploy all global features
$ sls m deploy --sm-scope global

Deploy single feature

# deploy all global features
$ sls m deploy --sm-features jedi

Deploy Multiple features

# deploy all global features
$ sls m deploy --sm-features jedi,sith,dark_side

Deploy Multiple features in sequence

# deploy all global features
$ sls m deploy  --sm-features jedi,sith,dark_side --sm-parallel false

Author: aa2kb
Source Code: https://github.com/aa2kb/serverless-modular 
License: MIT license

#serverless #aws #node #lambda 

Noemi  Sanford

Noemi Sanford

1596087000

Introducing Workers Unbound

We launched Cloudflare Workers® in 2017 with the goal of building the development platform that we wished we had. We want to enable developers to build great software while Cloudflare manages the overhead of configuring and maintaining the infrastructure. Workers is with you from the first line of code, to the first application, all the way to a globally scaled product. By making our Edge network programmable and providing servers in 200+ locations around the world, we offer you the power to execute on even the biggest ideas.

Behind the scenes at Cloudflare, we’ve been steadily working towards making development on the Edge even more powerful and flexible. Today, we are excited to announce the next phase of this with the launch of our new platform, Workers Unbound, without restrictive CPU limits in a private beta (sign up for details here).

What is Workers Unbound? How is it different from Cloudflare Workers?

Workers Unbound is like our classic Cloudflare Workers (now referred to as Workers Bundled), but for applications that need longer execution times. We are extending our CPU limits to allow customers to bring all of their workloads onto Workers, no matter how intensive. It eliminates the choice that developers often have to make, between running fast, simple work on the Edge or running heavy computation in a centralized cloud with unlimited resources.

This platform will unlock a new class of intensive applications with heavy computation burdens like image processing or complex algorithms. In fact, this is a highly requested feature that we’ve previously unlocked for a number of our enterprise customers, and are now in the process of making it widely available to the public.

#cloudflare workers #serverless #serverless week #product news

Ida  Nader

Ida Nader

1596415472

Eliminating cold starts with Cloudflare Workers

A “cold start” is the time it takes to load and execute a new copy of a serverless function for the first time. It’s a problem that’s both complicated to solve and costly to fix. Other serverless platforms make you choose between suffering from random increases in execution time, or paying your way out with synthetic requests to keep your function warm. Cold starts are a horrible experience, especially when serverless containers can take full seconds to warm up.

Unlike containers, Cloudflare Workers utilize isolate technology, which measure cold starts in single-digit milliseconds. Well, at least they did. Today, we’re removing the need to worry about cold starts entirely, by introducing support for Workers that have no cold starts at all – that’s right, zero. Forget about cold starts, warm starts, or… any starts, with Cloudflare Workers you get always-hot, raw performance in more than 200 cities worldwide.

Why is there a cold start problem?

It’s impractical to keep everyone’s functions warm in memory all the time. Instead, serverless providers only warm up a function after the first request is received. Then, after a period of inactivity, the function becomes cold again and the cycle continues.

For Workers, this has never been much of a problem. In contrast to containers that can spend full seconds spinning up a new containerized process for each function, the isolate technology behind Workers allows it to warm up a function in under 5 milliseconds.

_Learn more about how isolates enable Cloudflare Workers to be performant and secure _here.

Cold starts are ugly. They’re unexpected, unavoidable, and cause unpredictable code execution times. You shouldn’t have to compromise your customers’ experience to enjoy the benefits of serverless. In a collaborative effort between our Workers and Protocols teams, we set out to create a solution where you never have to worry about cold starts, warm starts, or pre-warming ever again.

How is a zero cold start even possible?

Like many features at Cloudflare, security and encryption make our network more intelligent. Since 95% of Worker requests are securely handled over HTTPS, we engineered a solution that uses the Internet’s encryption protocols to our advantage.

Before a client can send an HTTPS request, it needs to establish a secure channel with the server. This process is known as “handshaking” in the TLS, or Transport Layer Security, protocol. Most clients also send a hostname (e.g. cloudflare.com) in that handshake, which is referred to as the SNI, or Server Name Indication. The server receives the handshake, sends back a certificate, and now the client is allowed to send its original request, encrypted.

Previously, Workers would only load and compile after the entire handshake process was complete, which involves two round-trips between the client and server. But wait, we thought, if the hostname is present in the handshake, why wait until the entire process is done to preload the Worker? Since the handshake takes some time, there is an opportunity to warm up resources during the waiting time before the request arrives.

With our newest optimization, when Cloudflare receives the first packet during TLS negotiation, the “ClientHello,” we hint the Workers runtime to eagerly load that hostname’s Worker. After the handshake is done, the Worker is warm and ready to receive requests. Since it only takes 5 milliseconds to load a Worker, and the average latency between a client and Cloudflare is more than that, the cold start is zero. The Worker starts executing code the moment the request is received from the client.

#serverless week #serverless #cloudflare workers #javascript #product news