WaveMaker released version 11.8.0 on July 29, 2024. This update includes a significant upgrade to Angular 17. This upgrade is expected to enhance your application's performance and development experience.

Angular 17​

The move from Angular 16 to 17 brings noticeable performance improvements, including faster load times and smoother visuals. This translates to a better user experience overall. Additionally, the upgrade enhances the stability and reliability of applications.

To learn more, see Angular Version 17 - what's in the release.

WaveMaker family, we are excited to announce the latest iteration of our platform, WaveMaker 11.8.0, and it’s packed with significant enhancements - most notably, the upgrade to Expo SDK 50.

Why this Upgrade Matters​

We know developers are always on the lookout for tools that simplify workflows and enhance efficiency. With this new version, we’ve not only improved performance but also brought in new features that could help developers save time and effort in areas where frequent testing is needed. Here's a sneak peek at what you can expect.

React Native 0.73​

We’ve upgraded to React Native 0.73, bringing you the latest features, enhanced performance, and improved developer tools. Dive into the React Native CHANGELOG to see all the detailed enhancements.

Improved Debugger for React Native apps​

Take a closer look into the future with a new JavaScript debugger UI, which helps developers debug at the same time in preview. This debugger is still in development, but you can try it out now!

What's new here​

• A fresh, user-friendly interface for finding and fixing bugs.
• Built on the same technology as the debugger you already know (from Expo CLI).

Try it out​

To give it a spin, simply add this line to your terminal before starting your Expo project:

EXPO_USE_UNSTABLE_DEBUGGER=1 npx expo start

This will activate the new debugger interface, giving you a smoother debugging experience.

Improvement in npx expo run Command​

Expo CLI will now prompt you to select a target platform if it's not explicitly named in the command. This is a small quality-of-life improvement that aligns the npx expo run UX with that of eas build:run. You can also use npx expo run android or npx expo run ios as alternatives to run:android and run:ios.

1. npx expo run - Prompts to select a platform.
2. npx expo run android - Runs on Android.
3. npx expo run ios - Runs on iOS.

Improved Error Messages and Stack Traces​

Debugging just got a whole lot easier! Having the ability to read error messages quickly and having to put lesser efforts when developer runs into error is something that is most times overlooked at. Expo 50 offers more detailed and useful error messages and stack traces, making it faster to identify and resolve issues.

Optimized npx expo prebuild​

Skip the unnecessary dependency installations with the improved npx expo prebuild command. If there are no changes to the dependencies in package.json, the Node module installation step is skipped. This means a faster and cleaner prebuild process!

Speedy Build Performance​

WaveMaker 11.8.0 ensures that builds are quicker than ever before. This significant performance boost translates directly into a more efficient development cycle.

How to Get Started​

Before diving in, ensure you have the following prerequisites installed:

• JDK 17
• Android SDK 34
• @wavemaker/wm-reactnative-cli@1.8.x

And there you have it! WaveMaker 11.8.0 is here to supercharge your development process. Get ready to build, debug, and deploy faster and more efficiently. Feel the power of WaveMaker with Expo SDK 50. 🚀

We are happy to announce new updates in WaveMaker that will enhance your development experience and application quality. This is a product update for the months of June and July 2024.

Support for Java 17 and 21 Deployment​

WaveMaker now supports deployment on web servers using Java 17 and Java 21 alongside Java 11. This update prepares for future Java versions and enhances compatibility with modern libraries.

Read More

Performance Improvements​

• Dialogs now load their content only when you click them to open. This helps web pages with many complex dialogs load faster
• Bind Dialog and Tab Loading: Tabs in the bind dialog now load only when needed, improving navigation speed and overall performance
• Web pages with many dialogs, containing a lot of Widgets and Prefabs will now load and perform better with lazy loading; dialog content only loads when the dialog is clicked
• Prefabs load faster; reducing the number of calls needed to access properties and configuration files
• Optimized Angular builds to reduce the size of the generated application files (like vendor.js and main.js); the studio loads noticeably faster

Accessibility Enhancement with Label Widgets​

WaveMaker improves accessibility by using semantic tags like <p> and <h1>–<h6> instead of <label> tags outside of forms. This change ensures compliance with accessibility standards.

Read More

Pull Request Flow for Custom VCS​

Introducing a Pull Request (PR) flow for Version Control Systems like Bitbucket, GitHub, and GitLab, enhancing collaboration and code management for teams.

Read More

See Also​

v11.7.5 - Release date: 08 July 2024
v11.7.4 - Release date: 01 July 2024
v11.7.3 - Release date: 17 June 2024

This blog post provides an important update for developers regarding the support for application deployments with Java 17 and 21. Starting with release 11.7.4, WaveMaker applications will now support deployment on web servers running Java 17 and Java 21, along with continued support for Java 11.

Java 17 and 21 Deployment Support​

While WaveMaker applications can now be deployed on web servers using Java 17 and Java 21, the features and syntax of these Java versions cannot be used as compilation still requires Java 11.

What You Need to Do: Upgrade Your Deployment Container​

To deploy applications with Java 17 or Java 21, you need to update the Java version within your deployment container.

WaveMaker Online Users​

If you're using Wavemaker Online (WMO), you don't need to worry about immediate impacts. By default, WMO uses Java 11, so there will be no immediate disruptions for current users. However, the applications can be deployed externally using Java 17 or Java 21.

Frequently Asked Questions​

Is upgrading to Java 17 or 21 mandatory?​

No, upgrading is not mandatory.

Why the push for Java 17 and 21?​

Java 11 currently only has extended support. Libraries like Spring and other third-party libraries are actively being developed on Java 17 and above. From WaveMaker 12, we plan to move to Java 21 along with Spring and Hibernate upgrades.

Do I need to update my CI/CD pipeline?​

Yes, only if you want to deploy the application in Java 17 or Java 21.

Can I use Java 17 and 21 language features?​

No, only Java 11 language features and syntax can be used as code compilation requires Java 11.

Can I run Maven build using Java 17 and Java 21?​

Yes, Maven builds can be done using Java 17 and Java 21, but code compilation is done in Java 11.

Which web servers can the application be deployed?​

Any web servers that support Java 11/17/21 and Servlet 4.0, such as Apache Tomcat 9.x.

In accordance with web accessibility standards, the <label> tag is specifically intended for use within Forms. To ensure proper accessibility, WaveMaker is implementing changes to how label widgets are handled. Therefore, the <label> tag used out of the forms will replace with <p>, <h1> to <h6> tags based on the class or type attribute of that element.

Current Behavior​

Previously, when dragging and dropping a Label widget onto the canvas and previewing it, the element would utilize the <label> tag with a class defined in the element. Additionally, changing the template layout to headings (H1, H2, etc.) would only modify the class, leaving the tag itself as <label>. This approach conflicts with accessibility guidelines.

Improved Accessibility​

To address this issue, WaveMaker is replacing the <label> tag with more appropriate semantic tags like <p> (paragraph) or <h1> to <h6> (headings) based on the class or type attribute of the element.

How it Works​

Here's a breakdown of the changes:

Default Behavior: When you drag and drop a label widget, the markup will now include class="p" and type="p" appended to the "wm-label" element by default. This translates to a <p> tag in the preview, ensuring proper accessibility.

Template Layouts: Changing the template layout (e.g., H1, H2) will update both the class and type attributes accordingly. The preview will then reflect the corresponding heading tag (e.g., <h1>). Layouts like "Primary Text" and "Secondary Text" will continue to use the <p> tag.

Implicit Conversion: Labels within widgets like cards, accordions, and panels will be automatically converted to the appropriate semantic tag (<p> or <h1> to <h6>) based on their existing class values.

Addressing Potential Issues​

Differences Before and After change​

This section showcases the visual differences between the previous and updated behavior.

Label in Markup​

• In the studio when we drag and drop a Label onto canvas and go to markup tab to see the differences as given below.

Before

After

• Click the label on canvas and then select the template layout option to "H1" then the class and type both gets updated to "h1".

Before

After

Label in Preview​

• Click on preview and see the difference that <label> tag is getting replaced by <p> tag by default.

Before

After

p.app-label{
   display:inline-block 
}
p.p.app-label{
    display:block;
}

Cards as Example​

• Drag and drop the Card widget and click Preview.

Before

After

Overall, these changes enhance the accessibility of WaveMaker applications by ensuring proper use of semantic tags for labels. This benefits users with disabilities by providing a more predictable and navigable interface.

WaveMaker Release 11.7 is scheduled for the 29th of April 2024 and the release will include an update to Angular 16. This upgrade will enhance your application development experience and performance.

Angular 15 New Features and Enhancements​

Angular 15 to 16 includes many performance improvements, such as faster startup times and improved rendering performance, allowing the apps to be more responsive and provide a better user experience. Also, it improves the stability and reliability of Angular applications.

Recommendation​

With the Angular 16 upgrade, it is suggested to use the latest compatible browser versions.

To understand more about the compatible browser versions, see Angular Browser Support.

Performance improvements​

With the underlying framework upgrade, we have used some of the best features available to keep the studio code footprint lighter at all times. With these implementations, you will see the project loading faster when opened in the new studio.

Some of the actions taken in this direction are:

Lazy loading modules​

By modularising all the major workspaces and using the lazy loading concept in angular, we have decreased the bundle size and kept it to the minimum that is required to initially load the studio.

Project updates​

The project updates are now pushed in the background and do not come in the way of the project load. This decreases the time taken for a developer to resume work in their branch. No more will you be asked to update all the prefabs used in the project every time you load your project. You can simply resume the work you left previously without any distractions.

What's new?​

Along with the tech upgrade and the performance improvements, there are a few visible changes to the studio as well. Some of these are:

Introducing ProjectsHub​

The projects listing page is completely redesigned and is now called ProjectsHub. Dogfooding our own software, the new ProjectsHub is built using WaveMaker platform itself.

Refreshing overall studio look​

The overall look and feel of the studio has changed. We have reduced clutter in the toolbars and improved the way icons, text look.

A better version controlling​

When you work in a team, It's important to stay updated with the latest work being done by other team members. A powerful code diff viewer becomes crucial for such an environment. Based on the developer feedback, we've revamped the code diff editor in the studio.

• the code diff editor now shows only the changes made in a file, so you can focus on the same and not scroll through a big file to view what changes are. The unchanged lines of code are by default collapsed, which can still be expanded and viewed.
• the line diff now clearly highlights the diff literal by literal, so it's easier to view the actual change.
• you can navigate through the changes with the next and previous diff buttons

Powerful 3-way merge screen​

Power packed with all the diff features mentioned above, the 3-way merge screen used in case of merge conflicts boosts the developer productivity as developers can focus on just the conflict areas and resolve them quicker.

New settings workspace​

Multiple project level configuration options in the studio have been collated into one place simply called as Settings. All project level settings that you would generally configure in a project and visit not too frequently are placed here. These configuration options will vary based on the project type. For example:

• General settings
• Profile configuration
• Security
• Artifacts
• Prefab configuration (Prefab project)

With this change, the studio header becomes lighter and less complicated. The features that are more frequently used in the day to day developer activities are all still placed in the studio header.

New project updates section​

All the updates to a project are now pushed in the background and collated in the project updates section present in the studio header. Few examples of updates to a project are:

• Changes pushed to the project by other developers.
• Availability of new version of artifacts used in the project (prefab, theme, etc)

Updated APIs workspace​

All the APIs imported in a project are now placed at a single place, the APIs workspace. These include the individual REST API endpoints as well as the OpenAPI (swagger) bundle imported in the project.

A new (yet familiar) playground for APIs​

The APIs workspace now uses the standard OpenAPI UI plugin as the playground to view and test all the APIs in your project in WaveMaker studio. Since this plugin provides exactly the same UI and experience as you would see on the official swagger editor portal, it would feel much more familiar while testing the APIs in WaveMaker studio as well.

New code editor​

We are now using monaco as the code editor in the studio, the editor that powers VS Code. The new code editor comes with a new set of rich functionalities provided by monaco, such as better intellisense, code lens feature that makes it easier to navigate through a large file, etc

Rollout plan​

To facilitate a smooth transition, we will be rolling out access to the new version of Studio in a phased manner. This approach allows us to closely monitor performance, address any unforeseen issues, and provide necessary support to users as they familiarize themselves with the updated interface and features.

Here is an overview of the phased rollout plan:

Phase 1: Internal rollout​

All WaveMaker email accounts will get access to the new ProjectsHub and Studio. This phase will help us identify any potential issues and gather valuable insights for optimization.

Phase 2: Selected WMOnline customers​

Access to the new version will be extended to selected WMOnline customers. These are the customers who provide valuable feedback on the platform stability on a regular basis.

Phase 3: All teams on WMO + WME​

All of the online and Enterprise customers will be moved to the new version of the platform.

Deprecation notice for Cordova project type​

With the release of 11.6.0, we will start providing minimal support to Cordova projects. However, by June 2024 we will end our complete support for Cordova projects and users will not be provided with any new patches/updates in further releases.

Background​

WaveMaker’s support for developing mobile applications was launched in 2015 with Cordova as the underlying framework. But with multiple advancements, in 2022, we released support for creating React Native mobile applications.

Why React Native​

With better performance and the latest technology, React Native stands as the first choice for application development. To understand more about how React Native is better than Cordova, see React Native or Cordova.

What's Next​

What happens to the existing applications​

Mobile applications that are already installed on devices will continue to run. This notice concerns WaveMaker’s usage to develop the application to add new features or change already built pages. There is no runtime impact.

Migration Strategies​

1. Recreate mobile application functionality in WaveMaker’s React Native project type.
2. Setup the WaveMaker built web application to be a Progressive Web application.

Please reach out to your customer success partner to talk about your migration approaches. We will be happy to help with this.

We thank all the WaveMaker developers who have built mobile applications and are looking forward to serving you in the future.

Exciting news for WaveMaker developers! The upcoming upgrade of the WaveMaker Web Apps Charting libraries, scheduled for Release 11.5.3 in the fourth week of January 2024, introduces significant improvements derived from both D3.js and NVD3.

This update ensures compatibility with modern web standards and offers a more streamlined experience for developers.

Who should read this​

WaveMaker developers using chart widgets without D3 methods in the ChartOnBeforeRender callback won't be affected by the D3 library upgrade. Their applications will work smoothly without any changes. However, if developers use D3 methods in the callback, the upgrade might impact functionality, requiring adjustments as outlined below to ensure continued operation.

D3.js Version 7​

D3.js, a powerful JavaScript library for creating interactive data visualizations, undergoes a major version upgrade from 3.5.7 to 7.8.5, bringing new features and improvements and allowing developers to adapt to the latest changes.

Key Changes in D3.js Version 7​

1. Syntax and Selections
2. Promises
3. Immutability
4. Chaining
5. Modularity
6. Axes and Scales
7. Data Join
8. Compatibility
9. Documentation

Syntax and Selections​

• The syntax has evolved to be more concise and adherent to ES6 standards.
• Method chaining and selections exhibit a more logical and consistent structure.

// D3 v3
d3.selectAll('circle').attr('r', function(d) { return d.radius; });

// D3 v7
d3.selectAll('circle').attr('r', d => d.radius);

Promises​

D3 v7 embraces Promises for asynchronous operations, simplifying the handling of asynchronous tasks.

// D3 v3
d3.json('data.json', function(error, data) {
// Callback-based approach
});

// D3 v7
d3.json('data.json')
.then(data => {
// Promise-based approach
})
.catch(error => {
console.error('Error loading data:', error);
});

Immutability​

D3 v7 introduces immutability to selections, enhancing code predictability and avoiding unexpected side effects.

// D3 v3
var circles = d3.selectAll("circle");
circles.attr("r", 10);
circles.style("fill", "blue");

// D3 v7
const circles = d3.selectAll("circle")
.attr("r", 10)
.style("fill", "blue");

Implications of Immutability​

Consistency and Predictability:​

The immutability of selections in D3 v7 leads to more consistent and predictable behavior.

Transitioning and Animation:​

Transitions and animations are built on the same immutable foundation, providing clarity and control.

// D3 v3
var circles = d3.selectAll("circle");
circles.transition().duration(1000).attr("r", 20).style("fill", "red");

// D3 v7
const circles = d3.selectAll("circle")
.transition()
.duration(1000)
.attr("r", 20)
.style("fill", "red");

Chaining​

Immutability is closely linked to method chaining, allowing concise and readable code.

// D3 v3
var circles = d3.selectAll("circle");
circles.attr("r", 10).style("fill", "blue");

// D3 v7
const circles = d3.selectAll("circle")
.attr("r", 10)
.style("fill", "blue");

Modularity​

D3 v7 embraces modularity, allowing developers to use specific modules without including the entire library.

// D3 v3
// Include the entire library

// D3 v7
import { scaleLinear, axisBottom } from 'd3';

Axes and Scales​

While core concepts remain, v7 brings refinements for creating scales and axes, offering more control and customization options.

1.d3.scale.linear() = d3.scaleLinear()
2.d3.scale.ordinal() = d3.scaleOrdinal()
3.d3.svg.arc()= d3.arc()
4.d3.svg.axis.orient('bottom') = d3.axisBottom()
5.d3.event.pageX() = d3.pageX()
6.d3.time.format() = d3.timeFormat()
7.d3.time.Scale() = d3.scaleTime()
8.chartinstance.dispatch.on('render_end')=chartinstance.dispatch.on('renderEnd')
9.Changes in Mouse Event Callbacks:
   The arguments passed in mouse events callback functions changed 
   from data, index => event, data, index.
    a.In D3 v3, the mouse event callback functions received 
      data and index as the first and second arguments.
    b.In D3 v7, the order is changed, and the callback functions 
      receive events as the first argument, followed by data and index.

Data Join​

D3 v7 enhances the data join pattern for better performance and optimizations.

// D3 v3
var circles = svg.selectAll('circle').data(data);
circles.enter().append('circle');

// D3 v7
var circles = svg.selectAll('circle').data(data)
.join('circle');

Compatibility​

D3 v7 aligns with modern web standards, integrating seamlessly with other JavaScript tools and frameworks.

