Tech News - Server-Side Web Development

Yesterday, Das Surma, a Web Advocate at Google, shared how he and his team replaced a JavaScript hot path in the Squoosh app with WebAssembly. Squoosh is an image compression web app which allows you to compress images with a variety of codecs that have been compiled from C++ to WebAssembly. Hot paths are basically code execution paths where most of the execution time is spent. With this update, they aimed to achieve predictable performance across all browsers. Its strict typing and low-level architecture enable more optimizations during compilation. Though JavaScript can also achieve similar performance to WebAssembly, it is often difficult to stay on the fast path. What is WebAssembly? WebAssembly, also known as Wasm, provides you with a way to execute code written in different languages at near-native speed on the way. It is a low-level language with a compact binary format, which provides C/C++/Rust as the compilation target so that they can run on the web. When you compile a C or Rust code to WebAssembly, you get a .wasm file. This file contains something called “module declaration”. In addition to the binary instructions for the functions contained within, it contains all the imports the module needs from its environment and a list of exports this module provides to the host. Comparing the file size generated To narrow down the language, Surma gave an example of a JavaScript function that rotates an image by multiples of 90 degrees. This function basically iterates over every pixel of an image and copies it to a different location. This function was written in three different languages, C/C++, Rust, AssemblyScript, and was compiled to WebAssembly. C and Emscripten Emscripten is a C compiler that allows you to easily compile your C code to WebAssembly. After porting the entire JavaScript code to C and compiling it with emcc, Emscripten creates a glue code file called c.js and wasm module called c.wasm. The wasm module gzipped to almost 260 bytes and the c.js file was of the size 3.5 KB. Rust Rust is a programming language syntactically similar to C++. It is designed to provide better memory and thread-safety. The Rust team has introduced various tooling to the WebAssembly ecosystem, and one of them is wasm-pack. With the help of wasm-pack, developers can turn their code into modules that work out-of-the-box with bundlers like Webpack. After compiling the Rust code using wasm-pack, a 7.6 KB wasm module was generated with about 100 bytes of glue code. AssemblyScript AssemblyScript compiles a strictly-typed subset of TypeScript to WebAssembly ahead of time. It uses the same syntax as TypeScript but switches the standard library with its own. This essentially means that you can’t just compile any TypeScript to WebAssembly, but you don’t have to learn a new programming language to write WebAssembly. After installing the AssemblyScript file, with the help of the AssemblyScript/assemblyscript npm package, AssemblyScript provides with a wasm module of at least 300 bytes and no glue code. The module can directly work with vanilla WebAssembly APIs. Comparing the size of files generated by compiling the above three languages, Rust gave the biggest file. Comparing the performance To analyze the performance, the team did speed comparison per language and speed comparison per browser. They shared the results in the following two graphs: Source: Google Developers The graphs show that all the WebAssembly modules were executed in ~500ms or less, which proves that WebAssembly gives a predictable performance. Regardless of which language you choose, the variance between browsers and languages is minimal. The standard deviation of JavaScript across all browsers is ~400ms. And, the standard deviation of all our WebAssembly modules across all browsers is ~80ms. Which language you should choose if you have a JS hot path and want to make it faster with WebAssembly? Looking at the above results, the best choice seems to be C or AssemblyScript, but they decided to go with Rust. They narrowed down to Rust because all the codecs shipped in Squoosh so far are compiled using Emscripten and the team wanted to broaden their knowledge about the WebAssembly ecosystem by using a different language. They did not choose AssemblyScript because it is relatively new and the compiler is not as mature as Rust. The file size difference between Rust and other languages were quite huge but in reality, this is not a big deal. Going by the runtime performance, Rust showed a faster average across browsers than AssemblyScript. Additionally, Rust will be more likely to produce faster code without requiring any manual code optimizations. To read more in detail, check out Surma’s post on Google Developers. Introducing CT-Wasm, a type-driven extension to WebAssembly for secure, in-browser cryptography Creating and loading a WebAssembly module with Emscripten’s glue code [Tutorial] The elements of WebAssembly – Wat and Wasm, explained [Tutorial]

