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.
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.
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.
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.
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.
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, or 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 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 ensuring 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.
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?
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
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.
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.
|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.