// D3 v3
// No native module support

// D3 v7
import { select, scaleLinear } from 'd3';

Documentation​

The documentation for D3 v7 is updated, offering more comprehensive explanations and examples.

// D3 v3
// Limited documentation

// D3 v7
// Well-documented features with examples

NVD3 is a wrapper library over D3 which is also upgraded to incorporate latest changes in D3.

To learn more, see The Comprehensive Migration Guide.

WaveMaker Release 11.5 is scheduled for the 4th week of November 2023 and the release will include an update to Angular 15, as well as an upgrade to Node.js 18.16.1.! This is a significant upgrade that will help improve your application development experience and performance.

Angular 15 New Features and Enhancements​

Angular 12 to 15 includes a number of performance improvements, such as faster startup times and improved rendering performance, allowing the apps to be more responsive and provide a better user experience. Also, it improves the stability and reliability of Angular applications.

To learn more, see Angular Version 15 - what's in the release.

Action Needed​

Along with Angular upgrade we have upgraded the Node version to 18.16.x. Therefore, you are required to adjust the CI/CD pipeline accordingly.

• Moving to Node.js 18.16.1

Node version should be greater than 18.16.1. The current version of the Node.js is 12.x.x

Design tokens are platform-agnostic variables. They are the single source of truth for the design system, and all applications that use the design system refer to them.

Design tokens allow designers to make sweeping changes to the look and feel of a product by simply changing the value of a single token. They are typically defined in human-readable formats like JSON or YAML, which makes them easy to understand and maintain.

Design tokens codify design decisions in a way that is easy to enforce, which helps to ensure consistency across all products that use the design system.

What are Design Tokens?​

Design tokens are the building blocks of a design system. They are platform-agnostic variables that represent the design elements of a product, such as typography, colors, spacing, and more. Design tokens can be shared across iOS, Android, and regular websites, and they provide the foundation for theming and design process automation to automate tasks in the design process, such as generating CSS variables or style guides.

Who uses Design Tokens?​

One of the fundamental questions when creating a design system is:

Who is going to use it and how?​

A design system is not just a project; it is a living document. Design systems are good for business and even better for people, providing a huge sense of relief for product managers, project managers, and VPs of Design.

So, what does a design system do for your designers and developers?

Designers and developers benefit from design systems in a variety of ways. For example, design tokens allow designers to easily update and reproduce design changes throughout a project, eliminating the need to manually update elements individually. This saves time and effort, and ensures flawless visual consistency throughout the design process.

Why should we use design tokens?​

It is important for companies with many products to include design tokens in their design system. The complexity of the world we’re living in today where a single organization that is building multiple web apps and native applications needs to feel and look the same while not slowing down the development team.

As digital transformation accelerates, companies face the challenge of scaling design across an increasing number of screens, tech stacks, and product teams. As the product footprint grows, propagating even simple design decisions (such as a color change) can take weeks to accomplish.

To address this challenge, the design system team at Salesforce established a new data layer and a practice that helps scale design across multiple platforms and teams. They named it Design Tokens. By using design tokens, it can take minutes—instead of weeks—to implement design decisions across platforms

The key benefits of using design tokens are

• Consistency
• Efficiency
• Flexibility
• Adaptability
• Documentation

Let’s try to understand with an example how adopting modular design tokens brings flexibility and scalability to design systems.

Let’s say we have a theme with a primary color as the dominant color and use it across different components like button, input fields, toggle, checkboxes, etc.

Now, suppose a designer decides to choose a darker shade for the primary color. We can do that using styles in Figma or other design tools, and CSS variables can handle this challenge and bring scale to some extent. But using just styles or variables alone cannot solve other complex challenges, like changing the primary color only in components where it is used as a background—this is where design tokens come into play.

Design tokens are not just limited to a color system; they can store everything from type or spatial systems to design assets.

Design Tokens ≠ CSS Variables​

Design tokens follow the same concept as design variables, but they do have their differences.

Simplifying the Process​

Tokens includes everything in css properties that goes within “” values, spacing, sizing, rounded corners, fontweights, font sizes, line heights, shadows, font families, border colors, background colors, text colors, animation durations, z-indexes, media queries, etc.

How can we start our design system using simplified tokens?

The solution is to use a concept similar to atomic design, where we will have a base token and a semantic token.

Base Token​

The base token will represent the literal value of the property. It will be the base, and you don’t need to have many rules for creation, for example:

colorBase {
color.blue.50 = #000022
color.blue.100 = #000033
}

Semantic Token​

Tokens that represent the character of the base design tokens If the designer decides the border color should be the brand primary, the border color will change accordingly.

color.blue.50 = #000022
color.blue.100 = #000033

colorSemantic {
color.brand.primary = color.blue.100
button.border.color = color.brand.primary
}

Types of Tokens​

There are three types of design tokens:

Global Tokens​

Global tokens control all instances of a particular design decision, and can be defined by their context or theme. You can refer to Shades Generator to create tonal colors.

Alias Tokens​

Alias tokens are context-specific and reference global tokens. They are also known as semantic tokens.

Component specific Tokens​

Component-specific tokens are related to the individual parts of a component. Component-specific tokens are self-explanatory and aim to provide enough context about the use of token

Naming Design Tokens​

As tokens become more sophisticated, naming patterns matter. For ease of use, it is recommended to use Category/Type/Item/Subitem/State (CTI) naming conventions to define tokens in a hierarchical tree structure of options and decisions.

Each token combines four levels -

1. Namespace levels combining any of System (wm), Theme (material, branding theme) or Domain
2. Object levels refer to a component (button), Element (left-icon) or Component group (forms)
3. Base levels as a backbone combining Category (color), Concept (action) and Property (size)
4. Modifier levels refer to one or more of Variant (primary), State (on-hover), Scale (100), Mode (on-dark)

Let's see an example token:

How does it work?​

The design tokens can be broken down into a few main steps:

Centralize​