Earlier this month, the launch of Javalin 2.0 RC3 was announced. The team has now removed the “RC” tag and made Javalin 2.0.0 stable. Javalin is a web framework for Kotlin and Java, which is simple, lightweight, interoperable, and flexible. With ~5000 additions and ~5500 deletions reflecting in the gitlog, major changes have been introduced in this version. Most of the changes include the removal of abstraction layers and the completely rewritten implementation of WebSocket and test-suite. To summarize, here are few of the major changes: Additions ETag support and a method for auto-generating ETags Support for WebJars, client-side web libraries packaged into JAR (Java Archive) files. Javalin now has a pac4j implementation. It is an security library for Javalin web applications which supports authentication and authorization. RequestLogger interface ({ ctx, executionTime -> ...}) An option to return 405 instead of 404, listing available methods for the path A set of default responses, so you can throw BadRequestResponse() A CrudHandler to remove some boilerplate from creating standard CRUD APIs Improvements Improved support for Single Page Applications Improved exception handling for async requests You can now easily plug in your own mappers/rendering engines, as JSON and Template functionalities has been modularized. The ctx.render() function now contains all the Template functionality. Default value changes All requests run through an AccessManager now with the default implementation, NOOP URL matching is now case-insensitive by default. You can call app.enableCaseSensitiveUrls() if you want to disable it. Request-caching is now limited to 4kb Server now has a LowResourceMonitor attached To know more on the Javalin 2.0.0 updates head over to their official website. If you are planning to migrate from 1.x to 2.x, you can refer to the migration guide. Javalin 2.0 RC3 released with major updates! Kotlin 1.3 M1 arrives with coroutines, new experimental features like unsigned integer types Kotlin/Native 0.8 recently released with safer concurrent programming

On Monday, the team behind NgRx, a platform that provides reactive libraries for Angular, announced the release of NgRx 8. This release includes the NgRx Data package, creator functions, four run-time checks, mock selectors, and much more. Following are some of the updates in NgRx 8: NgRx Data integrated into the NgRx platform In this release, the team has integrated the angular-ngrx-data library by John Papa and Ward Bell directly into the NgRx platform as a first-party package. Using NgRx in your Angular applications properly requires a deeper understanding and a lot of boilerplate code. This package gives you a “gentle introduction” to NgRx without the boilerplate code and simplifies entity data management. Redesigned creator functions NgRx 8 comes with two new creator functions: createAction: Previously, while creating an action you had to create an action type, create a class, and lastly, create an action union. The new createAction function allows you to create actions in a less verbose way. createReducer: With this function, you will be able to create a reducer without a switch statement. It takes the initial state as the first parameter and any number of ‘on’ functions. Four new runtime checks To help developers better follow the NgRx core concepts and best practices, this release comes with four runtime checks. These are introduced to “shorten the feedback loop of easy-to-make mistakes when you’re starting to use NgRx, or even a well-seasoned developer might make.” The four runtime checks that have been added are: The strictStateImmutability check verifies whether a developer is trying to modify the state object. The strictActionImmutability check verifies that actions are not modified. The strictStateSerializability check verifies if the state is serializable. The strictActionSerializability check verifies if the action is serializable. All of these checks are opt-in and will be disabled automatically in production builds. Mock selectors for isolated unit testing NgRx 7 came with MockStore, a simpler way to condition NgRx state in unit tests. But, it does not allow isolated unit testing on its own. NgRx 8 combines mock selectors and MockStore to make this possible. You can use these mock selectors by importing @ngrx/store/testing. To know more in detail, check out the official announcement on Medium. ng-conf 2018 highlights, the popular angular conference Angular 8.0 releases with major updates to framework, Angular Material, and the CLI 5 useful Visual Studio Code extensions for Angular developers

