WaveMaker 10.8 brings capabilities and features that harness the power of artifacts and prefabs on the WaveMaker low-code platform--especially for teams. Prefabs are custom widgets that can be reused across projects within a team. With this release, the platform consolidates its strength on prebuilt software components by making collaboration across teams faster and easier to manage.
WaveMaker continues to enable enterprise IT teams, ISVs, and all stakeholders to co-create value faster and better with low-code.
Artifacts are reusable components that can be developed and maintained independently. Various components such as prefabs, project shells, template bundles, and themes come under the umbrella of artifacts on the WaveMaker low-code platform. V10.8 allows the sharing of a central repository of artifacts in teams promoting collaboration between team members.
Team members can view a list of all available artifacts providing clear visibility. Developers have complete access to the repository of available components and are free to choose the artifact version that suits their requirements best. This in turn makes activities such as documentation, maintaining change logs, and version control of artifacts a seamless process.
With 10.8, developers creating and using artifacts across teams and projects can manage their workflows seamlessly. Consider a scenario where a developer publishes an artifact and waits for approval from the team admin. The admin can then review the artifact on the team portal and approve the same, making it accessible for all developers to use or reject it and send it back with changes.
Not just that, the same prefab or artifact can be versioned multiple times with each version visible to all team members. Developers can search and view available prefabs under projects, teams, or system prefabs and import specific versions into the projects.
Different projects can use different versions of the same prefab with a scope for upgrading. Developers can choose versions that suit their requirements with the help of changelogs and get real-time notifications of newer versions. Minor patch updates on prefabs can be published independently using branch support. Development teams can update patches and upgrades seamlessly without disrupting the existing environment and projects.
For ISVs, having access to the latest versions of artifacts is of great value. This allows for both forward and backward compatibility with respect to prefabs with minimum disruption. With every new update, WaveMaker continues to bring developers together, fostering collaboration, and helping them build powerful applications.
To know more about WaveMaker 10.8.0, please read the release notes here.
Create, publish and consume APIs effortlessly with WaveMaker low-code platform
Digital transformation is no longer a buzzword. It has become a way of life for enterprises that want to stay in business. In the current post-pandemic era, business maturity is being evaluated in terms of digital maturity. The road to digital adoption has many emerging technologies in force but working silently behind the scenes and aiding this rapid acceleration, is the unseen ‘super glue’ of all business services - Application Programming Interfaces (API). Technically, APIs have been around for two decades at different levels of operability but it is only in recent years that there has been an explosion of sorts in the usage of APIs.
The demand for multichannel experiences and the everything-on-cloud approach has accelerated the use of APIs. Whether it be composable architecture or microservices, APIs enable the kind of business collaborations that were unheard of before. The partnering of transportation services with a bank, retail shops with payment apps, and banks offering investment opportunities, loans, currency transactions, and payment services on an e-commerce platform have all been made possible by the growth of APIs. Similarly, offloading certain business tasks to ecosystem partners and liberating internal services from silos has been fueled by the synergy between APIs.
API-driven development is the practice of designing and building the API contract first and then developing the application around the contract. Also, known as the API-first approach, this paradigm involves the front-end developers building mocks around APIs and creating refined end-user experiences. In parallel, the back-end developers implement the underlying logic of the APIs.
Dedicated test suites are created around these APIs and, in a way, they foster the idea of test-driven development. In an API lifecycle, the API Publisher designs and deploys the API whereas the API Consumer discovers and integrates the APIs. Each of these roles has multiple functions associated with them and those functions define the characteristics of the API.
WaveMaker is an open standards-based, developer-centric low-code platform built for modern development practices. The platform enables app developers to play the role of an API Publisher and API consumer. The platform has a natively integrated component called the API Designer which is used to ease the process of designing, creating, and consuming APIs.
WaveMaker offers an API-driven development platform with:
A developer-friendly low-code platform abstracts the complexities of API management and provides UI-based connectors to work on the endpoints without having to hand-code. WaveMaker scores high on effortless API creation and management with an API-driven approach and an in-built API designer. The platform’s inbuilt adherence to the rules of the API game and its innate ability to convert any service as an API makes the job of all stakeholders so much easier.
APIs have become an inherent part of software building. Programmableweb (API directory) had a listing of mere 54 APIs in 2005. Today there are close to 24000 APIs listed there, and this is excluding the internal enterprise-level APIs and the ones that haven’t been made discoverable yet. Fuelling this expansion are tools and platforms that help us design, manage, test, produce, and consume APIs. Rapidly, easily and securely.
For years, APIs and Services have been around in Enterprise Computing. In the good old middleware days, Service Oriented Architecture came into existence, and services were exposed using SOAP Web Service APIs. These APIs were mainly used to integrate applications to legacy systems and to one another.
With the advent of cloud, mobile, and the need for massive internal/external adoption of services, REST-based APIs have replaced SOAP Web services. REST APIs are HTTP-based, lighter, easier to understand, and integrate, and therefore, have become the de facto standard for creating enterprise APIs. Enterprise APIs can be internal APIs i.e. within or across LoB (Line of Business), or external APIs for partners and third-party developers.
In the past few years, enterprises, having learned from web-scale consumer APIs, realized that in order to create an ecosystem of applications around your API, it takes more than just creating an API and expecting consumers to use them. This is true for both internal and external APIs.
API management is the ability to document, publish, share, control, consume and monitor the consumption of APIs. All of this is done in a fashion that allows easy publishing and onboarding of developers using the APIs. So the question is:
If an enterprise is looking to publish internal and/or external APIs, is there a difference in managing them?
The majority of enterprises consume more internal APIs than external ones. API management is essential for both internal as well as external APIs as long as there is a need for,
So how do you begin with API management? What we see is, depending on the maturity of the enterprise, the journey of API adoption can vary. Some enterprises with no APIs will start with internal APIs, get the ball rolling, work closely with internal stakeholders to fine-tune the APIs, and then roll it out for external consumption. On the other hand, mature enterprises may start directly with external adoption. Some may just roll out internal APIs depending on the business need. Let’s take a look at differences in the requirements when it comes to publishing and consuming APIs,
|Creation of APIs||APIs are created based on custom business logic and could be auto-generated during the application development process.||APIs are tuned and designed as per the needs of the external partners and third-party developers.|
|API Publishing, Sharing, and Discovery||Done on an Enterprise Developer Infrastructure/Network that is accessible to all other applications within the Enterprise.||Done on an External API Portal that is accessible to External Partners and third-party developers.|
|Purpose of API Consumption||Increase internal app development productivity, integrate applications within and across LoB resulting in streaming business operations.||Increase partner business opportunities, create new business models, and in some cases, direct consumer integration.|
|API Discovery||Need to be discovered on the same developer platform used by other internal applications willing to consume the APIs.||Need a public-facing portal to discover the APIs, explore them, and sample them.|
|API Subscription||May not need a stringent subscription plan to consume the APIs.||Need diverse subscription PLANs for API consumers to subscribe to and then consume based on SLAs, Payment Plans, etc.|
|API Policing||Need to make sure access of APIs are metered, rate-limited, and accessible based on Enterprise LoB needs and access rights.||Need fine-grained API control around security, access, rate limits, SLAs, and access limits based on Partner usage models and subscription PLANs.|
|API Access||May or may not need special tokens or keys to access the APIs. Mainly depends on the sensitive nature of data being exposed.||Need API Keys and security tokens to access the APIs.|
|API Invocations||API Invocations are in very large numbers as they are consumed by the Internal Applications.||Dependent on business requirements for access to external stakeholders. May be a much smaller number for Enterprise LoB Use Cases.|
Platforms that provide a unified approach to rolling out internal and/or external APIs can better facilitate enterprises willing to develop an ecosystem around their APIs. At WaveMaker, we aim to make the journey from internal to external API Publishing a seamless one. As mentioned in my earlier post, WaveMaker Studio, via API Designer feature, allows for publishing, sharing, and consuming APIs internal to the enterprise. As these APIs become foolproof, and enterprises like to develop an ecosystem around it, they can use WaveMaker Gateway that allows for publishing, sharing, management, and consumption of APIs by external partners and third-party developers. WaveMaker Gateway provides full-fledged API management capabilities and is specifically designed, positioned, and priced for enterprises wanting to embrace and develop API Ecosystems around Partners and third-party developers. Click here for a demo of WaveMaker Gateway.
As we are all aware, in today's hyper-connected world of applications, it is not uncommon for any product, service, or application to have APIs. APIs (Application Programming Interface) has become the de-facto foundational technology for enterprise app development and more specifically for Web applications.
An API-Centric or API-Driven Web Application is a web application that basically executes most, if not, all of its functionality through API calls. In an API-Centric web application, the front-end communicates with the backend using just APIs.
There are a number of advantages of developing an API-centric web application, namely,
In this post, we will see how developers can easily create API-Centric Web applications using WaveMaker Studio. Using Import functionality, a developer can use a wizard to import REST, SOAP APIs into the application development. Figure 1, shows how a REST API is imported in Studio,
REST APIs can be secured or non-secured. WaveMaker REST API Import Wizard allows for quick consumption of Secured as well as Non-Secured REST APIs. Secured APIs can be imported in 2 ways,
API-Centric Applications also make it easier for external applications (Mobile as well as Web) to integrate into it easily. It does it by exposing REST APIs to the external world.
WaveMaker Studio soon  will have support for creating a Swagger 2.0 compliant API Specification file for the auto-generated REST APIs as part of the Application developed. See the previous post on API Designer that talks about Studio-Auto generating REST APIs. In the upcoming version, the API Designer will generate Swagger conformant REST API documentation. More about it in a later blog post. Figure 4 shows below the Swagger 2.0 document for the HR DB (Sample DB) REST APIs auto-generated by Studio.
This Swagger document can also be taken and used to publish the APIs for the external world using WaveMaker Gateway product.
Mayur Shah (firstname.lastname@example.org)
WaveMaker Passionate Technologist