Manage design tokens in a single place in a platform-agnostic format (e.g., JSON or YAML).

  json {
    “color”: {
      “primary”: { “value” : “#3366FF”},
      “text” : { “value” : “{color.primary.value}” },
    },
    “button”: {
      “background”: { “value”: “{color.primary.value}” },
      “text”:  { “value”: “{color.text.value}” }
    }
  }

Transform​

Use a build engine that takes design tokens as input and transforms them into platform-specific or framework-specific style files (e.g., CSS, Sass, iOS, Android, React, etc.). You can develop your own engine, or you can use existing ones like Style Dictionary and Theo.

  css
  :root {
  --color-primary: #3366FF;
  --color-text: var(--color-primary);
  --button-background: var(--color-primary);
  --button-text: var(--color-text);
  }

We will learn more about using design tokens with or without a design system in the coming blogs.

Conclusion​

In conclusion, design tokens are not just a novel concept; they are the game changer for digital product design.

As we simplify the process, we can standardize the creation of design tokens, the naming conventions of design tokens, and the different types of design tokens. Using design tokens instead of hard coded values ensures more flexible design systems that are easy to build, maintain, and scale.

In the next blog post, see how it works with SaaS application and with WaveMaker.

These API endpoints are automatically used by the WaveMaker application UI when they are bound to a variable. If the application is secured with a security provider the existing architecture of the WaveMaker app UI already handles the authentication of the APIs i.e., if the UI and services are in the same application.

The WaveMaker application APIs can also be invoked from different clients. To know more about What is Client.

How can WaveMaker application APIs be used in other clients?​

The WaveMaker application APIs that are exposed can be used in many ways and if the client is,

• A WaveMaker application then the APIs can be imported as a REST service or as Swagger.
• A Non-WaveMaker application then the APIs can be invoked by making an HTTP request to the API.

When WaveMaker APIs are secured with security providers​

APIs exposed by the application are also secured and require authentication to access them when used in other applications.

If the application is secured by any form-based security provider like Database/LDAP/DB/Custom Security, then the client can pass the BASIC authorization header in the HTTP request to invoke the application APIs. Basic authentication has to be enabled to access the APIs and in WaveMaker, by default, basic authentication is enabled for form-based authentication providers.

If the application is secured with an SSO security provider like OpenID, SAML, CAS, then the below approach can be used to invoke the secure APIs.

How can Clients invoke WaveMaker Application APIs Secured with SSO?​

If a client that needs to invoke the WaveMaker application APIs has security configured, the same user context cannot be used to access the WaveMaker secured APIs as the security configured can be different, even if it is the same security provider there cannot be common user context between them.

This can now be achieved in WaveMaker by using JWS or Opaque tokens as the secondary authentication providers. In other words, if the WaveMaker application's APIs are secured and are to be used by other clients then, the user can enable a secondary authentication provider i.e., JWS or Opaque providers. This makes the APIs accept a token and provide user access to the APIs.

For example, consider a client and one WaveMaker application, the application provides some services and has the primary security SAML configured. If the service APIs are to be accessed from the same application UI then the existing architecture of the WaveMaker applications takes care of the complete flow. In this flow, the user is redirected to the SAML server for authentication and once the user is authenticated, they get redirected to the application.

If the same APIs are invoked from a different client, then along with SAML a secondary security provider needs to be configured. Now the client can invoke the API with a bearer token header in the request and gain access to the APIs. To know more about Bearer token.

What is Client​

The client can be a WaveMaker application/Non-WaveMaker application, microservice, Java client, command line, Postman, and so on. The client should have a token of the current user, making the request that is issued by any provider that follows OpenID specification. According to the OpenID specification, the provider returns two tokens, an ID and an access token. Any one of the tokens can be passed in the request as a header while invoking the API.

What is Authorization Server​

An authorization server issues tokens to clients that can be used to access protected resources on the resource server which is known as bearer token. These tokens are usually in the form of OAuth2 ID and access tokens and are issued after the client has been authenticated and authorized by the authorization server. The authorization server is responsible for ensuring that only authorized clients can access protected resources on the resource server.

What is Resource Server​

The resource server is the WaveMaker application which has the service APIs exposed for use. These APIs are secured by the primary security provider but if we enable a secondary security provider that can be one of JWS or Opaque and thus it can accept ID or access token in the request which is being made by the client and provide access to the client. The resource server handles the validation of the ID/Access token. To know more about the differences between an ID token and an Access token, see ID/Access token .

Configuring WaveMaker Application as Resource Server​

WaveMaker application can be configured to accept an ID token or access token as bearer token in the authorization header. It is then validated using the JWS provider if it is an ID token or using Opaque token provider if it is an opaque access token.

This makes the application a resource server that validates ID and access tokens to share resources. To know how to configure JWS or opaque as secondary authentication providers, see Configure JWS and Opaque providers.

Configuring WaveMaker Application as Client​

WaveMaker application can be configured as a client to pass the ID or access token to the resource server. To know more, see How to Pass Logged-In User ID/Access Tokens as Header.

WaveMaker app security configuration has now migrated from XML-based configuration to Java-based configuration. In earlier versions, the Java beans generated during any security change, using security dialog, used to get saved in the project-security.xml file. With this release, WaveMaker 11.4, project-security.xml and securityService.properties files will be removed from the project and the Java beans will be generated dynamically in the WaveMaker runtime.

Why are we Migrating?​

XML configuration beans are generated in design time when a security-related configuration is saved or updated from the Security dialog. By moving beans to the Java configuration there is no generation of XML files which helps in the following.

• Switching security providers based on the profile i.e., users can set different security providers for the development profile and testing/production profile. To know more about profiles, see Configuration Profiles.
• XML changes are no longer visible in VCS as the security configurations are maintained in the WaveMaker app runtime. This avoids confusion as only user changes would be visible in the VCS.
• Any configuration changes/bug fixes in the future will not require any migrations in the user projects.
• In further releases, it would also help in supporting multiple security providers in the same profile in WaveMaker studio.

Backward Compatibility​

As a part of release 11.4, the following profile property names have been auto-migrated in the user projects. In case, the users have been using the below properties in any of their environments or build scripts, they need to perform the below changes.

Although Accessibility is designed for people with disabilities, it helps everyone in general. Accessibility promotes usability. Everyone, in general, can benefit from clear instructions, opportunities to correct form errors, simple visual layouts, high color contrast, and the option to read a transcript or captions to a video or audio recording. Accessibility often describes hardware and software designed to help those who experience disabilities.

Standard practices to ensure AA compliance​

WCAG 2.1 Guidelines: The Web Content Accessibility Guidelines (WCAG) 2.1 provide the most widely recognized and accepted accessibility standards. These guidelines define criteria for making web content more accessible to users with disabilities.

Keyboard Accessibility: All components and interactions should be operable and fully functional using only the keyboard. This ensures that users who rely on keyboard navigation or assistive devices can access all functionalities without barriers. Proper focus management is crucial for keyboard accessibility.

Ensuring that focus is clearly visible and moves in a logical order through interactive elements improves the overall accessibility web apps built with the platform. All modals/dialogs with custom HTML or widgets like date, datetime made accessible by trapping the focus inside them i..e, when a user hits Tab or Shift+Tab or clicks around, they can't escape a certain cycle of focusable elements like anchor/button/input inside the dialog. The only way to escape the focus on dialog is to close it or press Escape key.

Semantic/native HTML: Using these HTML elements is essential to create a well-structured and accessible user interface. This includes using proper heading tags, lists, form elements, and semantic roles to convey the meaning and relationships of content to assistive technologies.

Form Accessibility: Forms on the platform should be designed with clear labels, error messages, and properly associated input fields. This ensures that users can understand and complete forms using assistive technologies. ARIA (Accessible Rich Internet Applications): Implementing ARIA attributes can enhance the accessibility of dynamic and interactive components on the website. ARIA roles and properties provide additional context and information to assistive technologies.

Testing and Validation: Regular accessibility testing and validation should be conducted during the development process. Automated testing tools, as well as manual testing with users with disabilities, can help identify and address potential accessibility issues.

Documentation and Training: Providing comprehensive accessibility documentation and training for web app developers and users helps ensure that accessibility is consistently maintained throughout the development lifecycle.

A Holistic Approach to Embrace AA Compliance:​

Accessibility is not an afterthought; it's an integral part of our WaveMaker’s DNA. From the initial planning stages to the final implementation, we adopted a holistic approach to accessibility, ensuring that apps built with WaveMaker cater to everyone. Aligning with the Web Content Accessibility Guidelines (WCAG) 2.1 AA standards, our team worked tirelessly to address host of issues with AA compliance in our widgets. Clear and consistent navigation, keyboard operability, and color contrast optimization were among the many key aspects we prioritized to create a seamless browsing experience.

1.The Power of Semantic Markup: Recognizing that an accessible app goes beyond mere compliance, we fully embraced the potential of semantic markup. By using appropriate HTML elements with meaningful structure, we enable all users, including those with assistive technologies, to comprehend the content's context and organization effortlessly.

2.Empowering Users with Semantic Elements: Semantic headings play a crucial role in guiding users through our website’s content. By employing a logical heading hierarchy, we empower screen readers to provide users with a comprehensive outline of the information, ensuring easy navigation and comprehension.

3.Enhanced Interactive Elements: Our commitment to inclusivity extended to interactive elements, which received special attention. Every button, link, and form field is equipped with descriptive labels, ensuring that users, irrespective of their abilities, can fully grasp the purpose and functionality of each element.

4.The Impact of ARIA Roles: Incorporating ARIA roles judiciously, we elevated the accessibility of our platform’s dynamic components. Navigation menus, landmark elements, and live regions were thoughtfully annotated, providing users with valuable context through assistive technologies.

5.Unlocking the Power of Data Tables: When presenting data in tabular format, we embraced best practices for table accessibility. Meaningful table headers and descriptive captions not only aid screen readers in properly interpreting the information but also offer a seamless experience to all users.

6.Form Filling Made Accessible: We understood the importance of form accessibility, as it directly affects users' ability to interact with our services. With clear validation messages and error handling, we created a smooth form filling experience for everyone

Accessibility attributes added to different widgets in WaveMaker​

By incorporating many of these recommendations with a focus on accessibility and semantic markup, we aim to create a seamless and inclusive browsing experience for all users, regardless of their abilities.

Data Table: Implemented proper table headers and captions for screen readers to interpret data correctly. Ensured that data cells are logically organized, making navigation easier for keyboard users. Incorporated ARIA attributes to convey additional information about the table structure.

Typography: Utilized appropriate heading tags (e.g., h1, h2, etc.) to maintain a clear content hierarchy. Ensured sufficient contrast between text and background for readability. Made font size adjustable using browser settings to accommodate users with low vision. Added descriptive and meaningful text labels for buttons and anchor links. Provided keyboard focus styling to indicate active elements for keyboard users. Included ARIA roles and states to communicate button states to screen readers.

<label for="name">Full Name:</label>
<input type="text" id="name" name="name" aria-required="true" />

Cards: Made card content accessible to screen readers by using proper semantic elements. Ensured focus order inside the card for keyboard navigation. Made card structures consistent and straightforward for easy comprehension.

Iframe: Added descriptive titles to iframes, conveying their purpose to assistive technologies. Ensured that the iframe content is accessible and adheres to WCAG guidelines.

Lists and Pagination: Utilized semantic list elements (e.g., ul, ol) to provide clear content structure. Added ARIA attributes to indicate the list role and state to screen readers.

Live Filter: Provided accessible feedback to screen readers when filtering results dynamically. Ensured that the filter function is keyboard operable and fully functional without a mouse.

Forms: Implemented form labels, legends, and placeholders to describe form elements clearly. Ensured proper validation messages for screen readers to identify and correct errors.

<button type="submit" aria-label="Submit Form">Submit</button>

Form Widgets: Ensured form widgets (e.g., input fields, dropdowns) are accessible and operable with a keyboard. Provided appropriate labels and instructions for assistive technologies.

Carousel: Implemented ARIA roles and states to indicate the current slide and navigate the carousel. Made navigation buttons and indicators accessible with proper labeling.

Date Widget: Provided ARIA live regions to announce dynamic notifications to screen readers. Ensured that notifications are perceivable by users with visual and hearing impairments.

<label for="eventDate">Select Event Date:</label>
<input type="date" id="eventDate" name="eventDate" aria-label="Event Date" />

Progress Bar: Implemented ARIA roles and states to communicate the progress status to screen readers. Made the progress bar keyboard accessible and focusable.

Messages: Ensured that messages, such as alerts and feedback, are accessible with descriptive text. Used ARIA roles to convey important information to assistive technologies.

Panel, Tile, Accordion, Tabs, Dialog, Wizard, Media: Ensured that all interactive elements within these widgets are keyboard accessible. Provided proper labeling and ARIA attributes for enhanced screen reader support.

Different tools used to test Accessibility​

In our quest to ensure accessibility compliance across our WaveMaker’s diverse range of widgets, we employ various tools and techniques to test and validate the accessibility of each element. Below are some of the tools we leverage to ensure that every widget on our platform is accessible to all users:

Screen Readers (e.g., NVDA/AssistiveLabs and VoiceOver): We test all widgets using popular screen readers like NVDA (NonVisual Desktop Access) and VoiceOver to experience the website as users with visual impairments would. This helps us identify issues and optimize our widgets for smooth navigation and comprehension.

Keyboard Navigation Testing: We conduct extensive keyboard navigation testing to ensure that users can access and interact with all widgets using only the keyboard, without relying on a mouse.

ARIA Validation Tools: We use ARIA (Accessible Rich Internet Applications) validation tools to verify the appropriate use of ARIA attributes and roles in our widgets, enhancing their compatibility with assistive technologies.

Form Accessibility Testing: Our forms undergo rigorous accessibility testing to ensure they are easily navigable and usable with screen readers, providing descriptive labels, and handling errors effectively.

Automated Accessibility Testing Tools (e.g., Axe, Pa11y): We utilize automated testing tools like Axe and Pa11y to scan our widgets and identify potential accessibility issues. These tools help us streamline the testing process and catch common problems quickly.

Browser Developer Tools: The built-in accessibility inspection tools within modern web browsers assist us in identifying and rectifying accessibility issues for each widget.

User Testing and Feedback: Real-world testing by users with disabilities is a crucial aspect of our accessibility evaluation process. We seek feedback from diverse user groups to gain valuable insights and address any usability challenges.

Continuous Monitoring: We continuously monitor our WaveMaker’s accessibility to ensure that any new updates or content additions maintain the same high level of accessibility compliance.

By combining these testing methods and tools, we offer excellent platform to build rich web applications that are accessible, inclusive, and easy to use for all users, regardless of their abilities or assistive technologies. Our commitment to accessibility remains an ongoing journey, and we are dedicated to providing an inclusive experience for users of every app built using WaveMaker.

We are excited to announce the upcoming release of WaveMaker Version 11.4, which will introduce various new features and improvements. With this release, we end our support for WaveMaker 10 projects.

Upon launching WaveMaker 11.0 on June 6th, 2022, our users were provided with the flexibility to work on WaveMaker 10 projects while undertaking the upgrade process to WaveMaker 11, using our Multi-version Studio. With 11.4 release, we are disabling the support for the above facility and auto-upgrading the projects to WaveMaker 11.

What will happen?​

However, with the release of Version 11.4, we will officially discontinue support for WaveMaker Version 10 projects. This decision is aligned with our commitment to delivering the latest technology and ensuring that our users can benefit from the most up-to-date and secure features. As part of this transition, we will be ending support for WaveMaker 10.x projects by September 4, 2023.

What Should You Do?​

After the 11.4 release, our support team will no longer provide assistance or updates for projects running on Version 10. Therefore, we strongly recommend that you plan to migrate your projects to the latest version to continue receiving support and leverage the latest functionalities.

Migrating from WaveMaker 10.x to 11.x​

To aid you in the process of migration, we have prepared detailed documentation on migrating from Version 10 to the latest Version 11.x. To get started with the migration process, see Updating an App from WaveMaker 10 WaveMaker 11.

Upgrade In-progress: Archived Apps​

It is recommended to complete the migration from WaveMaker 10 to WaveMaker 11.x before the 11.4 release. To perform smooth migration, WaveMaker has provided the ability to use the multi-studio projects, this enables you to initiate migration and continue working on WaveMaker 10 projects while you simultaneously implement WaveMaker 11 upgrade. In the process of migration,

WaveMaker 10 projects​

WaveMaker 10 projects that have not been migrated will be automatically migrated to 11.4. Users might face some issues as it is migrated without their interference.

WaveMaker 11 Projects​

For the WaveMaker 10 projects for which the migration process has been initiated, WaveMaker 11 version will be moved to the Archived apps, and the WaveMaker 10 version of the project will be auto-migrated to WaveMaker 11.4.

To avoid auto-migration from WaveMaker 10 to WaveMaker 11, complete the process before 4th September 2023. In case of any assistance, reach out to our support team.

TLS (Transport Layer Security) is an encryption protocol that encrypts all the information communicated between the client and the server. Mutual TLS is an additional configuration in which the server and client authenticate each other, and only then is the connection established. This blog explains in detail what MTLS (Mutual Transport Layer Security) is and why it is used.

Mutual TLS​

Mutual TLS is a configuration in which the client authenticates the server first, and then the server authenticates the client as well. The SSL connection gets established if both client and server are authenticated successfully.

1. Client connects to the server to initiate an SSL connection.

2. Server presents its certificate to the client.

3. The client authenticates the server's certificate from its truststore and can verify the hostname (Optional).

4. Client presents its certificate to the server.

5. Server authenticates the client certificate.

6. Symmetric session keys are created, and an SSL connection gets established.

7. The client and server exchange information in a secure connection.

Server Authentication​

The server presents its certificate to the client, and the client authenticates it. The client authenticates the server's certificate using its truststore. TrustStore is used to store certificates from Certified Authorities (CA) that authenticate the certificate presented by the server in an SSL connection. If the server is using a self-signed certificate, then a custom truststore needs to be generated with the server's certificate, and you must configure it in the client.

The client can then use this custom truststore to authenticate the server's certificate and proceed to further steps in initiating the SSL connection.

Client Authentication​

The client presents its certificate to the server, and the server authenticates it. The server authenticates the client using the Keystore configured using the client key and certificate. When the server authenticates the client, then it proceeds to the further steps in initiating the SSL connection. When the client authentication is enabled along with the server authentication, it indicates that the SSL connection is configured with mutual TLS.

Why is Mutual TLS used?​

Typically, TLS protocol only proves the server's identity to the client, but the server cannot authenticate the client. MTLS provides an additional layer of security in which the server should authenticate the client and prevent unauthorized access.

Configure Mutual TLS in a Webserver​

MTLS is part of the TLS standard, and any web server that uses TLS to secure its connection should be capable of mutual authentication. In order to implement mutual authentication, the server needs to ask the client for its certificate specifically. Web servers are not configured to do this by default. For more information, see tomcat documentation to configure MTLS.

WaveMaker MTLS Support in REST APIs​

WaveMaker now supports mutual TLS in REST APIs or imported APIs using Swagger by configuring a few properties in the application. See Configure MTLS in WaveMaker application for more details.

In this blog we talk about how to make any WaveMaker application Observable by applying OpenTelemetry, Zipkin. While accelerating application development, WaveMaker's generated code allows easy integration with best of the breed tools and applying devops best practices while operating the app in production a cinch.

About Open Telemetry​

Open telemetry is an opensource tool enabling Observability. Observability lets a developer understand an application from the outside without knowing its inner workings and helps in troubleshooting degradations in service quality. To achieve this, a developer should instrument the application. By instrumenting code to emit traces and metrics, and collecting such data developers make the application observable.

Once instrumented, the end user flows become traceable across different microservices. This data can be sent to Zipkin - a popular open source tool.

Benefits of implementing observability​

Metrics, Logs and Traces make up the golden triangle of Observability of any application. WaveMaker built applications can also easily be set up for tracing.

1. Understand why the applications has slowed down.
2. Trace 500 error codes to figure out what went wrong among the microservices.
3. What if one of the application calls is taking too long than expected.

OpenTelemetry tool integration with an application can help have detailed visibility of tracing an application to easily spot almost any issue or have an idea of where the problem could be. Instrumenting WaveMaker applications code lets you get traces for each request, along with their time slices captured in detail.

Four simple integration steps for Opentelemety​

1. Install and Setup tools
2. Instrument application code
3. Build and Deploy application
4. Accessing request traces

1. Install and Setup tools​

How to use OpenTelemetry integration to have complete visibility of the application, Here in this first step explains details to Install and Setup tools and integrate OpenTelemetry and Zipkin with the application deployed at Apache Tomcat.

1. Install Zipkin as default data collector and tracing dashboard. Once the following docker command is run, browse to http://your_host:9411 to find traces. Dashbord will be empty initially.

             docker run -d -p 9411:9411 openzipkin/zipkin
   

2. WaveMaker application can be deployed on specific versions of Apache Tomcat. Install Tomcat by following installation instructions and then copy step 1 downloaded opentelemetry-javaagent.jar to tomcat lib directory($TOMCAT_HOME/lib/)

2. Instrument application code​

OpenTelemetry code instrumentation is supported for Java based applications, here are the steps to Instrument application code.

1. Download latest open telemetry opentelemetry-javaagent.jar from the Open Telemetry repo and place the JAR at preferred directory and launch it with tomcat.
2. Set environment variables by adding the setenv.sh file above the installed tomcat bin directory.

$TOMCAT_HOME/bin/setenv.sh

    export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/usr/local/tomcat/lib/opentelemetry-javaagent.jar”
    export OTEL_TRACES_EXPORTER=“-Dotel.traces.exporter=zipkin”
    export  OTEL_EXPORTER_ZIPKIN_ENDPOINT=“-Dotel.exporter.zipkin.endpoint=http://<zipkin-host-ip>:<zipkin-port>/api/v2/spans”
    export OTEL_SERVICE_NAME=”-Dotel.service.name=<App/service name>”
    export JAVA_OPTS=”$JAVA_OPTS $CATALINA_OPTS $OTEL_TRACES_EXPORTER $OTEL_EXPORTER_ZIPKIN_ENDPOINT $OTEL_SERVICE_NAME”

3. Introduce tracing code: To introduce tracing and create correlations Spring AOP(Aspect Oriented Programming) code changes needed, this code can also be introduced by using the IDE at WaveMaker application.
   Download WaveMaker Application Zip from Studio, extract the downloaded zip file to a directory and call it as $WMAPP_HOME Navigate to the maven pom.xml file to add following dependencies code snippet

$WMAPP_HOME---->pom.xml

      <dependencies>
        <dependency>
              <groupId>io.opentelemetry</groupId>
              <artifactId>opentelemetry-sdk</artifactId>
              <version>1.11.0</version>
        </dependency>
       <dependencies>

Navigate to the project-user-spring.xml in the below path and add the given snippet

$WMAPP_HOME -----> src/main/webapp/WEB-INF/project-user-spring.xml

          <beans xmlns="http://www.springframework.org/schema/beans"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xmlns:aop="http://www.springframework.org/schema/aop"
              xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd 
              http://www.springframework.org/schema/aop   
                  http://www.springframework.org/schema/aop/spring-aop-3.0.xsd ">
                  <!--<context:component-scan base-package="com.aop.aspect"/>-->
                  <bean id="LogAspect" class="com.aop.aspect.LogAspect"/>

              <aop:config>  
                <aop:aspect id="myaspect" ref="LogAspect" >  
                   <!-- @Before -->  
                   <aop:pointcut id="pointCutBefore" expression="within (com.wavemaker.*.*.controller..*) || within (com.wavemaker.runtime.rest.controller..*)|| within (com.*.*.controller..*)"/>  
                   <aop:before method="before" pointcut-ref="pointCutBefore" />
                </aop:aspect>  
              </aop:config>  
          </beans>

Create a new java file with given package structure and copy code to the created Java source file

$WMAPP_HOME ----->src/main/java/com/aop/aspect/LogAspect.java

          package com.aop.aspect;

          import org.aspectj.lang.JoinPoint;
          import org.slf4j.Logger;
          import org.slf4j.LoggerFactory;
          import io.opentelemetry.api.trace.Span;
          import javax.servlet.http.HttpServletResponse;
          import org.springframework.beans.factory.annotation.Autowired;
          public class LogAspect {

              private static final Logger logger = LoggerFactory.getLogger(LogAspect.class);

              @Autowired
              private HttpServletResponse response;

             public void before(JoinPoint jp) {
                  Span currentSpan = Span.current();
                  currentSpan.setAttribute("x-wm-request-track-id", response.getHeader("x-wm-request-track-id"));
              }
          }

3. Build and Deploy application​

Build and Deploy application to reflect above instrumentation code change

1. With above changes build WaveMaker app for WAR and copy built war to tomcat setup at webapps folder ($TOMCAT_HOME/webapps)
2. Restart the tomcat server to reflect above changes at setenv.sh along with the WaeMaker application.

4. Accessing request traces​

Accessing request traces with Use Cases Here is the introduced sample use case at WaveMaker application to imitate calls to other external services, or another microservice and a call to database engine into the application. Following are the Zipkin screenshots where time taken by application request is spent in each function, to pin where the problem is with the call to the microservice and focus on reducing the latency in a service considering the time details exposed. Or, These traces can be used to understand what the workflow of a request is. Another advantage that works is by introducing trace ID in the response payload of the WaveMaker application and using that ID to correlate with other dependency calls.

Every time when a hit to service endpoint of an application is made a trace is captured at Zipkin, to see something like this at Zipkin dashboard by accessing url http://your_host:9411, here are few WaveMaker application request traces.

Click on the show button to see WaveMaker API Composer call details

WaveMaker API Composer call trace info with its status code(500) and Server response time details.

WaveMaker API Composer first GET call with its status code(200) and response time details.

WaveMaker API Composer second GET call with its status code(404) and response time details.

Click on show button for WaveMaker API call details

WaveMaker API generated to access DB trace info along with its status code(200) and response time details.

WaveMaker API generated to access DB query and its response time details.

A new zero-day vulnerability was reported in the Spring library on 29th March 2022, affecting the library versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions. The vulnerability impacts Spring MVC applications running on JDK 9+.

Spring has released a new version on 31st March 2022, 5.3.18, which fixes the vulnerability. The specific exploit requires the application to run on Tomcat as a WAR deployment. The blog post added by Spring has more details about the vulnerability.

Is WaveMaker Application Affected?​

WaveMaker 10 Apps are compiled using Java 8 and supported to deploy on Java 8 only. So ideally, WaveMaker apps are not affected. Applications deployed on Java 9+ are maybe vulnerable if the controller methods use @ModelAttribute or have no annotation. WaveMaker generated controllers either use @RequestParam, @PathParam or @RequestBody. So, they are not affected by this vulnerability.

Risk Mitigation​

Below are two ways that you can follow to mitigate the risk against CVE-2022-22965 before the scheduled hotfix release.

Upgrade the Spring Version Manually in your pom.xml​

Add the latest version of Spring framework bom 5.3.18 as the first dependency under the <dependencies> section of <dependencyManagement> section. Add the following dependencies as specified below.

<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-framework-bom</artifactId>
 <version>5.3.18</version>
 <type>pom</type>
 <scope>import</scope>
</dependency>

Upgrade Tomcat Version​

Upgrade the Tomcat version to either 9.0.62 or 8.5.78, closing the attack vector on Tomcat's side.

• Identity provider (IdP) - producer of assertions, and
• A service provider (sp) - the consumer of assertions.

The identity provider could be any vendor like ADFS, OneLogin, Okta etc. which supports SAML-based Single Sign-On (SSO). The service provider is your WaveMaker application which makes use of Identity Provider to enable single sign-on across all your WaveMaker applications.

Why SAML upgrade is required?​

WaveMaker offers many security providers which can be enabled by the user based on their requirements. SAML is one of the security providers which depends on spring security extensions dependency. The spring-security-saml2-core has reached end of life as per the spring documentation. It means there will no longer be any support or bug fixes for this library from spring.

The saml2-service-provider is the replacement of spring-security-saml2-core and all the WaveMaker projects that are using SAML as a security provider will be migrated.

User changes required after SAML upgrade​

The new SAML library provided by spring suggests the metadata, audience url, SSO, SLO URLs which are different from the old one. So the user has to update the new URLs in their respective IDP providers. Below is a table that differentiates the old and new SAML URLs.

Here app-url can be preview or deployed URL.

Steps to update the URLs in Okta provider​

1. Login to the okta provider and open the configured saml application.

2. Click on the General Settings where the metadata, audience, SSO and SLO URLs are configured.

   

3. Click on edit and update all the 4 URLs as shown in the below screenshot.

   

4. If SLO is enabled in the application then SLO URL should also be updated.

   

   Here SP issue URL is same as metadata URL.

5. After updating the URLs you can preview the application and verify the SAML flow.

You would have to edit pom.xml when changing the dependency versions or add custom configurations for immediate fixes when needed. When you keep adding these configurations, it lengthens the generated pom.xml with the details of the application configurations and the Studio configurations that the developers only sometimes need access to. For this reason, the pom structure has been remodeled to inherit from the parent pom, making it easy to read and manage the code.

Hierarchy with a Parent pom​

We introduce the parent pom to the generated application.

Every generated application must depend on this parent pom, which contains all the generic build resources, filters, profiles, and essential profiles like development/production, repositories, and plugin management.

The parent pom furthermore depends on another pom, i.e., the wavemaker-app-dependencies pom, with all the app runtime dependencies and their versions as properties. The build-helper-maven-plugin is still in the application pom as it contains the list of services created in the application.

This model introduces less verbosity in the generated pom.xml, making it clear and concise for developers to understand, and can easily add further customization to the pom.xml.

Below is a default pom.xml generated when a WaveMaker project is created.

Advantages of New Pom Structure​

Below are a few advantages of adapting to the new inheritance model of pom.

Less Verbose​

All the WaveMaker-related configuration is moved to the parent pom. So the generated pom is more readable, and the developer can easily understand the custom configurations.

Upgrading without Migrations​

In the previous structure, any migrations made to the application would be visible to the user in their VCS. But, since all the WaveMaker-related configurations are maintained in the parent pom, it avoids confusion, and only the WaveMaker Studio version changes would be visible in the VCS.

Ease of Library Version Overrides​

Users can easily override the application runtime libraries, databases, or security dependencies.

1. By adding the new version in the properties of the application's pom.xml

   Example of upgrading log4j version:

   

2. Bypassing the property during application build.

   Example : mvn clean install -Dlog4j.version=2.17.2

Impact on Users Project​

• Database and Security dependencies will now have only the groupId, and artifactId. The version has been removed since it is inherited from the parent pom. If you want to change the version, you can override it by adding the version details in the properties.
• Any custom configurations you made will still be in the pom.xml after the upgrade.

Earlier in this blog, we announced ending support of WaveMaker 9 (WM) Projects. WaveMaker offered support to manage individual versions of your app with our multi-version control system so that you could simultaneously work on both WM 9 and WM 10 projects. One of the key differences between the WM 9 and WM 10 is moving from AngularJS to Angular 11.

Angular laid its plan in January 2018 for the final releases of AngularJS before entering long-term support (LTS) and extended the LTS due to the global pandemic until December 31, 2021. As we reach the end of life of AngularJS, we officially withdrew support of WM 9 projects starting WM 10.12 release planned for February 2, 2022. As a result, the existing WM 9 projects get archived.

WaveMaker Archived Apps​

Typically, when initiating project migration, you have two versions of the project in one folder containing WM 9 and WM 10 projects.

The following diagram illustrates which projects move to the archived location.

Project Upgraded​

Case-1: When you finish the upgrade process, the WM 9 project gets archived in that folder. In this case, the upgraded project, WM 10, remains in WaveMaker apps and has all functionality that a regular WaveMaker app has. The WM 9 version of the project moves to the archived location, which should be safe to delete.

Upgrade in Progress​

Case-2: The projects that have just initiated the upgrade, move to the Archive location as individual projects of their own versions, such as WM 9 and WM 10 projects. These projects automatically move to the Archive location separately. To work on these projects, you can download the project as Zip and import; the project gets imported as a WM 10 version.

Upgrade not Initiated​

Case-3: The projects that have not yet initiated upgrading to WM 10 move to the Archived location as is. You can still import the project as zip and import to use its content.

Accessing Archived Apps​

In WaveMaker Studio, navigate to the topnav tabs displaying WaveMaker apps.

• Go to the Archived Apps tab. You can view all your archived apps here.

Archived Actions​

Archived apps are accessible with limited access. Allowed actions include:

• Download Project as Zip
• Delete Project

WM 9 Project Deployments Not Supported​

With WM 9 projects archived, deploying WM 9 apps are not supported anymore. WaveMaker will not display WM 9 projects in Manage Deployed Apps. All the details related to the project, including logs, releases, history, and app URLs, are removed. However, you can continue to access deployed apps on servers, such as AWS, Google, Azure.

In WaveMaker 10.10, Cordova-android is upgraded to 10.1.0. With that change, it is observed that third-party cookies are not getting stored on the WebView. Cookies are required for WaveMaker authentication. So, a plugin wm-cordova-plugin-advanced-http was used to make ajax calls instead of browser XHR. Following are the drawbacks of using the plugin.

• All network calls are logged into the console of chrome dev tools instead of the network tab.
• There are gaps between plugin API and XmlHttpRequest. Some of these gaps are addressed in the WaveMaker platform to make it work in WaveMaker without any changes in the existing code.

In WaveMaker 10.11, another method is implemented to solve the cookie problem.

Method​

Cordova allows developers to set the hostname through preference in config.xml. 'localhost' is the default hostname. Using this hostname preference, WaveMaker platform automatically sets the server path's (given in export Cordova zip dialog) domain as the hostname. This is done during Cordova zip export. Thus, all cookies from the server path become first-party cookies, and WebView is allowing them to be stored.

Changes needed from the Developer​

By default, this methodology gets implemented in all projects. If the hostname preference is mentioned in config.xml under the Android platform, then WaveMaker does not apply this change and fallback to plugin usage. No changes are required from the WaveMaker developer.

Changes to note​

In Android Apps, location.href now has the server domain as the host. All local app files are served at path https://${server_domain}/_www.

Additional Info​

As iOS does not allow to set scheme as HTTP/HTTPS, this same methodology does not work for iOS. So, the plugin is still being used in iOS for marking AJAX calls.

WaveMaker generates code for applications based on Angular. As part of the continuous improvement efforts, we upgrade WaveMaker to the next major Angular version, 11, in the release 10.11, scheduled for the second week of January 2022.

To learn more, see Angular Version 11 - what's in the release.

Testing Apps on WaveMaker 10.11 Beta​

We invite you to test your applications on the WaveMaker 10.11 beta before officially releasing the 10.11 version. This service is exclusively provided on request. Please get in touch with our support team to access the WaveMaker 10.11 beta service.

The areas change in WaveMaker has been with how lazy loading of JS artifacts work. Our QA team has tested this area, and the release candidate build is now deployed on staging. While testing your applications, pay closer attention to the areas of your application that may be using Prefabs and Partials in particular.

To do​

• Run and test applications containing Prefabs
• Run and test applications containing Partials

What's Deprecated?​

Support of IE 9 and 10 was deprecated in Angular 10 and removed entirely in Angular 11.

A zero-day vulnerability is an unintentional software security flaw identified in the application, poses a zero-day threat.

A new zero-day vulnerability was reported in the Log4j2 library on 9th Dec 2021, affecting the library versions >=2.0-beta9 and <=2.14. It has the potential to allow an attacker to execute the code remotely. Log4j has provided the fix by releasing the 2.15.0 version on the same day. Plus, Log4j has released a newer 2.17.0 version, which is available for production now. For more information, see LOG4J changes report.

Is WaveMaker Application Affected?​

WaveMaker applications that depend on Log4j2 2.14.1 (WM 10.10.1) or lower versions are at risk of the zero-day vulnerability.

Risk Mitigation

There are two ways to mitigate the risk before the planned hotfix release.

Maven: Upgrade the Log4j2 Version Manually​

Add the latest version of Log4j2 2.17.0 dependencies in the <dependencies> section, and NOT under the <dependencyManagement> section in your project's pom.xml file.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.17.0</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.0</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j-impl</artifactId>
    <version>2.17.0</version>
</dependency>

System Properties: Disable Lookups in Log4j2​

Set either the System Property log4j2.formatMsgNoLookups or Environment Variable LOG4J_FORMAT_MSG_NO_LOOKUPS to True. This mitigation does not need rebuilding of the war file. Tomcat or any web application server where the WaveMaker application is running needs to be set to one of the above-mentioned properties and restarted.

Examples for Apache Tomcat​

Follow the below-specified changes to set the System property and System environment variable.

Unix and Mac Systems​

Add the below in the setenv.sh file of the Tomcat bin folder.

1. The following adds a System property.

export JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true” 

2. The following add an Environment variable.

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true 

Windows System​

Add the below in the setenv.bat file of the Tomcat bin folder.

1. The following adds a System property.

set JAVA_OPTS="%JAVA_OPTS% -Dlog4j2.formatMsgNoLookups=true”

2. The following adds an Environment variable.

set LOG4J_FORMAT_MSG_NO_LOOKUPS=true 

WaveMaker Log4j2 Vulnerability Releases​

WaveMaker v10.10.3
WaveMaker v10.10.2

WaveMaker app development generates Angular code, as Angular marks the official withdrawal of the previous Angular versions, including AngularJS and Angular 1.x. Therefore, WaveMaker will be ending the support of WaveMaker 9.x projects that use AngularJS and Angular 1.x by 31 Jan 2022, as Angular announced. The update is primarily focused on improving performance, security, and bug fixes.

We have covered some essential FAQs to help you understand how you can migrate to the latest version of WaveMaker Studio.

What does the end of support for WaveMaker 9.x entail?​

Suppose you are using 9.x projects. In that case, WaveMaker will automatically update to the latest version of WaveMaker. The update can break applications that contain custom JavaScript code because of the Angular breaking changes. We have created a guide to help you update to the current version used by WaveMaker, Angular 10.

Please note that following 31 Jan 2022, we will not be supporting project migrations. Therefore, we recommend you plan to update your WaveMaker 9 projects to receive support before the established deadline for a smooth migration process.

Why is WaveMaker ending support for the 9.x version?​

End of previous version system means moving on to newer and better systems. Even though some updates are not entirely responsible for security vulnerabilities, they might impact stability and usability. Other updates address bug fixes and customer-requested features.

View the progress of WaveMaker features and fixes in Studio.

A glimpse of the updates:

• Outdated application stack: AngularJS ends the support by 31 Jan 2022, including security issues. Learn more about AngularJS version support status
• Latest angular stack Angular 10
• Several performance improvements
• Security vulnerabilities in the dependent third party libraries to get the benefits of up to date technology stack
• Support for new compression technique
• Enabling micro frontend enablement
• Wavemaker-generated code is now Veracode certificated
• ngx-bootstrap upgrade with enhanced features

Some Examples of UI Enhancements:

• Enhanced DSL APIs exposed on various widgets
• Advanced client-side and server-side validations on Form fields
• Custom Data Formatters for UI widgets
• Summary row in Datatable widget
• Ability to add multiple views in a prefab through partials
• Ability to provide widget level properties in a prefab
• Adding tablet view support to Mobile apps

And so much more. Read WaveMaker release notes to understand the features and fixes better.

How do I know if I have WaveMaker 9.x apps?​

When you launch WaveMaker Studio, you can see the orange bar at the top indicating that you are using 9.x projects.

When you start the project update, the project card converts into a folder. The folder contains all the versions of the app, including WM 9.x and WM 10.0. You can independently work on both versions.

For more information and a guide to update, see Upgrading an App from WaveMaker 9.x to WaveMaker 10.0.

How WaveMaker will help you with the update?​

Updating Angular is not relatively straightforward. However, our developers at WaveMaker have made it a little easier for you. When you initiate an update, WaveMaker takes care of the major part behind the scenes.

Even so, if you have included customizations, i.e., adding custom JavaScript code, you'll have to check and accept changes manually by verifying every single customization that runs through the process. This approach is taken care of by the inspection framework that we explicitly developed to guide you through the migration process. Further to this, you can reach out to our support team for more assistance.

What does end of support mean for your customers?​

The deployed apps will not be affected by the change to the end-users.

What happens if you do not upgrade to WaveMaker 10?​

If you have already deployed the 9.x WaveMaker applications, the change will not affect it. However, making alterations would no longer be possible for the app.

WaveMaker Online (WMO)​

The application projects will automatically upgrade to the latest version of the Studio.

WaveMaker Enterprise (WME)​

You will no longer receive support, and we cannot offer the license extension.

WaveMaker 10 Releases​

• WaveMaker 10 Preview
• WaveMaker 10.GA
• WaveMaker 10.1
• WaveMaker 10.2
• WaveMaker 10.3
• WaveMaker 10.4
• WaveMaker 10.5
• WaveMaker 10.6
• WaveMaker 10.7
• WaveMaker 10.8
• WaveMaker 10.9
• WaveMaker 10.10
• WM 10.10.3 - Log4j2 Dependency Vulnerability

For the detailed list of releases, including biweekly ones, see WaveMaker Release Notes.

In Git flow, the main (or master) branch contains your production-ready code. You can use the main (or master) branch for CI/CD integration. The other branches, feature branches, hotfix branches should contain work on new features and bug fixes and will be merged back into the main (or master) branch when the work is finished and properly reviewed.

Git Flow Considerations​

While working with the Git flow branching strategy, there are six principles you should adhere to to ensure you maintain good code.

1. Any code in the main(or master) branch should be deployable, production-ready.
2. Create new descriptively-named branches off the main branch for new work, such as feature/add-new-payment-types.
3. Commit new work to your local branches and regularly push work to the remote.
4. To request feedback, help, or when you think your work is ready to merge into the main branch, open a pull request.
5. After your work or feature has been reviewed and approved. It can be merged into the main branch.
6. Once your work has been merged into the main branch, it should be deployed.

Advantages of Git Flow​

1. Because of the simplicity of the workflow, this Git branching strategy allows for Continuous Delivery and Continuous Integration.
2. This Git branch strategy works great for small teams and web applications.

Implementing in WaveMaker​

WaveMaker supports the creation of a project using an existing branch in Git. We can follow the above Git model using the below steps:

1. Creating an Application (for example, SampleApp) from WaveMaker will create a repository with the main (or master) branch in Git.
2. By Default, all Contributors of this Project will push their changes to main (or master).
3. Anything in the main (or master) branch is deployable.
4. The above application will always point to the main (or master) branch.

5. To work on something new, go to the Git portal (for example, Github, Gitlab etc) and create a branch from main (or master) in the repository (for example, SampleApp). Give it a descriptive name (for example, feature/new-oauth2-scopes).

6. Now again, from WaveMaker, go to option Create Project Branch for the application mentioned above (for example, SampleApp), and create a project branch by selecting the appropriate branch. Following the above example, we’ll select branch feature/new-oauth2-scopes. This will create a new branch project, pointing to the branch feature/new-oauth2-scopes.

7. Developers can start collaborating and working on this project, named feature/new-oauth2-scopes, and can regularly push their work.

   1. Developers can review the changes using Preview in WaveMaker.

   

   2. Users can also deploy the feature branch to an external testing environment using a branch from Git or exporting a war file from WaveMaker. Refer to the below screenshot to download the war file.

   

8. After the required changes are done and tested in the feature branch, you can merge it into the main (or master). Merging the feature branch into the main (or master) branch is done outside of WaveMaker and through Git portals like Github, Gitlab, etc.

   1. In our example, Merge feature/new-oauth2-scopes branch into the main (or master) branch from Git portals like Github, Gitlab, etc.

9. Once it is merged and pushed to main (or master) branch, you can PULL the latest changes into the main (Master) Project (refer to Steps 1, 2 & 3) and deploy from WaveMaker or use CI/CD to deploy from the main (Master) branch.

   1. Users can deploy from a master project from WaveMaker for Testing the main (or master) branch.

   

   2. User can configure the main (or master) for Continuous Integration and Continuous Deployment in their external deployment pipeline.

Consequently, we have developed a roadmap to update the platform with the Release 10.9 scheduled for the 13th of September 2021, which includes the Angular 10 update. If you are a WaveMaker application developer who uses your own infrastructure to build and deploy the application, you need to read further.

This update requires you to take action, i.e., updating the Node and NPM versions. To avoid breaking changes, we have recommended the following steps described in this blog post.

What's in the Update​

This update impacts building WaveMaker apps using your own CI/CD pipeline using the Angular Build.

How WaveMaker can Help​

There are two ways to upgrade to your build system with Angular 10.

1. Download and install Node and NPM in the build system with the versions specified above.
2. Use resources provided by WaveMaker team.

Using Docker Option​

If you are using Docker images for building WaveMaker application, you can use them in the following ways:

• Using them from the public repo containing pre-built Docker image developed and published by WaveMaker.
• Using Docker files to build the Docker images. For more information, see Build with Docker.

Testing your Application​

We recommend you test the application to see if the build is successful. For this, you must test the application using the Angular Build. If the build fails, we request you to contact our support team with logs.

Why Accessibility?​

Although Accessibility is designed for people with disabilities, it helps everyone in general. Accessibility promotes usability. Everyone, in general, can benefit from clear instructions, opportunities to correct form errors, simple visual layouts, high color contrast, and the option to read a transcript or captions to a video or audio recording.

In the IT world, Accessibility often describes hardware and software designed to help those who experience disabilities.

Features of Accessibility Websites​

• Good use of HTML headings
• Accessible with the keyboard
• Accessible images
• Accessible menus
• Accessible forms
• Accessible tables
• Effective use of color
• Meaningful link text

Accessibility in WaveMaker​

To make components accessible, all the text on the web page must be unique, along with its captions and roles. To make it possible, we have introduced aria-labels attributes for all the wm-widgets which are configurable and certain Role to identify every component as per their standard behavior. This ARIA "roles" and "attributes" will benefit the group of people using Assistive Technology Readers (ATR) to read the text and the purpose of the widget aloud to the users.

WaveMaker Accessibility enhancements will cover Web Content Accessibility Guidelines (WCAG) "A" and "AA" compliance for all non-text content, including the following.

Name Role & Value, Info, Relationships, Meaning Sequence, Sensory Characteristics, Identify Input Purpose, Non-Text Contrast, Page Titled, Headings and Labels, Label in Name, Language of Page, Status Messages, Error Prevention.

Good Use of Headings​

To make good use of headings on a page, add CSS class name from the Style properties tab, for example .h1, .h2, .h3, etc. Using any of the above headings class name, an attribute "aria-level" will be assigned to the HTML structure to make the screen readers understand the text specificity while scanning a page. You can copy the heading caption to the hint property to make it ARIA accessible.

For more information on how to use accessibility, see Accessibility in WaveMaker.

Bundle Tool​

An aab file cannot be installed directly on a device. This is a format for publishing to Play Store. For development, apk can still be used. Incase if you want to install aab file, apk file has to be generated from aab file. Google released a tool called bundle tool to help developers in this regard. BundleTool is a jar file (requires Java8 or higher) that can be downloaded from here. After downloading the jar, create an alias (in Linux or MAC) as follows in bashrc.

alias bundletool="java -jar BUNDLE_TOOL_JAR_PATH"

Example command to generate apk file:

 bundletool build-apks --bundle="./people_wavemaker(0.0.1).debug.aab" --output="./people_from_aab.apks"

Example command to install apk on a connected device

bundletool install-apks --apks="./people_from_aab.apks"

For more commands supported by bundletool, check this link.

wm-cordova-cli breaking change​

Previously, packageType is an argument in the build command to specify the type of build (development or production). This argument is renamed to buildType in 2.0.0. Now, packageType is used to specify the type of package. For Android build, options available under packageType are bundle (for aab) and apk. Since, ipa is the only format available for ios apps, there is no packageType option for ios build.

Changes in AppChef​

In the build step of creating a new cordova build, a new dropdown is introduced to capture User's choice of Android Package. This dropdown is only visible when a ceretificate for Android build is selected. This dropdown has only two options (aab and apk). If the build type is development, then Android package is set as apk. If the build type is production, then Android package is set as aab. Users can override the default behaviour with their choice.

Google Anouncement​

Starting from August 1st 2021, Google Play Store will allow only new app submissions in aab format. Check the Google Anouncement here.

These database import flows have now been optimised to enable faster database imports in the application. Let's have a look ahead on how this was done and how would this affect the app developers.

How did we enable faster database imports in Studio?​

When a database is imported into an application, the schema is read to discover relationships between the tables and individual table schema as well. Armed with this information, WaveMaker generates REST API and creates hibernate entities for each of tables in the database.

Like mentioned, during this import operation, to read the schema information and relationships metadata for the tables, there are a set of metadata queries for each respective database type, that are run in background on the system tables in the database. These metadata queries have now been fine tuned across all database types, keeping in accordance with the query standards listed for high performing queries.

How were the queries optimised?​

Below is a short insight about the approaches taken to fine tune the queries for better loading times:

• Nested select queries were avoided
• Avoided iterating through the same resultset due to join operation
• Used left outer joins instead of general joins or where clauses
• Select field instead of select * from system tables
• Used WHERE instead of HAVING to define filters

How does it impact the Studio developer?​

As a result of this enhancement, the WaveMaker developer will have a better experience when working with databases while building the application. The import/re-import operations of database in the application will be quicker than the earlier times.

From the tests we did, the some of the queries used in database import operation are 600x faster. As a result, the time taken for the entire process of code generation for database entities during database import operation and the respective API generation powered by WaveMaker, is almost cut by half approximately.

Note: The performance improvement ratio is proportional to the number of constraints and relations defined for the tables in the database.

Based on the statistics generated at our end during the QA phase, the metadata for a database with around 800+ tables and heavy constraints for the entities was read in less than 4 seconds due to the optimised metadata queries.

Do try out our database import feature and let us know your feedback.

How Redshift Architecture Works​

Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. You can start with just a few hundred gigabytes of data and scale to a petabyte or more.

Amazon Redshift achieves efficient storage and optimum query performance through a combination of massively parallel processing, columnar data storage, and very efficient, targeted data compression encoding schemes.

Redshift is a data warehouse cluster which is a combination of nodes. If a cluster has two or more clusters then an additional leader node exists which coordinates between the nodes and handles external communication. Each compute node has its own dedicated CPU, memory, and attached disk storage, which are determined by the node type.

A compute node is partitioned into slices. Each slice is allocated a portion of the node's memory and disk space, where it processes a portion of the workload assigned to the node. The leader node manages distributing data to the slices and apportions the workload for any queries or other database operations to the slices. The slices then work in parallel to complete the operation.

Redshift in WaveMaker​

From version 10.7.0, WaveMaker has extended its support to allow a dedicated section for the Redshift database.

If you have been working with the Redshift database earlier, which allowed importing as read-only mode, you can now import a Redshift database with read and editable modes. Further, you can customize Redshift tables in the database designer. Perform queries and create variables to compose data that you can incorporate into the UI to display devised data in Charts, List, Data Table, and more.

Connecting to Database​

Using the Connect to DB option allows you to import the Redshift database from the Databases menu. WaveMaker takes care of adding the driver dependency in pom.xml.

For instance, in the following image, consider an employee table was imported into the project.

By importing Redshift tables in editable mode, you can create new tables and modify existing tables from the database designer directly in WaveMaker instead of using the Redshift DB console.

Using the above table, you can create List, Data Table widgets, etc., and perform CRUD operations on it.

Querying Redshift Database in WaveMaker​

From the Query Editor in the Databases menu, you can run all types of queries and procedures and save them, which you can use to create variables and bind them to the widgets.

The queries can also have parameters that you can dynamically pass during runtime. Below is an example query of the Employee table that has employeeId as a parameter. For more information, see Working with Queries in WaveMaker.

Using Redshift DB for Creating a List Widget​

Drag and drop a List widget and configure the List widget by selecting the same employee table discussed in the earlier points.

After configuring the widget, you can preview the application and view the table data as a list.

Already using a Redshift database?​

Import the Redshift database by following the how-to’s doc Connect To AWS Redshift Database.

In case you don't​

Below are the steps to get you started to launch a Redshift cluster:

1. Sign in to AWS Management Console. Use the following link to open Amazon Redshift console − https://console.aws.amazon.com/redshift/
2. Create a Cluster and select the number of nodes, node capacity, and other database configurations.
3. After the cluster creation, you can get the hostname, port, JDBC connection string from the cluster console. Use them to import into WaveMaker.

SAP HANA Database​

SAP HANA Cloud is a fully managed in-memory and column-based cloud Database as a Service (DBaaS) offered by SAP that helps in managing your data storage and integration while running powerful applications.

In SAP HANA, the data is completely stored in the main memory. When the main memory limit is reached, the whole database objects, including table, view, etc., that are not used will be unloaded from the main memory and saved into the disk. For example, in a column store table, data is stored vertically. So, similar data types come together, which provides faster memory read and write operations with the help of the In-Memory Computing Engine.

SAP HANA in WaveMaker​

Earlier, you could import and integrate the SAP HANA database with WaveMaker applications. However, when importing a SAP HANA database using the Other option, you could get read-only mode.

With release 10.7.0, WaveMaker supports read and editable modes with a dedicated section for SAP HANA. Hence, with this upgrade, you can create variables with CRUD functionality to develop List, Data Table, and develop an application using more such widgets within a few clicks.

Connecting to Database​

Using the Connect to DB option allows you to import the SAP HANA database from the Databases menu. WaveMaker takes care of adding the driver dependency in pom.xml.

For instance, in the following image, consider an employee table was imported into the project.

Using the above table, you can create List, Data Table widgets, etc., and perform CRUD operations.

Using SAP HANA DB for Creating a List Widget​

Drag and drop the List widget and configure the List widget by selecting the same employee table discussed in the earlier points.

After configuring the widget, you can preview the application and view the table data as a list.

Editing Tables​

When you import SAP HANA tables in editable mode, you can create new tables and modify existing tables from the database designer in WaveMaker instead of using the SAP HANA console.

Already have a SAP HANA Database?​

Import the SAP HANA database by following the how-to’s doc Connect To SAP HANA Database.

In case you don't​

The following steps help you to launch the SAP HANA instance:

1. Sign in to SAP HANA cloud central console.
2. Launch an SAP HANA instance with the required memory and other database configurations.
3. After the instance creation, you can get the hostname, port from the SAP HANA database explorer.

As a part of brand unification, our digital team has been working hard to create a better online experience for our customers. For this reason, we are moving to a new domain for WaveMaker Documentation.

Starting June 21, 2021, our new domain for Documentation will be docs.wavemaker.com/learn.

RSS Feed​

If you have subscribed to our Team Blog via RSS feed, we request you to update the feed URL to continue to receive news and updates from our Engineering team.

Updated URL​

https://docs.wavemaker.com/learn/blog/feed.xml

Alternatively, find the updated URL when you navigate to blogs as well, as shown below.

Though there are no other significant changes in the layout and context, we have made it just a little easier for our customers and clients to find us online and convey a more cohesive brand identity.

Take a peek into what's new in this release.

What's New​

• Working in branches offers the standard SDLC workflow for making fixes on already released version of your WaveMaker aoo while rest of the team continues sprinting on the next release. You can now create a branch for the released version of the app and make your hotfix on that branch from within WaveMaker. This feature is available in our "Teams" offering.

• While support for branching requires enhancements to how VCS operates, including how you manage projects, groups, and organizations. See how these changes your current workflow if you are a member of WMO Teams.

• Are you already a part of the Amazon ecosystem? In that case, we have good news for you. With the support of the Redshift database in WaveMaker, get speedy, high performance, horizontally scalable, with the ability to add massive capacity storage—all in the cloud using clustering model.

• Are you using SAP HANA in your SAP modules? With SAP HANA implementation in WaveMaker, import the SAP HANA database into your WaveMaker application for seamless integration, supporting the columnar data model. It improves flexibility, performance and uses an in-memory store with the read and editable modes.

• Limitations to access public servers apply to most organizations. We understand. All the essential UI Artifacts to generate and build an Angular app are published to the npm central repository. Incorporate UI Artifacts and simplify your CI-CD pipeline using the standard npm repo without worrying about firewall restrictions safely.

• In the times before world changed, and you could go grocery shopping, you knew where to find the items you need as they are neatly classified into categories. A new property called Groupby helps you group and classify data to arrange things systematically. We introduced this property within several widgets, including Select, Search, Chip, Radioset, and Autocomplete.

Improvements and Bug Fixes​

In addition to new features, improving the existing ones is just as important. We fixed some critical bug fixes and enhanced several features. See the full list of bug fixes here and enhancements here.

Do you have a great idea of what you'd like to see next? Let us know here.

See Also​

Release Notes 10.6
Release Notes 10.5
Release Notes 10.4

Why?​

Over time, we have seen that though the theme builder tool was efficient to kick start with branding changes, it lacked in the styling details of what each project needs. There was a need to handle the advanced styles with an option to view the changes. We understand that only coding without preview is baseless, So here is the solution to those problems that every developer faces.

With the new enhancement to the theme builder tool, We have introduced a new code editing option to create themes more efficiently. The new feature will help develop a full-fledged theme with the branding configuration and advanced modifications as per project requirments.

How does it work?​

Theme editor will continue the styling configurations till Step 4, followed by a new "Code Editor" button, which starts a new window to the bottom of the screen.

Steps to follow:​

• Click next to continue the initial flow till Step 4.
• Click on the code editor button to the left corner in the footer.
• A code panel will popup to the bottom, with the preview application vertically sectioned.
• Explore the capabilities like Add, Override, and Modify based on the needs of each project and save the file.

• Checked your changes and repeat the steps to style more.
• Bring the focus to the editing lines and try Ctrl F to search for classnames whenever required.
• Close the editor to go back to the branding changes anytime and choose "Okay" to override the progressive changes made.

• When ready, download the theme and import to the projects.

Editor's tips and tricks​

We will share few easy way tips to help you get faster and more productive while editing the theme file.

• The editable file is in .less format. Hence, the changes should start inside the class name parenthesis .wm-app{ }.
• The code editing starts from the 11th line from .wm-app{ }. The lines above are not editable due to complications with the respective path.
• With every change, saving the file is mandatory to reflect the changes in the preview application
• The CtrlF function will work when focused on the editable lines.
• CtrlZ function will revert your changes to the initial state.
• To override the styles, search for the class name and address applicable changes.
• If theme selected is flat or gradient, The classnames might duplicate for overriding purpose. Search and modify accordingly.

• Add proper comments for every piece of code rewritten in the file.

Bug Fixes​

1. Added more screens in the preview application with all the WaveMaker components to test the theme styles.
2. Checkboxes and radio button borders were half cut when set the font size to 10px or 11px. Fixed now
3. When the secondary button is focused, the text changes to primary color instead of active contrast color. Fixed now.
4. Changed the build settings of the preview application to load the assets faster.
5. Fixed the alignment issue for the select widget down arrow when the gradient theme is selected and imported to projects.
6. Dynamic form labels were not vertically aligned when selected a flat theme or gradient theme. Fixed now.

Will be back with more updates.

What happens if you don't scale your application?

It is the point when an application can no longer handle additional requests effectively that will limit its scalability. This limit is reached when the resources run out, requiring more machines or more capacity.

In this article, learn about scaling approaches and how WaveMaker scales an application.

Understanding Scaling Approaches​

Following are the two approaches for scaling an application.

1. Vertical Scaling
2. Horizontal Scaling

Vertical Scaling​

In simple terms, Vertical scaling means adding more resources to the server, for example, increasing the capacity of the CPU, RAM, and DISK space in a single machine to "scale-up". Vertical scaling is limited to the capacity of a single machine, therefore, scaling beyond that capacity often involves downtime when switching from a small machine to a bigger machine.

Horizontal Scaling​

Horizontal scaling means it scales an application by adding more machines into the pool across the horizontal direction to "scale-out", and the scaling is based on partitioning the data. It replicates the application by growing the number of nodes in the cluster. Also, distributing the responsibilities of each node and providing additional end-points for client connections.

Which one is better for your application?​

The decision depends on a number of factors, including the following.

1. Is the application request volume steadily growing?
2. Is the application's current growth experiencing spikes that lead to service degradation?

Combine these factors with the application's unique requirement to evaluate and determine the optimal scaling approach.

However, when you compare both Vertical and Horizontal approaches, Horizontal scaling offers a benefit of elasticity. Instead of taking your server down while you are scaling up to a better one, you keep your existing pool of resources online while adding more to what you already have. By adding more machines to the existing pool, you are not limited to the capacity of a single machine, and that scales your application with almost no downtime, and you do not get caught into the resource-shortfall.

WaveMaker's approach for Scaling Applications​

Although horizontal scaling is the desirable approach for scaling an application, there are still a few challenges that need to be addressed. Let's understand that first.

How data partition can be a challenge in Horizontal scaling​

The following image shows a deployment architecture of Horizontal scaling.

With Horizontal scaling, the data gets distributed among the nodes, and each node contains only a part of the data. Therefore, the user-session created by a node cannot be understood by the other node. In this case, when the user logins again, it rejects the request if the request goes to another node.

WaveMaker generates open standards code based on Spring for the back end. So, for Horizontal scaling, Spring Session Module implementation can be used, configured to handle session management for the application.

Integrating Spring Session with WaveMaker​

Spring Session manages user's http session information while supporting clustered sessions without being tied to an application container specific solution.

In the following illustration, see how WaveMaker applications scale horizontally; specifically, storing user authenticated sessions when the requests are served by different nodes using the round-robin mechanism and without using any sticky sessions.

Distributed Persistence of User Authentication Session Architecture​

For this approach, WaveMaker uses spring-session-core as a runtime dependency. It distributes the persistence of the user authentication session. With a distributed session registry, the user session created by a node can be understood by the other nodes by persisting the user sessions in a distributed manner.

Spring-session based on External Store​

There are two ways for configuring external session stores depending on your requirements by choosing from Redis and JDBC. To configure with Redis as an external store, WaveMaker adds spring-session-data-redis along with lettuce-core dependency. Similarly, for JDBC, we add a spring-session-jdbc dependency. WaveMaker internally adds these dependencies to scale applications and handle session management for the application.

With release 10.6, all the WaveMaker applications provide an option to opt for Horizontal scaling by choosing from Redis, JDBC, along with MapSessionRepository as a Distributed Session Registry.

MapSessionRepository is an In-memory type that does not scale the application horizontally, and it is the default settings when you create a WaveMaker application. To enable Horizontal scaling, simply select an option from the dropdown, and follow the on-screen instructions. To learn how to use this feature, see Horizontal Scaling using Session Persistence.

With WaveMaker 10.6 release, we have fixed a few bugs. Know more details here.

Input URL​

New feature Step-2 unlocked for Generating Theme Colors

Introduced a new flow to identify the colors of a website using the Input URL option. Follow the steps below to use this feature.

1. Go to the Dashboard page of the Theme builder app.
2. Click *Input URL and generate*.

3. Enter a website URL. For example, https://www.google.com/, and click Search URL to generate the color palette of the website.

4. A prompting message displays on the Editor page with the generated colors with a maximum of six colors that are highlighted. However, the preview application continues to use the default colors of the existing Material theme.

5. You can design WaveMaker components with the new colors and preview them right away.

6. When ready, download the theme.

Bug Fixes​

1. The list widget data is now replaced with the real data in the preview application.
2. A new page template called Dashboard1 is newly included for the preview application. You can navigate it from the left navbar.
3. Added Panel Secondary to the preview application to check the color changes for the secondary theme color.
4. Fixed issue related to gradient background that was not consistent for widgets when previewing the application switching to gradient theme for UI elements, including Nav, List, Panel backgrounds, Checkboxes, and Radio buttons.
5. Changed the default option for the Spacing property in General Settings from default to comfortable to match the default Material-2.0 theme.
6. Fixed issue related to Border radius panels that were not consistent when changing from none, less, and more.
7. Fixed the list item active state that did not match the color selected for the gradient theme in the left navigation.
8. Fixed the state colors that did not reflect the tiles widget.

That's all for now. See you soon with more updates.

Introduction​

In HTTPS handshake, the server responds with a public certificate issued by Certificate Authority (CA) to establish a connection. If CA, or Root certificate was compromised and issues a certificate without the domain owner's consent, the client may face the Man-in-the-middle (MTM) attack. To protect users from this vulnerability, an app can employ SSL pinning.

Certificate Pinning is an additional layer of security that protects communication between client and server. The Standard HTTPS verifies whether the connection is secure but it cannot verify whether you are communicating with the actual server or an intercepted server.

What Certificate Pinning offers​

Standard HTTPS establishes a secure connection and checks whether the server certificate was issued by a trusted CA. Certificate Pinning additionally forces the client app to validate the server certificate with a known copy of the certificate.

The client application contains the pinned certificates which are pre-defined "known" certificates. During the time of communication between the client and server, the client expects the server certificate to match with any one of the pinned certificates. If it does not match, the client will terminate the connection.

Web Certificate Pinning​

Web Certificate Pinning is dynamic pinning. Certificates are pinned during the initial connection establishment. It was introduced in 2015 but was deprecated in 2018 due problems it created than resolving the actual problem.

Mobile Certificate Pinning​

Mobile Certificate Pinning is static pinning, in which the certificate is bundled with the app. This means new app has to be installed on the certificate expiry.

Advantages of Certificate Pinning​

• Certificate Pinning protects data tampering even if the user installs a malicious CA with or without knowing.
• If a trusted certificate authority gets compromised due to security vulnerability, the application will not get affected.

Problem Associated with Certificate Pinning​

A security researcher has warned the risk associated with using HTTP Certificate Pinning.

• If the key was accidentally deleted, stolen, hacked, you may face serious application downtime issues.
• Domain hijacking - on Domain-hijacking, you can lose control of certificates, and hijackers can mishandle your certificates.

What next?​

Certificate Transparency (CT) was introduced in 2018 after deprecation of Web Certificate Pinning. CT is an open-source framework for monitoring and auditing certificates. This standard creates a public logger that records all the certificates issued by the trusted CA. You can monitor these loggers to detect mistakenly-issued certificates, compromised CAs, and CAs dishonesty.

CT in OpenSSL, whenever a connection is initiated, SSL certificates' timestamp will be used to fetch the certificate from the CT log and compared to establish the connection.

Conclusion​

Though CT is different from Certificate Pinning, it will effectively replace the Certificate Pinning without compromising the quality of service.

Have a great idea for what you'd like to see next? Let us know here.

Following plugins are not required for WaveMaker10.6 platform. During the upgradation process, these plugins are removed from config.xml.

1) cordova-plugin-file-transfer 2) cordova-plugin-local-webserver 3) cordova-plugin-transport-security 4) cordova-plugin-wkwebview-engine 5) cordova-plugin-telerik-imagepicker