Sails v1.0 is here! Sails.js is an MVC framework for Node.js, to easily build custom, enterprise-grade Node.js apps. It combines the familiarity of working with MVC pattern of frameworks like Ruby on Rails, with the requirements of modern apps, such as data-driven APIs with a service-oriented architecture. Version 1.0 promises to provide a better developer experience over backward compatibility. Because of this, the upgrade to Sails 1.0 may include more breaking changes than previous versions. Here’s an overview of what's changed in this release and some of the new features you might want to take advantage of in your app. Sails v1.0 no longer supports Node v0.x; the earliest version it supports is Node 4.x. Sails v1.0 introduces custom builds. These custom builds provide more control over an app’s dependencies as certain core hooks are now installed as direct dependencies of an app. It also makes npm install sails run considerably faster. The new Sails also comes with several improvements in app configurations. This includes: datastores, which is by far the biggest change in app configuration. Datastores represent the data sources configured for an app. automatic install of lodash and async are now customizable to any version. view engine configuration syntax has been normalized to be consistent with the approach in Express v4+. The new blueprint API is getting expanded to include a new endpoint which might require developers to make changes in the client-side code. Most importantly, Sails v1.0 comes with a new release of Waterline ORM (v0.13). This Waterline version introduces full support for SQL transactions, picking/omitting attributes in result sets, dynamic database connections, and more granular control over query behavior. It also comes with a major stability and performance overhaul. These cover the majority of changes that Sails version 1.0 has introduced. A comprehensive list of all changes along with the necessary code files required to upgrade to the version 1.0 is available on the Sails Documentation.

Yesterday, the Cloud Native Computing Foundation (CNCF) announced the general availability of gRPC-Web, which means that it is stable enough for production use. It is a JavaScript client library that allows web apps to directly communicate with backend gRPC services, without the need for an intermediate HTTP server. This serves as an alternative to the REST paradigm of web development. What is gRPC? Source: gRPC Initially developed at Google, gRPC is an open source remote procedure call (RPC) framework that can run in any environment. gRPC allows a client application to directly call methods on a server application on a different machine as if it was a local object. gRPC is based on the idea of defining a service, specifying the methods that can be called remotely with their parameter and return types. To handle the client calls the server then implements this interface and runs a gRPC server. On the client side, the client has a stub that provides the same methods as the server. One of the advantages of using gRPC is that gRPC clients and servers can be written in any of the languages supported by gRPC. So, for instance, you can easily create a gRPC server in Java with clients in Go, Python, or Ruby. How gRPC-Web works? With gRPC-Web, you can define a service “contract” between client web applications and backend gRPC servers using .proto definitions and auto-generate client JavaScript. Here is how gRPC-Web works: Define the gRPC service: The first step is to define the gRPC service. Similar to other gRPC services, gRPC-Web uses protocol buffers to define its RPC methods and their message request and response types. Run the server and proxy: You need to have a gRPC server that implements the service interface and a gateway proxy that allows the client to connect to the server. Writing the JavaScript client: After the server and gateway are up and running, you can start making gRPC calls from the browser. What are the advantages of using gRPC-Web? Using gRPC-Web eliminates some of the tasks from the development process: Creating custom JSON serialization and deserialization logic Wrangling HTTP status codes Content type negotiation The following are its advantages: End-to-end gRPC gRPC-Web allows you to officially remove the REST component from your stack and replace it with pure gRPC. Replacing REST with gRPC will help in scenarios where a client request goes to an HTTP server, which interacts with five backend gRPC services. Tighter coordination between frontend and backend teams As the entire RPC pipeline is defined using Protocol Buffers, you no longer need to have your “microservices teams” alongside your “client team.” The interaction between the client and the backend is just one more gRPC layer amongst others. Generate client libraries easily With gRPC-Web, the server that interacts with the “outside” world is now a gRPC server instead of an HTTP server. This means that all of your service’s client libraries can be gRPC libraries. If you need client libraries for Ruby, Python, Java, and 4 other languages, you no longer have to write HTTP clients for all of them. You can read CNCF’s official announcement on its website. CNCF accepts Cloud Native Buildpacks to the Cloud Native Sandbox Cortex, an open source, horizontally scalable, multi-tenant Prometheus-as-a-service becomes a CNCF Sandbox project Google Cloud hands over Kubernetes project operations to CNCF, grants $9M in GCP credits

