Categories
Enterprise Application Development

Reaping Angular Advantage with WaveMaker

As web application development evolved, usage of JavaScript skyrocketed. To address the variance in support of JavaScript, HTML across the different browser versions libraries like jQuery evolved to offer a layer of abstraction for the web developers, so that they can just focus on writing their application logic instead of worrying about the vagaries of browser support. Single-page web applications started to become the norm as more code started to be written in JavaScript than ever before. JavaScript has also become the language of choice to deliver applications that run on desktop browsers and mobile phones. So web applications written in JavaScript are now in the run-in environments with huge variations in parameters such as device CPU & memory, network bandwidth, browser support.

Powering this scale of growth needed the emergence of more JavaScript frameworks that provide abstractions over this diversity of hosting environments packaging up the best practices in loading times, memory usage, and responsiveness. There is simply no way to deliver a high-quality user experience without basing application development on top of these quickly evolving JavaScript frameworks such as Angular. Leave it to the smart folks in the Angular team to worry about keeping up with the evolving web application requirements while the application developers’ energies are productively engaged with solving the business problem at hand.

WaveMaker generates Angular code

WaveMaker is the only Rapid application development platform with open-standards-based code generation using Angular & Spring. Our 110+ UI components are implemented as Angular components built into libraries. When the user starts building a page in WaveMaker, the product starts generating Angular code in the background. The generated code imports the UI components user dropped into the page and then wires them up using data binding.

 

The code generated by WaveMaker is fully customizable, allowing developers to write custom business logic in javascript. Using WaveMaker our customers have built a line of business apps, customer-facing portals, and mobile applications in several verticals such as insurance, banking, manufacturing, healthcare, retail, etc.

Build full-stack teams and boost their productivity

WaveMaker offers ready to use and well-tested component library and a visual development environment to drag-n-drop these components to design a page. WaveMaker abstracts away all the Angular concepts like routing, scoping, security (auth guards), i18n, and service integration with REST, SOAP & databases, etc. The developer focuses on building application capabilities like user interface & interaction, representing data with widgets like Forms, Table, Lists or Charts, etc., defining access control for both UI components and APIs.

Mobile-First application development

WaveMaker UI components built using Angular are device responsive and designed to suit mobile-first apps. WaveMaker platform enables hybrid mobile application development, using device-native capabilities through Cordova combined with the power of responsive Angular widgets.

Bring in existing UI components

While WaveMaker has 110+ UI components and this list is ever-growing, we realize that teams may want to build reusable UI components to further decrease the time it takes to build applications in WaveMaker. WaveMaker supports importing reusable JavaScript components that are packaged as Angular.io elements, web components, or jQuery widgets. Using a WaveMaker feature called “prefabs” existing UI components can be imported and these will stay accessible alongside the standard WaveMaker UI components and can be easily dragged and dropped onto the page that is getting developed.

Keep your application on the latest version of Angular

When users develop an app, WaveMaker generates application metadata that does not depend on a specific Angular version. From the metadata the Angular code is generated by the platform, keeping the app agnostic of any specific version of Angular. This means that the app will stay using the latest versions of Angular as WaveMaker rolls out the support for those versions. By simply upgrading WaveMaker versions the application will start reaping the benefits of staying on the latest version of Angular. There is no need to spend time in big stack upgrade projects that consume the productivity of your team.

Build applications that load faster

One of the benefits of Angular is that the framework comes with tools that support very advanced build strategies that reduce your application’s footprint. This is very important to the application’s load time as the amount of JavaScript that is getting downloaded from the cloud uses up critical resources such as network bandwidth, device CPU. Smaller the application footprint, the faster the app loads. When you attempt to deploy the WaveMaker app, we internally use ng build –prod mode with tree shaking enabled so that each page includes only the WaveMaker UI components that it uses and not all of the library. Essentially, the WaveMaker platform takes care of all the build optimizations and keeps the application footprint as optimal as possible to give better performance and first-time load experience.

Easy to deploy onto a CDN