With cordova-ios@6.1.0 upgradation, WaveMaker supports from iOS-12.0 (and above). As recommended by cordova, WaveMaker supports Launch story boards in iOS. Due to that, minimum number of splash images in iOS got reduced to 8.

Here are some highlights of what's in this release.

What's new​

1. Upgraded to Angular 9

2. Spring Session Persistence - uses the spring-session-core library for session management

3. Page Cache - a new flag called Cache is introduced on the Page tag

4. Retain State for Widgets - to efficiently save and restore UI state

5. Command-Line for Building Cordova Zip - generate Cordova Zip outside WaveMaker Studio

6. Alternative to PhoneGap - WM-Cordova-CLI

7. AppChef App for generating APK and IPA

8. Public npm Registry

9. Central Maven Repositories

10. Up-to-date Libraries

11. Docker Upgrade

Bug Fixes​

Some of the critical bugs have been fixed in the release. See the list of bug fixes of WaveMaker 10.6.

As a modern development team, we are adapting to the latest technology trends. If there is anything you feel WaveMaker should have, do let us know here.

See Also​

Release Notes 10.5
Release Notes 10.4

• Switching between different tab panes in a Tabs widget.
• Switching between different accordion panes in an Accordion widget.
• Selecting items in a List widget and navigating between different pages of the List(pagination).
• Searching, Sorting, Row Selection, and Pagination in a Data Table widget.