Today, Amazon released Smoke Framework, a lightweight server-side service framework written in the Swift programming language. The Smoke Framework uses SwiftNIO for its networking layer by default. This framework can be used for REST-like or RPC-like services and in conjunction with code generators from service models such as Swagger/OpenAPI. The framework also has a built-in support for a JSON-encoded request and response payloads. Working of Swift-based Smoke Framework The Smoke Framework provides the ability to specify handlers for operations the service application needs to perform. When a request is received, the framework will decode the request into the operation's input. When the handler returns, its response (if any) will be encoded and sent in the response. Each invocation of a handler is also passed an application-specific context, allowing application-scope entities such as other service clients to be passed to operation handlers. Using the context allows operation handlers to remain pure functions (where its return value is determined by the function's logic and input values) and hence easily testable. Parts of the Smoke framework The Operation Delegate The Operation Delegate handles specifics such as encoding and decoding requests to the handler's input and output. The Smoke Framework provides the JSONPayloadHTTP1OperationDelegate implementation that expects a JSON encoded request body as the handler's input and returns the output as the JSON encoded response body. The Operation Function By default, the Smoke framework provides four function signatures that this function can conform to ((InputType, ContextType) throws -> ()): Synchronous method with no output. ((InputType, ContextType) throws -> OutputType): Synchronous method with output. ((InputType, ContextType, (Swift.Error?) -> ()) throws -> ()): Asynchronous method with no output. ((InputType, ContextType, (SmokeResult<OutputType>) -> ()) throws -> ()): Asynchronous method with output. Error handling By default, any errors thrown from an operation handler will fail the operation and the framework will return a 500 Internal Server Error to the caller (the framework also logs this event at Error level). This behavior prevents any unintentional leakage of internal error information. Testing The Smoke Framework has been designed to make testing of operation handlers straightforward. It is recommended that operation handlers are pure functions (where its return value is determined by the function's logic and input values). In this case, the function can be called in unit tests with appropriately constructed input and context instances. To know more about this in detail, visit Smoke framework’s official GitHub page. ABI stability may finally come in Swift 5.0 Swift 4.2 releases with language, library and package manager updates! What’s new in Vapor 3, the popular Swift based web framework

Last week, the team at Rocket released Rocket 0.4, a web framework for Rust which focuses on usability, security, and performance. With Rocket, it is possible to write secure web applications quickly and without sacrificing flexibility or type safety. Features of Rocket 0.4 Typed URIs Rocket 0.4 comes with uri! macro that helps in building URIs to route in the application in a robust, type-safe, and URI-safe manner. The type or route parameter that is mismatched are caught at compile-time. With the help of Rocket 0.4, changes to the route URIs get reflected in the generated URIs, automatically. ORM agnostic database support. Rocket 0.4 comes with a built-in, ORM-agnostic support for databases. It provides a procedural macro that helps in connecting Rocket application to databases through connection pools. Rocket 0.4 gets databases configured individually through configuration mechanisms like Rocket.toml file or environment variables. Request-local state Rocket 0.4 features request-local state which is local to a given request and is carried along with the request. It gets dropped once the request is completed. Whenever a request is available, a request-local state can be used. Request-local state is cached which lets the stored data to be reused. Request-local state is used for request guards which get invoked multiple times during routing and processing of a single request. Live template reloading In this version of Rocket, when an application is compiled in debug mode, templates automatically get reloaded on getting modified. To view the template changes, one has to simply refresh and there is no need of rebuilding the application. Major Improvements Rocket 0.4 introduces SpaceHelmet that provides a typed interface for HTTP security headers. This release features mountable static-file serving via StaticFiles. With this version of Rocket, cookies can automatically get tracked and propagated by client. This version also introduces revamped query string handling that allows any number of dynamic query segments. Rocket 0.4 comes with transforming data guards that transform incoming data before processing it via an implementation of the FromData::transform() method. This version comes with Template::custom() which helps in customizing template engines including registering filters and helpers. With this version, applications can be launched without a working directory. In Rocket 0.4, the log messages refer to routes by name. A default catcher for 504: Gateway Timeout has been added. All derives, macros, and attributes are individually documented in rocket_codegen. To retrieve paths relative to the configuration file, Rocket 0.4 has added Config::root_relative() The private cookies are now set to Http and are also given an expiration date of 1 week by default. What can be expected from Rocket 0.5? Support for Rust Rocket 0.5 will run and compile on stable versions of the Rust compiler. Asynchronous Request Handling Rocket 0.5 will feature the latest asynchronous version that will support asynchronous request handling. Multipart Form Support The lack of built-in multipart form support makes handling file uploads and other submissions difficult. With Rocket 0.5 it will be easy to handle multipart forms. Stronger CSRF and XSS Protection Rocket 0.5 will protect against CSRF using effective robust techniques. It will come with added support for automatic, browser-based XSS protection. Users have been giving some good feedback on the Rocket 0.4 release and are highly appreciative of the Rocket team for the efforts they have taken. A user commented on HackerNews, “This release isn't just about new features or rewrites. It's about passion for one's work. It's about grit. It's about uncompromising commitment to excellence.” Sergio Benitez, a computer science PhD student at Stanford, has been appreciated a lot for his efforts towards the development of Rocket 0.4. A HackerNews user commented, “While there will ever be only one Sergio in the world, there are many others in the broader Rust community who are signaling many of the same positive qualities.” This release has also been appreciated for its feel which is similar to Flask and for its capability of using code generation and function's type signatures to automatically check the incoming parameters. The fact that the next release will be asynchronous has created a lot of curiosity in the developer community and users are now looking forward to Rocket 0.5. Read more about Rocket 0.4 in the official release notes. Use Rust for web development [Tutorial] Introducing ‘Pivotal Function Service’ (alpha): an open, Kubernetes based, multi-cloud serverless framework for developer workloads Kotlin based framework, Ktor 1.0, released with features like sessions, metrics, call logging and more

Today, Alex Russell, a Google software engineer, submitted a patch called ‘Never-Slow Mode’ for Chromium. With this patch, various limits will be enforced for per-interaction and resources to keep the main thread clean. Russell’s patch is very similar to a bug Craig Hockenberry, a Partner at The Iconfactory, reported for WebKit, last week. He suggested adding limits on how much JavaScript code a website can load to avoid resource abuse of user computers. Here are some of the changes that will be done under this patch: Large scripts will be blocked. document.write() will be turned off Client-Hints will be enabled pervasively Resources will be buffered without ‘Content-Lenght’ set Budgets will be re-set on the interaction Long script tasks, which take more than 200ms, will pause all page execution until the next interaction. Budgets will be set for certain resource types such as script, font, CSS, and images. These are the limits that have been suggested under this patch (all the sizes are in wired size): Source: Chromium Similar to Hockenberry’s suggestion, this patch did get both negative and positive feedback from developers. Some Hacker News users believe that this will prevent web bloat. A user commented, “It's probably in Google's interest to limit web bloat that degrades UX”. Another user said, “I imagine they’re trying to encourage code splitting.” According to another Hacker News user putting hard coded limits will probably not work, “Hardcoded limits are the first tool most people reach for, but they fall apart completely when you have multiple teams working on a product, and when real-world deadlines kick in. It's like the corporate IT approach to solving problems — people can't break things if you lock everything down. But you will make them miserable and stop them doing their job”. You can check out the patch submitted by Russell at Chromium Gerrit. Chromium developers propose an alternative to webRequest API that could result in existing ad blockers’ end Chromium blacklists nouveau graphics device driver for Linux and Ubuntu users Chromium-based Brave browser shows 22% faster page load time than its Muon-based counterpart

Tornado recently announced the release of version 5.1 and dropped the plans for a major release of Tornado 6.0. Tornado is a Python-based web framework and consists of asynchronous networking libraries for complete web development in Python. It is known for its ability to scale a huge number of connections on the web and is considered ideal for the applications that require uninterrupted connectivity on the web. Features included in Tornado 5.1 Improvement in the command-line wrapper. It will no longer clash with the active processes on Windows. New module to support non-ASCII characters in username and password Consistent behavior of the client-server modules like simple_httpclient and curl_httpclient Improved compatibility with GNU Hurd Improved WebSocket modules to protect against DoS attacks Preparation for Tornado 6.0 Tornado 6.0 will drop the support for Python versions 2.7 and 3.4 while making Python 3.5.2 as the minimum supported version. To make sure systems running on older Python versions do not break, the deprecation warnings are emitted. In order to receive the deprecation warnings, you need to run -wd argument or set the environment variable for your Python ecosystem. Also, Tornado maintainers have informed that the applications running on Python 3, which do not receive the deprecation warning will be able to move to Tornado 6.0 without breaking. To avoid the risk of errors that are introduced due to the connection leak, the ExceptionStackContext module will be removed from Tornado 6.0. Tornado 6.0 will remove obsolete packages to make a lean standard framework. For example, the Stack context module will be removed as it will stand obsolete after the introduction to co-routines. To learn more about the deprecated features in Tornado 5.1 and in-depth feature notice, you can check out the release notes page of Tornado 5.1. Read more Masonite 2.0 released, a Python web development framework Python web development: Django vs Flask in 2018 Python founder resigns – Guido van Rossum goes ‘on a permanent vacation from being BDFL’

Blazor 0.5.0 is here. Blazor is an experimental .NET client-side web framework that uses c# and HTML. It runs on a browser using WebAssembly mechanism. Here component logic and DOM interactions occur in the same process. The latest release includes features such as server-side Blazor, a new startup model, and early support for in-browser debugging among other updates. Let’s discuss the highlights of Blazor 0.5.0 release. Server-side Blazor Blazor 0.5.0 release makes it possible to adopt the out-of-process model for Blazor by stretching it over a network connection so that you can run Blazor on the server with ease. With Blazor 0.5.0 it is possible to run your Blazor components server-side on .NET Core. UI updates, event handling, and JavaScript interop calls get handled over a SignalR connection. You can also use JavaScript interop libraries while using server-side Blazor. New Startup Model Blazor 0.5.0 projects now make use of a new startup model, similar to the startup model in ASP.NET Core. To configure the services for your Blazor app, each Blazor project consists of a Startup class with a ConfigureServices method. There’s also a Configure method for configuring the root components of the application. Calling .NET from JavaScript There’s a new feature added in Blazor 0.5.0 which lets you call .NET instance methods from JavaScript. You can do it by passing the .NET instance to JavaScript and wrapping it in a DotNetObjectRef instance. The .NET instance then gets passed by reference to JavaScript. This allows you to invoke .NET instance methods on the instance by using the invokeMethod or invokeMethodAsync functions. Adding Blazor to HTML file In earlier releases, the project build had modified index.html in order to replace the blazor-boot script tag with a real script tag.  This made it difficult to use Blazor in arbitrary HTML files. This mechanism has now been replaced in Blazor 0.5.0. You can add a script tag for client-side projects that references the _framework/blazor.webassembly.js script (which is generated as part of the build). You can add the script reference _framework/blazor.server.js. for server-side projects. Support for in-browser debugging Blazor 0.5.0 provides very basic debugging support in Chrome for client-side Blazor apps that run on WebAssembly. Despite the debugging support being limited and unpolished, it does show the basic debugging infrastructure. For more info on Blazor 0.5.0 updates, check out the official release notes. Masonite 2.0 released, a Python web development framework Node 10.0.0 released, packed with exciting new features