WaveMaker builds which are triggered when the Deploy button is clicked can produce different bundles for frontend, backend code enabling the frontend code to be deployed on a CDN. Each of the resources the page depends on includes a fingerprint that represents the contents of the resource. This means that CDN that is serving static assets can be configured to set cache headers allowing browsers to cache the content and further optimizing the load times for returning users. Because of the content-based fingerprinting incremental releases of the WaveMaker application will only link to newer static assets if there was a change. In most cases, WaveMaker UI components for a page are already in the browser’s cache.

Categories
Enterprise Application Development

Micro services Architecture in Greenfield Projects – WaveMaker

Launching a new business or project means that everything has to be built from the ground up, from defining services, functions, and product range, to deciding the technology, infrastructure, and resources required. Enterprises, to serve the evolving demands of customers and add business value, are looking to develop new applications faster with minimal resources and cost.

In greenfield development projects, the new applications built either solve unaddressed business challenges or entirely replace an existing inadequate system. Consider this example of a new start-up company that is going to launch an online, product range. The primary focus of the company is to build a minimal viable product (MVP) with the ability to make product improvements from customer responses. Without existing systems or architecture in place, the company plans to build a suite of applications to serve various business needs, add new functions, provide an uninterrupted online presence, and ensure scalability based on changing customer demands.

The company, with the absence of an existing legacy system, is weighing out the option of adopting microservices. If they choose microservices architecture, this would involve defining service boundaries (which need to be dynamic) and deciding the technology stack for each microservice. It would also include rethinking operations, creating a scaling strategy, provisioning infrastructure required for elastic scalability, and configuring and maintaining monitoring solutions.

While it is a relief not to inherit technical debt from legacy systems, there are many aspects to be considered when adopting microservices architecture for a greenfield development project.

Define your domain or service boundaries

When developing greenfield applications, defining service boundaries could be tricky. Before trying to categorize your system into different services, ensure you know your domain. For instance, you define that service A is responsible for doing a particular function. What if this changes or if you realize the function needs access to service B.

Before separating functions into microservices, you need to understand and have clarity about the dependencies they have. Only after some time would patterns emerge from which you can identify the functions and services and the problems they can solve. However, there would be apparent functions such as login or profile services that could be carved out into a microservice straight away.

Decide on the technology stack

The technology stack used with microservices in greenfield projects is diverse. You can combine multiple programming languages, frameworks, and data storage technologies. However, standardization becomes an issue with different teams using an entirely different technology stack. Low-code platforms offer one point of control for application updates and maintenance to overcome technology diversity. With a centralized repository for version control, multiple developers can collaborate and merge changes.

Achieve a minimum level of operational readiness

To start a greenfield project using microservices architecture requires a minimum level of operational readiness maturity. Operational readiness in terms of ensuring there is access to a deployment environment and building continuous delivery pipelines where services are created, tested, and deployed. Whether it is identifying and provisioning infrastructure requirements, scaling strategy, and service discovery, you need to have a plan to address the operational complexities that could occur when adopting a microservices architecture.

Low-code platforms simplify application development, deployment, and delivery. They use Continuous Integration (CI) tools like Jenkins to provide a continuous delivery pipeline and provide an automated containerization workflow. Low-code platforms transform the way enterprise applications are developed and delivered.

Reorganize development, DevOps and IT teams

To ensure every microservice is managed independently, you would need to reorganize your teams and maintain a balance of resources. It is not productive to have engineers working on multiple microservices; neither is it feasible to have one person for each unique role. For instance, a DevOps engineer can manage dual roles of development and operations, or a full-stack developer can manage the entire application development lifecycle. Ideally, every team should have a balance of expertise which could comprise of developers, testers, operations engineers, database administrators, UX designers, and in some instances, even product managers.

With the rapid increase in opportunities applications have to serve customer needs, development teams are under pressure to deliver at a fast pace with tight turnaround times. Added to that, the shortage of skilled professionals is hindering rapid application development. Here is where low-code platforms help by providing a user-friendly interface and a development environment where teams can collaborate on modules with efficiency.

Ensure microservices implementations do not turn into distributed monoliths

There are whispers about how most greenfield microservices implementations turn into “distributed monoliths.” By taking a monolithic codebase and spreading it across a network, the benefits of microservices architecture fade. For instance, when making changes to business logic in a shared library, if you need to synchronize the deployments of multiple teams, it reflects the inability to deploy changes in isolation. When building a new system, it is a huge advantage to have a single, non-distributed codebase.