Problem​

When any of the the above actions are performed in a page and the User navigates to another page, on navigating back to the previous page using Browser back button, the previous state is lost. All widgets of the page go back to their initial states. There should be a way to retain the state such that even when the user refreshes the page or shares the URL with someone else, they land on the page at a particular state.

Solution​

Retain State feature is coming to the rescue in Wavemaker 10.6 release! The actions performed above can be retained in the URL, Local Storage or Session Storage. A Behavior property called Retain State has been exposed for the supported widgets. This gives us the flexibility to be able to choose different State retention mechanisms for different widgets as and when required.

A sample URL with state information(provided that URL was chosen as Retain state mechanism) is shown below.

https://local-studio.wavemaker.com/run-jm4351st8w/StatePersistenceApp_master/#/Main?wm_state=('ws'~('RepsTable1'~('search'~!('field'~'city'_'value'~'New'_'matchMode'~'anywhereignorecase'_'type'~'string')*_'sort'~('direction'~'asc'_'field'~'name'))))

A reserved query param called wm_state is appended to the URL which contains the state information.

Supported Widgets​

As of 10.6 release, out of the box support has been provided for Tabs, Accordions, Lists and Data Tables. Support for other widgets will be incrementally added in the future releases. However, the below methods have been provided so that Users can retain state for other Widgets/Variables as well.

