Categories
Blog

WaveMaker v10.8.0 is out!

Team access to artifact repository, improved workflows for artifact publishing, prefabs versioning, and more

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.

Teams - Together and Transparent

Artifacts in Teams

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.

A new and improved flow

Artifact approval

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.

One component, different forms

Support for specific prefab versions

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.

Categories
Blog

Leveraging low-code for API-driven development

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

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.

API Management with WaveMaker low-code platform

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.

  • API- first approach: With WaveMaker, a REST API is generated automatically for every service that is imported. These APIs are available for consumption as well as modification through the API designer that can be used for:
  1. Exploring the various APIs generated by the platform
  2. Testing the APIs 
  3. Customizing APIs generated by Java services
  • API GeneratorWaveMaker generates standards-based REST annotations for the above services which can be consumed by API tools for generating documentation using the API generator. The design of these auto-generated REST APIs can be updated further by configuring their description, visibility, method types, and parameter types.
  • Open APIs: The platform generates core REST APIs endpoints using Swagger/Open API compliant contracts for database services, Java services, web services, custom code business logic, or even third-party imports. It also to generates UI functionality for Create, Read, Update, Delete (CRUD) operations for REST APIs which conform to Open API specifications. Integrating an existing REST endpoint with any of the 100+ UI widgets offered by WaveMaker is also straightforward without writing a single line of code. Open API helps WaveMaker apps consume other WaveMaker APIs enabling applications within an enterprise to talk to each other.
  • API Security & TestingSecurity is auto-enabled for an application that can be viewed in the API designer. API security is ensured by securing it with role-based access within the enterprise. API endpoints are also OAuth protected. Once the REST APIs are defined successfully, they can be tested with the “Test” tab. On successful testing, APIs are published along with the applications.
  • Legacy APIs: APIs are invariably REST-based but there remain big remnants of legacy SOAP-based APIs. WaveMaker automatically creates a REST API endpoint for the SOAP services that are imported into an application thus enabling the reuse and modernization of legacy technologies.

WaveMaker offers an API-driven development platform with:

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.

Categories
Insights

Internal vs External APIs: Does it matter?

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

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,

  • Providing easy means to manage the lifecycle of APIs (Create, Publish, Version, and Retire).
  • Secure Access for protecting sensitive data that is being exposed.
  • Differentiated Access while allowing the consumption of APIs among stakeholders.
  • Easier onboarding of applications and developers that consume the APIs.
  • Monitoring real-time access and usage trends of APIs and take actions as required by the business.

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,

External vs Internal APIs

 

Internal APIs

External 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.

Categories
Enterprise Application Development

How to Create API-Centric Web Apps

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,

  1. Easy consumption on multiple devices. RESTful APIs provide a lightweight integration model that significantly helps in creating mobile applications.
  2. Business logic is well contained with individual APIs.
  3. Ease of application development as the focus of application in on the front end-user interaction.
  4. Forces Reuse, as APIs developed can be used by multiple applications on multiple form factors.
  5. With the proliferation of APIs (Open, Cloud, SaaS), etc., developing applications becomes faster and easier.

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,

  • Using Basic HTTP Authentication, passing in Username and Password. Enable the HTTP Authentication check box as shown in Figure 2, to import the API.
  • Passing Security Tokens via HTTP Header properties. For example in order to authenticate via OAuth Security, Authorization: Bearer token is sent in the header to get back an OAuth access token. See Figure 3 that shows how the Authorization Token is passed to the API. Similarly other tokens, cookies can be used as required by the REST API.

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 [1] 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.

Excited about developing API-Centric applications using Studio?  If so, log in to WaveMaker Online and create one. If you have any suggestions and feedback contact us.

Mayur Shah (mayur.shah@wavemaker.com)

WaveMaker Passionate Technologist