In greenfield, microservices-based implementations, low-code application development platforms provide business agility by automating systems and ensure data security, integrity, and compliance with IT governance and standards. However, before going all in to adopt a microservices architecture, it would be useful to be clear about the fundamental aspects mentioned earlier about service boundaries, infrastructure, technology stack, resources, and team organization.

Categories
Enterprise Application Development

Faster Page Load Times Using Brotli Compression

By Subodh Kumar, Principal Engineer, WaveMaker

At WaveMaker, we want our users to have the best user & developer experience aided by a great performance. Also, we want the apps built by our customers in WaveMaker to load really quickly. In every release, we work on making the load experience better.

WaveMaker is a Rapid Application Development (RAD) platform that lets customers create responsive web applications or mobile applications using a simple drag and drop approach. WaveMaker simplifies building modern responsive apps using Angular. WaveMaker provides 100+ out-of-the-box responsive UI components. Using these components functionality can be built by binding them to data sources such as REST, SOAP APIs or Databases.

As customers build the application in WaveMaker, Angular code is automatically generated. This allows us to use build tools like web packs and other tools in the Angular ecosystem. Using these tools WaveMaker application build process already derives benefits such as minification, tree shaking, lazy loading, and compression of static assets

In the 10.2 release, WaveMaker is introducing support for a better compression algorithm ‘Brotli’ as a part of its optimization that will help the apps load even faster. Customers will realize these benefits without any code changes by simply rebuilding their apps.

Why static assets should be compressed?
The performance of every app is proportional to the size of the resources it serves over the network to the user. The resources can be in the form of HTML, JavaScript, images, styles, and others. The bandwidth & time a resource can consume is a function of its size.

Thus, having resources of a smaller size can help in an app’s response time & performance. Compressing the application assets can help us achieve that. With the right compression algorithm deployed, the resources served will be optimal.

Brotli will help the pages of an app load faster & be more responsive. It also provides a better user experience, which every app or business is striving for.

What is Brotli? How is it better than gzip?
Brotli like broccoli is better for your health. 🙂

Humor aside, Brotli (defined in RFC 7932) is a generic-purpose lossless compression algorithm that compresses data using a combination of a modern variant of the LZ77 algorithm, Huffman coding, and 2nd order context modeling, with a compression ratio comparable to the best currently available general-purpose compression methods. It is similar in speed to deflate but offers more dense compression.

Brotli, when compared to Gzip, provides better compression & decompression performance. Following is the summary for comparison of common assets of an app

  • 14% smaller JS
  • 21% smaller HTML
  • 17% smaller CSS

It’s not just about compression ratio, but also about how long Brotli takes to compress & decompress data. Data suggests that Brotli is better at compressing static data because of its superior compression ratio.

Browser support
Brotli compressed files are served only over HTTPS & encoding is supported in most of the modern web browsers as shared below,

How to check if your static assets are Brotli compressed
The browsers which support Brotli will send ‘br’ with ‘gzip’ in ’accept-encoding’ of request header.

 

And, If Brotli is enabled on the server, the response will be in Brotli compressed format

Performance gains in load times
In WaveMaker, as soon as the user makes a deployment request for the Angular profile, the Brotli compressed files are generated. Since the generation of compression is part of the build process, when a request for resources is made by the app, the files are readily available and shared. This results in no additional runtime cost at the server.

Below is the comparison of resources for a sample app developed in WaveMaker, which will show the difference in the resource size.

Asset Type Without Compression Gzip Brotli
JS 2.7MB 698KB 573KB (~17% over gzip)
CSS 548KB 82.9KB 67.5KB (~18% over gzip)


What do WaveMaker customers need to do to benefit from this?
For existing projects, just modify deployment.properties (This will be not be needed after the migration is in) to enable the compression in the ‘deployment. properties’ as shown below & have the app served over HTTPS.

 

References:
Google blog -Introducing new brotli compression 2015/09
Github – Brotli
Mozilla – GZip Compression with brotli