DSL API​

The below DSL methods have been exposed to cater to the custom use cases which a User can have. Mode is an optional parameter which can be passed for Widgets which don't support state retention by default. If no value is passed then mode will be defaulted to 'URL'.

1. setWidgetState(widget, value, mode?)​

   Sets the passed value to the state information by using the passed widget instance. Example:

On changing a text box value, we want to add a state param in the url.

Page.text1Change = function($event, widget, newVal, oldVal) {
    var stateService = App.getDependency('StatePersistenceService');
    stateService.setWidgetState(Page.Widgets.text1, {
        textValue: newVal
    });
};

2. getWidgetState(widget, mode?)​

   Will return the value set against the passed widget. This will be called on page load (typically in onPageReady). Based on the value returned, operations can be performed.

Example:

Page.onReady = function() {
    var stateService = App.getDependency('StatePersistenceService');
    var widgetState = stateService.getWidgetState(Page.Widgets.text1);
    if (widgetState && widgetState.textValue) {
        Page.Widgets.text1.datavalue = widgetState.textValue;
    }
};

3. removeWidgetState(widget, key?, mode?)​

   Removes the passed widget’s state information from the State Object. If a key is passed, then only that particular entry will be removed, not any other entries for that widget.

Example:

//Initial State: widget_state = {“TextBox1”: {“textValue”: “Hi”, “numberOfKeypresses”: “5” }};
stateService.removeWidgetState(Page.Widgets.text1);
//Updated State: widget_state = {};

4. setStateVariable(variableName, value, mode?)​

   Sets the passed value to the state information by using the passed variable name as key.

Example:

stateService.setStateVariable('Variable1', {
    numberOfTimesInvoked': 2
});

5. getStateVariable(variableName, mode?)​

   Checks if the passed variable name has any state information available in the url or not.

Example:

stateService.getStateVariable('Variable1');

6. removeStateVariable(variableName, mode?)​

   Removes the passed variable’s state information from the URL.

Example:

//Initial State: variable_state = {“Variable1”: {“textValue”: “Hi”, “numberOfKeypresses”: “5” }};
stateService.removeStateVariable(“Variable1”);
//Updated State: widget_state = {};

New Features​

Adding new fonts​

Our new additions to the list of font-family will allow the users to select from trendy fonts for their application.

Modified the preview app​

• Added a new layout for the Dashboard page. On change of the state colors (primary, info, warning, danger) the same will reflect for the icons used to show the overview details (tile blocks)

,

• Components like Headings, Labels, and notification alerts can be viewed in the "Others" link of the left navigation. Labels can be either with background color or only text color change as per the class selected.

• Modified the user profile menu

• Added new components to the preview application for the users to get a better idea while creating their theme. These elements can give a brief idea of how the theme will look like. Hence added Buttons, Dropdown, Panels, Panel subheadings, Tree, Badges, Nav list, Breadcrumb, Accordions, and Top navigation list.

Feedback dialog​

Introduced the new feedback dialog for users to share their experience using the app. We will be looking at the feedback received to carve next set of updates to the app.

Google analytics​

Integrated google analytics to track and report the traffic visit to the theme builder site.

Bug Fixes​

1. Alignment issues when layout selection includes a right nav on the page. This works fine now
2. Redirection changes from #main to #Dashboard page to support google analytics. Working now
3. Fixes to support the instant changes of the color and theme style of newly added components in the preview application. Works now
4. On change of the primary color to a darker shade like #333, the hover/selected state of data table rows was effected. This is fixed now and the hover state will always apply a lighter shade of the primary color selected.
5. Font selection for heading tags (h3 to h6) was not working. This is fixed now.

See you again with more updates.

Introduction to PostgREST​

PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations.

Structure of PostgREST generated OpenAPI Documents​

Generally, the structure of an OpenAPI document generated out of a Spring/Node etc app looks like this.

   {
       "paths":{
           "/employees":{
               "post":{
                   "parameters":[
                       {
                           "in":"body",
                           "name":"employee",
                           "description":"employee",
                           "required":true,
                           "schema":{
                                "$ref":"#/definitions/Employee"
                           }
                       },
                       {
                           "in":"header",
                           "name":"Prefer",
                           "description":"Preference",
                           "required":false,                           
                           "type":"string"
                       }
                   ]

               }
           }
       },
       "definitions":{
           "Employee":{
               "type":"object",
               "properties":{
                   "empId":{
                        "type":"string"
                   },
                   "empName":{
                        "type":"string"
                   }
               },
               "title":"Employee"
           }
       }
   }

The above document indicates that the POST API expects an employee parameter of the type Employee in body and a Prefer parameter in header, therefore expecting the below parameters:

• Prefer in header
• empId and empName in Request Body

Now let us see an OpenAPI document generated out of PostgREST.

{
    "paths":{
        "/employees":{
            "post":{
                "parameters":[
                    {
                        "$ref":"#/parameters/body.employee"
                    },
                    {
                        "$ref":"#/parameters/preferReturn"
                    }
                ]
            }
        }
    },
    "definitions":{
        "Employee": {
            "type": "object",
            "properties": {
                "empId":{
                    "type":"string"
                },
                "empName":{
                    "type":"string"
                }
            }            
        }
    },
    "parameters":{
        "preferReturn":{
            "in":"header",
            "name":"Prefer",
            "description":"Preference",
            "required":false,
            "type":"string"
        },
        "body.employee":{
            "in":"body",
            "name":"employee",
            "description":"employee",
            "required":true,
            "schema":{
                "$ref":"#/definitions/employee"
            }            
        }
    }
}

Not only does WaveMaker allow importing of the REST API, but by parsing the entity definitions we generate user interface that handles create, read, update, delete of the entities. WaveMaker form generates form fields corresponding to the entity definition in the OpenAPI documentation.

If you have a look at the request parameters for the POST API, you can see that they are references to a different object in the document. So we will have to parse these parameters from the root level parameters object. On having a closer look at the body.employee parameter, we see that it is of the type Employee. We will have to parse its properties from the root level definitions object. By parsing these, we identify that the API expects the below parameters:

• Prefer in header
• empId and empName in Request Body

Since we did not have this kind of parsing logic in 10.4, we were unable to extract the form fields on dragging a Form widget for Employee Entity.

This feature is part of WaveMaker 10.5 release. Checkout more details on what is included in this release.

Conclusion​

The OpenAPI support in WaveMaker has been around for few months now and with this release we are making this more robust. Our target is to be able to import API from varied sources so that our users can quickly build out web, mobile applications. We would love to hear from you, if you have tried this feature out. Write to us at info@wavemaker.com.

1. UI Tests based on Selenium
2. API Tests based on RestTemplate

We have multiple environments i.e., Development, Staging and Production for WMO and several on-premise WME environment setups for enterprise customer releases. Our development team uses feature branches and when they merge these branches onto the master branch, we have to make sure all the existing automation tests pass. On a regular basis when each feature team performs a merge, we run a full set of automation tests at their beck and call.

If a new build is promoted to Production from Stage, and at the same time if a merge is performed onto master or a build request is raised to trigger tests in the development environment, multiple test automation setups are needed simultaneously. Imagine, the amount of Devops automation needed to provision, de-provision the infrastructure needed for these test setups and delays caused in the process.

Previously, we used to have a handful of server machines where automation tests for one product environment can be run as a Job on a single machine. To complete the tests it takes a definite amount of time and to parallelize, multiple threads can be configured with each thread running a browser with UI functional tests using Selenium. If the threads are increased, browsers crash due to lack of sufficient memory needed for running selenium tests.

Due to this, We wanted to build a scalable architecture which efficiently utilizes the infrastructure capacity and doesn’t require a lot of Devops effort to scale up and down our automation test setups.

Solution​

We explored Kubernetes (k8s) Jobs for test execution and wanted to completely automate the process of automation test setups, No beck and call!

First let us familiarize a few terms used in the Kubernetes world.

Cluster: A cluster is a set of nodes or machines for running containerized applications.

Node: A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the Master.

Pod: A Kubernetes pod is a group of containers that are deployed together on the same host. Pods can be horizontally scale, which represent services in the micro services world.

Job: The main function of a job is to create one or more pods and track the success of pods.

Namespace: Namespaces help pod-to-pod communication using the same namespace. Typically used for application or environment grouping.

Test environment provisioning with k8s​

Provisioning separate test setups for different product environments is done by creating separate namespaces for API and UI Tests in a k8s cluster for each environment. For every request to run test automation, a Jenkins task is started that generates a k8s spec file and launches a k8s job.

As the test repo keeps updated frequently by the QA team with new automation tests, we compile and create an image and push it to the kubernetes registry.

Once k8s Job has started, a Pod will be created to execute commands in the k8s spec file given below

• Maven command to execute tests
• Upload test results to s3.

On completion of above commands, respective Job status will be changed to complete.

Automation tests for multiple product environments i.e stage or prod, will be executed in a k8s cluster as shown in the below picture.

For each product environment, there will be an API namespace where a k8s job is run to execute all the API tests. For running UI tests, Zalenium is used which requires a separate k8s namespace for running the remote driver and the browser container. K8s job for UI tests communicates to Zalenium’s remote driver and based on the configured threads the browser containers are scaled up to run these UI tests simultaneously.

In the case of test execution for multiple product environments, If resource/memory is not sufficient to create a browser container then k8s cluster can be configured to scale up on demand. After the pod execution is done k8s will perform a health check and close the nodes if no resources are being utilized.

Conclusion​

With this approach, our automation test setup provisioning for multiple product environments has been completely automated, we can scale up and down nodes to speed up test execution times due to scalable infrastructure. Since, we have enabled parallel execution of selenium tests using multiple browser instances, we have achieved significant time reduction for running the tests.

Checkout what is in our latest release WaveMaker 10.5 here.

1. Failing to honor multiple/single flag in some of the cases.
2. UI for selecting images and UI for selecting videos are completely different.
3. There is no option to select files from Google drive or Cloud drive.
4. UI to select files (filetype: file) is very basic and doesn't provide much file information (thumbnails, last modified time etc.,).

WaveMaker allows creation of mobile applications by a simple drag and drop approach. Click here to know more.

Solution​

A Cordova plugin was created (with open source license) by WaveMaker team to address the above problems. Please visit github repo of the plugin to know more about the plugin.

This plugin requires Swift 4.2 runtime, which was released in 2018. Since iOS13, Swift 4.2 runtime is part of the iOS. For earlier versions of iOS (10-12), Swift 4.2 runtime is added to IPA bundle by the XCode. Due to that addition, the size of IPA will increase (~70 MB). If your app doesn't need to support iOS version 12 and lesser, changing deployment-target preference in config.xml to iOS 13 will reduce the IPA size.

WavaMaker mobile apps automatically upgraded to use this file picker​

Like always, with WaveMaker product updates, we also migrate applications that are already implemented. So if your WaveMaker mobile app was using file picker plugin then you simply get the new & better functionality without taking any action.

Known Issues​

1. In iOS, selection of multiple videos from local Photo Library is not supported. This issue is addressed in WaveMaker 10.6.0 release.

   This feature is part of WaveMaker 10.5 release. Checkout more details on what is included in this release.

This feature is part of WaveMaker 10.5 release. Checkout more details on what is included this release.

As per the Google stats link shared above, BBC lost 10% of its users with each additional second the site took to load & Pinterest gained 15% users signup when the perceived load times were reduced to 40%. So, performance is one of the important factors to consider in app development. An app with good performance can help businesses in better signups, enhanced user engagement & result in improved sales.

Performance in WaveMaker​

WaveMaker is a low code platform that continuously works on performance optimizations so that it helps customers to not only build quickly but deliver application that load fast. WaveMaker adopts the best practices that are evolving in the world of web applications and brings those to its customers & applications.

When a user accesses an app, the speed with which it loads & becomes responsive is a testimony to its performance. Each page in the application infact needs multiple resources to be loaded. The loading speed is a function of below-listed factors,

• Size of the resources loaded by the page
• Network Speed
• Number of HTTP Resource Requests required to build the page
• Time spend on the server in crafting the response
• User perception of app readiness

WaveMaker generates Angular code for the applications. Thus has the flexibility to leverage Angular build tools to optimize the application for better load times. Besides, if third party dependencies are required, modular libraries are preferred. WaveMaker component library of 100+ rich widgets. Still, the application build is only composed of components used. Below is the summary of optimizations that are delivered over past releases,

• Treeshaking/Dead Code Elimination, with the help of Angular Production Build & modular component library
• Lazy Loading of Routes & Components, so that user is served with just the required code as they navigate pages of the app
• Enable modern compression algorithms such as gzip & brotli for all the requests reducing the network load & time.

With the current release i.e., version 10.5, WaveMaker team is pleased to announce support for deployment of frontend artifacts onto a Content Delivery Network, which can help in reducing the download time of static resources by ~30%.

Content Delivery Network​

A Content Delivery Network(CDN) is a set of the geographically distributed servers which together enable fast, reliable & secure delivery of internet content including HTML, Javascript, Stylesheets, Images, etc.,

With CDN, the content is served from the CDN-edge server closest to the user location helping in faster load times. With caching & other optimizations CDN also reduces the amount of data origin servers must provide, thus reducing hosting costs. With its distributed nature CDN can ensure better availability and can handle failures better than any origin servers. With all these benefits CDN ensures consistent user experience for an app across the geographical locations.

To enable an application to make its artifacts served over CDN, the developer needs to handle additional operations such as,

• Configure the Origin source & Content Delivery Network
• Managing build artifacts with each release
• Cache invalidations to ensure the user is served latest response
• Additional operations based on CDN provider & more

But we wanted our low code developer to have access to all the CDN goodness very easily. So WaveMaker has made it available on click of a button, literally. With the current release, when the user deploys the WaveMaker app by clicking the "Deploy" button, it is deployed on AWS with CDN support without any additional configuration. This convenience is only available in the first phase of the deployment pipelines of the application. Note that, applications are deployed to this phase so that the app can be tested by the team & only last for limited period of time. See deploying to live phase.

CDN intergration with WaveMaker​

Under the hood, WaveMaker handles all operations required for CDN deployment of apps as listed below,

• Build process is updated with artifacts generation for front-end only static assets such as javascript, CSS, etc.,
• Upload the static assets of the project to Amazon S3
• CloudFront which is AWS-CDN service provider configured with all the required properties.
• Updates the deployed project to serve static assets from Cloudfront CDN.

Thus ensuring the customers benefit from CDN advantages for every app developed with no additional effort.

However, for deploying onto production, the customers may prefer their cloud service provider with the help of CI, CD pipelines. Here is the documentation on how to configure your CI,CD pipeline to deploy to CDN. In the subsequent releases, we will also support one-click deployment to deploy on customer cloud providers.

Results​

Below are the stats from WaveMaker testing with CDN integration comparing the download times of static assets for some of the standard sized applications,

As stated, improving performance is a continuous endeavor for WaveMaker & more optimizations will be delivered to the customers with each release. So, stay tuned for more. Also please share your thoughts or feedback on the optimizations achieved or other approaches to improve the performance of WaveMaker apps to info@wavemaker.com

As a modern development team, we are adapting to the latest technology trends. If there is something you feel WaveMaker should have, do let us know here.

Now, let's jump straight to see what's new in this release!

Deploying to CDN​

Well, speed matters!

Ensuring a consistent user experience is important not just in terms of features and looks, but also in terms of speed. With our 10.5 update, we are all set to adapt CDN into WaveMaker. This allows WaveMaker apps to work together with geographically distributed servers that enable fast, reliable, and secure delivery of the content. Now, you can deploy your apps with CDN automatically. To read our developer blog, see delivering your apps faster with WaveMaker.

Custom Formatter​

Customize data more SPECIFIC to your audience!

You can now write custom data formatter to convert data from services to a well-formatted data before showing it in the UI. You can control how you want to show data depending on the role, country, currency, and more.

For example, John is a card-holder, he can view his card details without any restrictions, whereas the bank admin cannot see his complete card number, which is masked with specific characters as shown below.

To learn about the usage of this feature, see Using Custom Formatter for masking sensitive data.

Data Table Widget Summary Row​

If Data Table is your widget, this is for you!

A table is considered as the most preferred method to represent data that talk! And having to do more with the Data Table adds so much value to it. And we are thrilled to add a summary row function, which helps you to calculate the summary with in-built javascript functions like sum, minimum, maximum, percent, and more.

To learn more about how it works, check out the Data Table summary row documentation.

Smart Widget Templates​

Just pick, click and apply away!

For Cards, List, and Wizard widgets, you can now quickly choose alternative UI representations while you can visually see the changes as you click on the template - just how the SmartArt works in PowerPoint.

For more information about applying a template as well as a layout from the canvas, see Using Smart Template and Layout for Widgets.

Extended Micro-frontend Support​

Smaller apps are easy to develop, maintain and communicate with each other!

In the last update 10.4, we introduced support for building Micro-frontend applications. This architecture encourages the independent delivery of frontend applications with a Node-based CLI. A CLI helps to convert WaveMaker apps to Single-spa compatible app. This release includes the version update of single-spa-angular to 3.4 for better support of Angular 7 projects.

Well, that's not it​

Some of the critical bugs have been fixed in the release. See the list of bug fixes here.

And most importantly, despite the lockdown, our team is staying agile and adapting to be able to deliver product updates. Stay safe and go ahead and create that application to digitise and create new efficiencies.

They come with obvious advantages as these micro services are:

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

Problems in a micro service architecture​

Although micro services make it easy for the services to be micromanaged by individual owners, it poses a challenge to the consumer of these APIs. For example a front end app that wants data which may be served at different micro services, the client has to make an API call to each microservice and combine the data to finally consume it in the UI elements. There is also the problem of over fetching and under fetching with these APIs. There could be certain fields in the data from one API, which the UI client may not even need, but still a bloated data is fetched.

Let's consider a simple example of a bookstore app with just two entities, a Book and an Author. Each entity is maintained by an individual microservice.

In order to display details of a book, minimum two API calls are required to be made, one to get Book info and one to get the respective Author info. Similarly, to display an Author details with all the Books written by them, two API calls are required to be made, one to get Author info and one to get the list of books for that author.

This approach has visible issues such as:

• multiple API calls required to be made to get relevant data, resulting into chattiness between client and server
• this makes the app brittle and multiple calls slow down the app
• since each micro service is now exposed to the client, all of them have to be made secure

GraphQL in a micro service architecture​

In order to solve this problem, the framework that is being widely used these days is GraphQL. One way to look at it is that GraphQL can be leveraged as an API gateway for interacting with multiple micro services, each dedicated to a single resource type while living alongside standard REST routes.

GraphQL and micro services are a perfect fit, because GraphQL hides the fact that you have a microservice architecture from the clients. From a backend perspective, you want to split everything into micro services, but from a frontend perspective, you would like all your data to come from a single API. GraphQL lets you split up your backend into micro services, while still providing a single API to all your application, and allowing joins across data from different services.

If the bookstore scenario discussed above is implemented with a GraphQL middleware, the architecture would look something like below:

What is GraphQL​

GraphQL is an API that was invented and open sourced by Facebook as a better replacement for REST. It can be understood as Query language for APIs, which enables declarative data fetching by exposing a single endpoint and responds to queries. In REST, there is always a dedicated endpoint for each type of request and can't be customized. In GraphQL, the client decides what data they need and that's the reason the client sends a query (payload) to the server and the server sends the data back as per the query request. There is where they get the name GraphQL GraphQL is, in many ways, one of the more powerful tools an API provider has in terms of providing singular endpoints to the consumer and controlling data flow.

Here is an example of a query to fetch an Author by id:

Type system in GraphQL​

GraphQL’s powerful expressive ability mainly comes from its complete type system. Unlike REST, it regards all resources in the entire Web service as a connected graph, rather than a resource island, which can be accessed when accessing any resource. Access other resources through connections between resources.

The bookstore schema graph would look something like below:

Wiring data with a GraphQL query​

GraphQL can simply be treated as the middleware of a back end system. Hence, it is very easy to plug it in with existing systems. For example, in NodeJS implementation of GraphQL, data against a query can be fetched via a resolve function, that simply returns a promise. The logic to query the data (e.g. calling an existing REST API) can be written in this resolve function.

For our bookstore app, the NodeJS implementation to fetch Author details by id would look something like below. Note the resolve function. Data here is fetched from a MongoDB model.

    author: {
        type: AuthorType,
        args: {id: {type: GraphQLID}},
        resolve(parent, args) {
            // fetch author by id from MongoDB
            return AuthorModel.findById(args.id);
        }
    }

Similarly, while defining the Author schema type object, the logic to fetch all Books under the author can be wired as below. Again, notice the resolve function.

const AuthorType = new GraphQLObjectType({
    name: 'Author',
    fields: () => ({
        id      : {type: GraphQLID}, 
        name    : {type: GraphQLString},
        age     : {type: GraphQLInt},
        books   : {
            type: new GraphQLList(BookType),
            resolve(parent, args){
                return BookModel.find({authorid: parent.id})
            }
        }
    })
})

Authentication and Authorization with GraphQL​

Authentication and authorization are other issues that need to be considered when using GraphQL. Do we process them before or after the GraphQL parsing process? To answer this question, you can think of GraphQL as a DSL (Domain Specific Language) on top of your own backend data acquisition logic. We just need to think of it as an intermediate layer that can be placed between the client and our actual data service (or multiple services). Then consider authentication and authorization as another layer. GraphQL is not useful in the actual implementation of authentication or authorization logic because it does not mean it. However, if we want to place these layers behind GraphQL, we can use GraphQL to pass the access token between the client and Auth API. This is very similar to the way we authenticate and authorize via the RESTful API.

Integrating with a WaveMaker App​

The GraphQL implementation (irrespective of the language implemented in) exposes a REST endpoint which is always a POST call with the query as request body. Now, this GraphQL endpoint can be imported into a WaveMaker app like any other REST API through the REST API import interface in WaveMaker studio. Once imported, UI can be built while binding to the GraphQL data in the form of a service variable without writing any code on the UI. Follow the document on working with REST APIs in a WaveMaker app.

Conclusion​

GraphQL is really good at describing schemas but also stitch together different APIs and the end result is something that's really useful for someone building an app as querying for data will be very simple. Different APIs is exactly what we have when we have a micro services architecture. Using GraphQL on top of it all means we can reap the benefits from our chosen architecture at the same time as an App can get exactly the data it needs.

A theme is a preset package containing graphical appearance details. It is often used to change the look and feel of multiple things at once, which makes the elements less granular than allowing the user to set each option individually. For example, you can specify your company's branding colors for your project.

Link to the app: http://apps.wavemakeronline.com/Theme_Builder/#/Dashboard

Customize color, typography, and style​

To begin customizing a theme, one can modify values for color, typography, and style. By default, the preview application starts with the material theme applied. We can switch between different theme styles and instantly preview the changes.

Color​

To change your theme colors, replace the predefined #HEX color code with a custom color.

Primary color maps to all active components and elements like(primary buttons, selected tabs, nav items, etc), while secondary color accents the icon colors for date and time selection. Background color applies to the scrollable content, while the text color maps to the body text and captions used in the application.

Header and Left nav colors define the coloring scheme for background, text, and active links. We also have More options to handle the notification and disable state colors.

Typography​

To change your theme's typography, choose the options from the dropdown, be it font-family, or the size of headings and body text.

Style​

Applying different styles like Flat, Material, and Gradient. This will help you understand how the components change. Each selection will override the existing behaviour of the elements displayed in the preview section.

Flat: The flat-theme includes a solid background to the elements with active states. It also adds an outlined border for user inputs.

Material: The material-theme has a sleek finish with elevated shadows to understand each element's relative importance and focus their attention.

Gradient: The gradient theme fills the content blocks with a linear gradient shade starting from top to bottom.

How to build a theme​

1. Go to https://apps.wavemakeronline.com/Theme_Builder/#/Dashboard
2. Click on the Explore/Create themes
3. On the Editor page, customize the #HEX values with your brand colors.
4. Select applicable font-family and sizes for your content and heading texts.
5. Switch between styles types to suit your requirement accordingly.
6. Icons changes are in progress (coming soon)
7. Click done, and give a name to your newly created theme from the dialog.
8. Import and apply the downloaded theme into any of your WaveMaker applications.

Modifying all the variables in your editor will create your new theme ready to download. Once provided a name, the theme will be downloaded as a .zip file. Import and apply to the WaveMaker built applications.

Bingo! We are ready with the theme.

What's next​

In the next release version, we will feature the icons and more styling options.

Update: Check out additions we made in the second release since this announcement.

See Also​

For more information on developing themes, see Creating themes.

Quick Recap​

Link to the app: http://apps.wavemakeronline.com/CoronaTracker/

Previously, we covered how to import REST API as datasource for the app and how to create a variable to access the REST API, and binding the widgets to the created variable.

For more information, see Corona Tracker App, walkthrough of the app, and how to build the dashboard.

How to build Charts Visualization​

WaveMaker has in-built nvd3 based charts which are used for building plots for visualization in this app. Drag-n-drop any chart widget to canvas and bind the dataset property to the Variable for plotting data as shown below.

Configuring axes​

After binding the variable for the dataset, configure x-axis and y-axis from the attributes of the dataset. By just picking these attributes your chart will be ready for viewing.

In this particular case for the bar chart, we have picked country on x-axis and confirmedCases attribute from API, to be depicted for each country on y-axis.

Configuring titles​

In the advanced settings for chart widget, there are several configuration options provided for configuring the axis titles, values, bar spacing etc.

Top countries bar chart is ready!

Wait, How did we pick only 10 countries from the entire list of 180+ countries returned by the API?

Also, how did we calculate the metrics for “Rest of World”?

This is where low-code comes into play, you can write javascript code to customize your dataset. After fetching the API response, you can calculate any custom metrics and also create a separate dataset for top countries as shown.

How to build Maps Visualization​

Maps is not an in-built widget in WaveMaker, using datamaps javascript library a Prefab is created. Datamaps takes JSON input for countries with their code and a colormap to plot the visualization.

Prefabs are typically built by a javascript developer who knows the nuances of working with a javascript library and creates a widget or prefab out of it. The Prefab developer will provide attributes that are available to WaveMaker low-code developers when the widget is dropped onto the canvas.

Creating a Prefab​

The following are the attributes provided by the Datamaps prefab developer that will appear in the Studio properties panel for binding.

Testing the prefab independently​

A Prefab project is another type of a project, where you can build a reusable component or widget and publish it to the workspace. Prefab developers will be able to test the prefab independent of the application by providing test data through an editor, as shown.

Publishing a Prefab​

After the prefab is tested independently, it can be published to the workspace so that WaveMaker developers can start using it as a widget in the Studio.

Using Maps Prefab as a widget​

After the Prefab is published, under the prefabs section in Studio the maps prefab appears just like any other widget.

Defining Color Map and Dataset​

Color map needed for the maps prefab can be created as a variable, shown below.

Using javascript, we have created a custom maps dataset from the REST API response, by calculating the color codes based on the confirmed cases in each country as shown.

Summary​

Using single-click deployment from WaveMaker, the app is deployed on to containers and made available publicly. Entire application was built by a single developer in 1 week.

See Also​

COVID-19 Visualization using WaveMaker - Part 1

Using WaveMaker, you can almost instantly create a chart or plot for visualization from any datasource. There are several API sources for COVID-19 data and with no code, using out-of-the-box widgets and charts the application has been built in just a few days.

In this series of blog post, we discuss how to build a dashboard, and in the next post, we will see how to build visualization for charts and maps. But before, let's do a little walkthrough of the app.

Corona Tracker App​

Link to the app: http://apps.wavemakeronline.com/CoronaTracker/

Not only can you quickly build the dashboard, it is responsive automatically and one can access it on a mobile device as well as on a large screen.

Quick walkthrough of the app​

The Corona Tracker application has an extensive dashboard with key metrics globally, i.e. Confirmed cases across several countries, recovered, deaths reported etc. The dashboard provides visualization for top 10 affected countries, plotting their death rates against recovery percentages, number of affected people in 1 million population etc.

This app also features datamaps with data set published by John Hopkins University, to visualize the spread of COVID-19 across the globe over a timeline.

How to build the dashboard​

Using WaveMaker, the elements of the dashboard can be built in just 4 steps without writing code.

1. Import datasource, REST API in this case
2. Create variable to access the REST API
3. Visually drag-n-drop widgets onto the canvas or editor
4. Bind the widgets to Variable

Step 1: Import datasource, REST API in this case​

The primary source of data for the dashboard are the following 2 REST APIs:

https://api.coronatracker.com/v3/stats/worldometer/country

https://api.coronatracker.com/v3/stats/worldometer/global

Import the REST APIs using Web Services import editor, as shown below

Step 2: Create Variable to access REST API​

Create a Page for the dashboard, and create a Variable within this page for the imported REST API, which enables invocation of the API whenever the page is accessed.

Step 3: Drag-n-drop widgets on to Canvas​

Key metrics for confirmed cases, recovery & deaths are built as tiles as shown. Each tile is further divided into sections using a Grid Layout which can be further customized to represent the data. Grid Layout is used to define the arrangement of various widgets on the page, by dividing the page into several responsive blocks. The size of each block can be configured and new columns and rows can be inserted as needed.

Step 4: Bind widgets to the Variable for data​

After arranging the widgets on the canvas, we can bind data to these widgets from the created variable using the Properties panel. WaveMaker automatically identifies the JSON response structure from the imported REST API and makes it available for binding through variables.

Bingo! We have the metrics from the REST API in our dashboard page.

Wait!, how did we get the other metric for % of recovered people?

Apart from just binding the data to API response, WaveMaker enables writing simple expressions as shown below to compute data. f(n) = (totalRecovered * 100) / totalConfirmed gives the % recovery, alongside using other data formatting rules.

Step 5: Deploy to the cloud and we are done!​

For more information, see how to deploy an app with One-Click Deployment.

What's next?​

In the next series of the blog post for developing a Covid-19 visualization using WaveMaker, see how to build visualization for charts and visualization for maps.

See Also​

COVID-19 Visualization using WaveMaker - Part 2

You can configure the deployment topology as per your requirement and then with a single button click, WaveMaker platform's deploy feature generates the docker files needed to build images, generates the K8S YAML files needed for deployment and triggers the K8S APIs for deployment. Customer's don't have to write even a single line of K8S YAML file!!

WaveMaker offers a pre-defined set of delivery phases which enables team a progression through Demo, Stage and Live phase. This let's you thoroughly verify your apps before taking them to the live environment.

Demo phase uses WaveMaker's internal cloud. But the Stage and Live phases need to be configured to use your own AWS, Azure or GCP accounts. To this list of cloud providers to choose from, we are now adding Digital Ocean. This is the first Kubernetes based cloud provider supported by the WaveMaker Platform.

Let us introduce you to the DigitalOcean Kubernetes cluster and walk you through the benefits of a Kubernetes based cloud provider and its deployments.

Introduction to DigitalOcean Kubernetes​

DigitalOcean Kubernetes (DOKS) is a managed Kubernetes service that lets you deploy Kubernetes clusters without the complexities of handling the control plane and containerized infrastructure. Clusters are compatible with standard Kubernetes toolchains and integrate natively with DigitalOcean Load Balancers and block storage volumes.

Why to choose Kubernetes based deployments?​

Before getting to the "why", let's understand first what basically is a kubernetes based deployment? To understand the scope of this, let us first go through and compare the different era's of app deployments:

Traditional deployment era: Every application was run on a physical server. Since no boundaries were defined for the applications in the physical server, there were instances when one application would take up all the resources resulting in all other applications to underpeform. Scaling of applications was difficult as resources were underutilized.

Virtualized deployment era: Virtualization being the solution for shortcomings of the traditional deployments, also provided security of application's information as the applications were isolated between the VMs.

Container deployment era: Containers, as we all know, are considered as lightweight systems as they are decoupled from the underlying infrastructure and at the same time have their own fileSystem, CPU, memory, process space etc. to maintain isolation between applications running. Containerized based deployments became popular due to multiple benefits like resource isolation, resource utilization etc.

So then why do you need Kubernetes and what can be done with it?

Kubernetes deployments, you can say, are nothing but containerized deployments only, with Kubernetes providing you with a framework to manage container resources, scaling and failover for your application. For ex: if a container goes down, another container needs to start. Wouldn’t it be easier if this behavior was handled by a system? Kubernetes helps us with this process and many other features that are good for the infrastructures!

• Auto Scaling,
• Self healing,
• Service Discovery,
• Storage orchestration are few among the features that the application developer receives on adapting to Kubernetes based cloud provider deployments.

Now that we understand the benefits of a Kubernetes based deployment, let us understand how WaveMaker platform simplifies the deployment process.

What does an application developer need to deploy his app on DigitalOcean Cloud?​

To deploy your application on DigitalOcean cloud, all you would need is a DigitalOcean account.

There are two stages involved for setting up the live/stage phase of the release pipeline with the DigitalOcean cloud provider:

• Configuration of DigitalOcean cluster
• Deployment of application to DigitalOcean cluster

Configuration of DigitalOcean cluster​

After choosing DigitalOcean Provider from the list of providers, an access token needs to be provided.

To spin up a new cluster in your account some configuration details need to be provided as well:

• cluster region,
• cluster name and
• cluster capacity.

After providing these details WaveMaker spins up a new cluster in your Digital Ocean account.

Alternatively, you may well choose to use an existing cluster already present in your account.

This cluster is then associated with the live/stage phase of the release pipeline.

Deployment of application to DigitalOcean cluster​

Once the live/stage phase of the release pipeline is associated with a cluster in DigitalOcean account, you are now ready to deploy.

There is no need to write K8S specific yaml files or build any app images!

WaveMaker automatically generates dockerfiles, builds a docker image, generates the K8S manifest files and deploys the application to cluster using K8S API's.

Also, the app memory and number of pod replicas are completely configurable from UI.

The cluster creation process and the app deployment process are executed as jobs and run in the background, allowing you to continue with your development while the cluster creates or the application deploys.

What happens post the app is deployed?​

Now post deployment, the app developer is returned with a Service URL which is the URL of the deployed application.

Not only is the application deployed on a kubernetes cluster, but the platform also returns deployment specific information like

• namespace at which the application has been deployed,
• the image used for the deployment process,
• the cluster version and
• worker node size being used etc.

You can use the kubectl commands with the associated kubernetes cluster or debug the image in the associated registry.

Go ahead and try out your app's first ever kubernetes deployment and let us know your experience!!

References​

• To know more about Kubernetes, see here
• To know more about DigitalOcean Kubernetes, see here
• Detailed process for deploying a WaveMaker application on DigitalOcean cluster

Deployment​

When user invokes Deploy operation, WaveMaker executes the maven command to build the project and generate artefacts for deployment. Build steps includes angular production build to generate optimized & compressed javascript & other front end assets.

WaveMaker's One-click deploy feature allows developers deploy their application to AWS, Azure, Google Cloud or Kubernetes cluster.

During the build process there can be failures if any of the markup, styles or scripts has issues. if the deployment of an application fails, it required some effort from the user to discover & resolve the issue in the last release as

• The developer is informed about the errors post the deployment failure which usually takes couple of minutes since the deployment is triggered.
• The user needs to analyse build.log file to find the exact error & its causes. The log file include framework specific messages which might be relatively hard for low code developers to comprehend & fix.
• The build step of deployment fails for the first error it encounters. So the failure log did not include the complete list of errors in the application. This might cost the user multiple deployment operations to discover all issues & their fixes.

Inorder to ensure a better deployment experience, WaveMaker leveraged its Observability platform to analyse the most common deployment issues in the past releases which are listed below,

• Invalid Page references
• Invalid Partial references
• Deleted Partial references
• Delete Page elements such as styles, scripts
• Referring to Invalid fonts in the styles.

and developed pre-deployment validation for each. With these checks enabled prior to deployment, users can experience significantly reduced error discovery & fix timeline.

Quick discovery of Errors​

• The validations are run as pre-deployment step, the errors are found quickly in the order of seconds.

• New Deployment flow with the validation state.

• Error state where the user is presented with the link to check the errors which caused failure as shown below.

Complete list of Errors​

• The validation works with the existing Inspection framework to present the errors with details.
• The validation scans complete application code & lists all the possible issues in one interation.
• The results list the errors grouped by files which covers markups, script & styles.

Clear description of Errors​

• Each error includes details such as filename & exact line number which can cause deployment failure.
• It also includes the documentation link, to help the developer understand the issue better & help in looking for solutions.

Convenience​

• The validations are added as a part of Inspection framework, the user need not trigger Deployment to find out the issues in the project. The user can also trigger Inspection check in the studio to find out application issues & fix them before making a deployment request.

• The Inspection framework in WaveMaker is a custom static code analyzer developed with popular open source frameworks
  • ESLint
  • Stylelint
• The Inspection framework analyse the markup, script & styles for any structure or usage which can cause deployment failure & logs it with additional metadata such as filename, line-column number, documentation links etc.
• The Inspection framework will be equipped with more validations with each release to help users develop & debug application easily ensuring a great developer & deployment experience.

Introduction to OpenAPIs​

OpenAPI is a broadly adopted industry standard for describing modern APIs. The development of the specification is fostered by the OpenAPI initiative. It's important that you are clear with the difference between OpenApi and swagger.

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. A document (or set of documents) that defines or describes an API in called the OpenAPI definition document. An OpenAPI definition uses and conforms to the OpenAPI Specification. The specification can be found here.

Advantages of working with OpenAPIs​

Since an OpenAPI definition document follows a standard OpenAPI specification, the document can be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.

WaveMaker extends this advantage to integrate REST endpoints in a Web/Mobile application. WaveMaker generates UI for Create, List, Update and Delete operations (CRUD) for REST APIs that confirm to OpenAPI specification. Integrating a REST endpoint with any of the 100+ UI widgets offered by WaveMaker is also simple and straightforward without writing a single line of code.

Since an OpenAPI document contains a number of APIs, WaveMaker identifies and groups a set of APIs under respective “entities”. For example, in an OpenAPI document, there can be multiple REST endpoints for an Employee entity. There could be respective endpoints to perform CRUD operations on this entity. While importing the OpenAPI document in WaveMaker, the platform performs a best guess algorithm to identify and map the endpoints against the respective CRUD operation. Once this is done, the app developer can make use of the Data widget combinations like Table/List with a Form and perform CRUD operations from the UI by simple drag and drop configuration without writing a single line of code.

This opens a wide range of possibilities for the platform to integrate with 3rd party REST APIs. To name a few:

• supporting various server side pagination/fragmentation/sorting techniques
• identifying relationships among various “entities”
• performing complex filter operations on an entity
• supporting various authentication/authorization mechanisms

We at WaveMaker are working to identify all such patterns and integrating it with the platform to provide a seamless experience. Keep an eye on this space for more updates.

Importing OpenAPI document in WaveMaker​

If you already have an API document that is in accordance with OpenAPI spec 2.0, it can be imported into your WaveMaker app project and integrated with the UI widgets. Refer the following document on how to do so:
Importing REST APIs via OpenAPI/Swagger

Importing an existing WaveMaker app’s APIs into another app​

The good news is all the APIs generated by a WaveMaker app follow OpenAPI 2.0 specification. Hence, a WaveMaker app's APIs are readily available for integration into another app. All you need to do is, take the OpenAPI/swagger json file from the existing app and import it into the other app where you want to consume the APIs. You don’t need to import each API individually anymore, which is a major time save.

Also, as mentioned above, the platform will identify “entities” from the OpenAPI document and group endpoints under these. So you can now perform the CRUD operations on a DB entity just the way you could do it through a DB CRUD (live) variable without creating individual Service Variables against each endpoint and writing custom logic to hook these operations. Here is a pictorial representation of the use case:

Generating OpenAPI document for existing APIs​

If you chose a RAD platform like WaveMaker to build/modernize an app, chances are you already have a set of APIs to consume and plug the UI with. These endpoints can be on various back-end technologies, but the advantage with an OpenAPI document is that it is language agnostic.

Due to its open source nature, wide variety of frameworks support automatic generation of the OpenAPI document through code. Here is a list of language-specific tools you can use to generate OpenAPI document for your APIs.

Java​

Spring developers can use springfox, while JAX-RS developers can leverage swagger-core. The Swagger Maven Plugin even works with both.

ASP.NET​

The Microsoft world supports OpenAPI, too. ASP.NET developers can install the Swashbuckle package and easily generate a specification for their APIs.

Python​

Django developers can add the django-rest-swagger module via pip, whereas Flask-RESTPLUS has Swagger support built in.

Javascript/Node​

Applications built in Node frequently use Express or HAPI as their framework. Third-party modules called swagger-express and hapi-swagger are available for those.

Ruby​

The grape-swagger gem provides full OpenAPI support and works well with other gems, such as grape-entity. With the latter, it is possible to define models and use them in the specification as well as for input validation.

Go​

Goswagger is available for all the Go developers out there. It is a large package that is not limited to the use-case of self-documenting APIs but allows all kinds of work with Swagger and OpenAPI definitions in Go.

References​

• OpenAPI initiative official space: https://www.openapis.org
• Swagger official space: https://swagger.io
• How to generate OpenAPI definition from code: https://www.blazemeter.com/blog/how-to-generate-openapi-definitions-from-code
• Importing REST APIs via OpenAPI/Swagger

Apple deprecated UIWebView and introduced WKWebView. Starting from April 1st, 2020, Apple stopped accepting all new apps that have references to UIWebView. From December 2020, Apple will stop accepting app updates that have references to UIWebView. The current version Cordova that is used in WaveMaker, uses UIWebView by default.

WaveMaker allows creation of mobile applications by a simple drag and drop approach. Click here to know more.

Solution​

Cordova created a plugin called cordova-plugin-wkwebview-engine. This plugin brings WKWebView of iOS into cordova. Due to its restrictions imposed by WKWebview, two problems araised.

1. Cordova by default loads index.html using file:// scheme. WKWebView is blocking access from html page (loaded via file://) to files outside of application directory.
2. UIWebView allowed CORS requests even if CORS is not enabled in the server. But, WKWebView blocks cross-origin requests unless CORS allowed by server. In WaveMaker, CORS is optional.
3. It doesnot store cookies from third party domains (domains other than the domain that html file is loaded). WaveMaker uses Cookie based authentication.

cordova-plugin-local-webserver is a cordova plugin that serves the app files over http by hosting a server with in the app. This helps in resolving problem1.

cordova-plugin-advanced-http is a cordova plugin that provides API (instead of xhr) to make http calls to the remote server. Using this plugin API, a wrapper is created to replace XHR so that all existing XHR calls work as earlier. This plugin routes all requests through native layer that doesnot block cross-origin requests. This plugin also persist cookies from all domains and send them in appropriate requests. This plugin helps in resolving problem 2 and 3.

In addition to the above, Cordova framework and plugins may have references to UIWebView. Cordova team addressed these framework level changes in cordova-ios@5.1.0. They added a preference called 'WKWebViewOnly'. If this preference is set to 'true', then UIWebView references in the cordova framework are replaced with WKWebView. Out of all the plugins that are supported by WaveMaker, cordova-plugin-inappbrowser has UIWebView reference. cordova-plugin-inappbrowser removed those references in version 3.2.0. So, that plugin is upgraded to 3.2.0.

Developer Action Required​

With WaveMaker 10.4 release, platform has no references to UIWebView. Developer has to make sure that all third party plugins (if any) also have no references to UIWebView in their code. If references are present, contact respective plugin-developer for a newer version of the plugin.

Known Issues​

1. cordova-ios@5.1.0 is not supported by build.phonegap.com. When publishing new app, ipa has to be created manually. For all development builds (even for new) and distribution builds for app updates, phonegap service can still be used.
2. While uploading a file, there is no pogress event avaiable in cordova-plugin-advanced-http plugin. Currently, a synthetic progress event is created which just mimics but doesnot corelate with the actual progress of operation.

References​

1. Apache Cordova blog about using WKWebView. https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html
2. Issue with WKWebView. https://github.com/apache/cordova-plugin-wkwebview-engine/issues/56
3. Cookie Issue with WKWebView. https://bugs.webkit.org/show_bug.cgi?id=140205
4. Progress issue in cordova-plugin-advanced-http. https://github.com/silkimen/cordova-plugin-advanced-http/issues/88

What are Micro Frontends​

One of the practices which simplify the development and maintenance of such apps is to decompose the application into modules that can be independently developed, tested, and deployed. This is known as the MicroServices pattern.

Adapting these practices to frontend systems enables us to generate independent, composable application modules. Such modules are called Micro Frontends.

This practice helps teams develop modules in parallel, deliver customer-facing solutions quickly, learn directly from customer feedback and improve the module for better adoption. Organizing teams this way to have a direct customer visible deliverable is a key ingredient in setting smaller teams for success by letting their customers connect with the teacher. Adopting or validating new technology for a new feature or replacing an existing feature can be progressively achieved without affecting other app entities.

For enterprises that want to modernize their applications by adopting micro frontend, the architecture gives them a delivery model where they can start deploying modernized modules into their existing application.

As the modules are independent of each other, below are the key gains.

• Reduced development time and testing effort
• Parallel and Incremental addition of features
• Enables using different technology, frameworks for development and delivery
• Ease of integration of new modules into existing systems

Implementation approaches​

There are many approaches to implementing the Micro Frontend pattern to an existing or new application. Let's take an example of an 'e-cart' app to explain the approaches to implementing Micro Frontends to an existing monolith app.

A typical 'e-cart' app can be grouped into below listed main modules.

Catalogue: The available items are managed. User Profile: The user-related operations are handled, such as his info Orders: The order related info such as history, status are managed Payments: The payment-related info such as mode, status is managed

Each of the above can be built into a deployable module bundle. Below are some of the approaches that can be adopted to compose them and serve as an application using the Micro Frontends pattern.

Container Application​

With this model, there can be one container module that can

• House common UI elements such as Headers, Footers, etc.
• Handles common operations such as authentication and navigation.
• Loads and unloads each 'Micro Frontend' module based on the user action.

Server Side Composition​

With this model,

• The app is served through an HTML page rendered on the server-side.
• The page is composed of common elements and placeholders.
• The page uses server-specific plugins to render MicroFront modules in the placeholders of the HTML as per the need.

Build Time Composition​

With this model,

• Each Micro Frontend module is published as an independent package.
• The container app will include the packages as library dependency and produce a single deployable Bundle on building
• However, a change in any module will require rebuilding the container bundle (in turn, rebuilds all the dependent modules) to be served, making it not a good approach to adopt.

Run Time Composition​

With this model,

• Each Micro Frontend module is built as an independent script and exposes a global function as its entry point.
• Each Module can also be built as Web Components.
• The container application will have the logic to load required modules on demand and render them into the required DOM node.

With all the approaches and advantages described above, this pattern does come with some costs listed below,

• The approach might cause an increase in Payload size if the modules share dependencies as the modules are built separately with dependencies.
• Increase operational cost as each module might involve a different build and delivery approach.

Single-spa framework in WaveMaker​

Single-spa framework allows you to compose and serve multi-framework modules into an app by including a compatible JavaScript bundle. When built, a real-world web application will not just generate JS bundles but also produce CSS and other metadata artifacts. Currently, the Single-spa framework does not have any specific way of loading non-code, non-JS artifacts. For this reason, the users are requested to add the additional scripts in the steps mentioned above.

WaveMaker is planning to work on a loader script that will load all the artifacts required for a WaveMaker app to work with Single-spa without the need for any additional loading scripts and provide seamless integration support in the coming releases.

Screenshots of Sample S-spa​

Home​

Angular App​

WaveMaker App​

Since the release, we continued to make changes and improvements to the site very frequently, and now we have fully adapted to the new GitHub workflow.

In the recent additions to the site, we implemented the search, which was one of the most-waited and most-requested features. While WaveMaker documentation is well-indexed by Google; additionally, it has the ability to search within the site, which makes it easy to discover content inside and outside.

What we used​

Implementing an entirely new documentation site was a different story while integrating the search was another (read more). We went with algolia community project called 'DocSearch' which offers fast, accurate and robust search results.

Algolia DocSearch is a popular hosted search and many open-source communities use it, including React, Vue, Bootstrap, Netlify, Paypal, and more. It shows real-time results instantly as you type. We are happy with how it offered the flexibility to make our own customizations.

With DocSearch​

• Algolia crawls documentation every 24 hours and creates a search index in its server.
• It automatically tracks internal links to make sure that the content does not miss away.
• It uses the semantics of the HTML structure to construct records.

The journey of the Search Implementation​

We admit that the journey behind this implementation was quite interesting, in a good way of course. The integration with algolia DocSearch as a ready-to-use service was fairly smooth. Though, there were few challenges from Docusaurus for placing the search into the setup it offered.

Let's first see how it looked before and what we did to make the search look neat and responsive across all devices.

Search before​

It did the job. But was it enough? Docusaurus does not allow modifying the header. The default search was overlapping the navigation menu in smaller screens. This hampered the user experience of mobile users. See the "before" screens below.

• In the mobile view, two headers were occupying more space and menu items were accessible only by scrolling horizontal ways.

• Default colors applied automatically, but content got over-crowded.

What we did​

Docs are the key source to find solutions instantly with hundreds of documents to filter from. Algolia took care of the technicality, and we took care of the rest. We consulted our UX team and developer to customize the search to match our theme and display results to access docs with ease and responsiveness.

We developed a custom script that injects dynamic HTML into the website. This means, whenever the documentation page loads, it builds a dropdown menu with options while injecting it into the header in the hidden mode. It also adds event listeners to show and hide menu items. This dropdown works in the mobile view only. We hide the horizontal menu, whilst we expand the search area for better visibility as shown in the screen below.

ta-da!​

When you access WaveMaker Docs in the mobile view, simply click the "Docs" option. It opens the menu vertically without interrupting the user experience. The dropdown menu can be closed by clicking anywhere on the page.

What more?​

We improvised the web view, too!

Try it for yourself to see how fast and accurately it works.

If you are interested to learn more about how we implemented this, see the pull request details.

We are constantly working on improving the documentation to make it better every day. If you notice something broken, please report to us by logging an issue here.

Stay up-to-date about the product and know what's happening inside our WaveMaker towers. Our team will keep you posted.

Stay tuned!