iMIS platform enables developers to create and integrate client-based iParts (application components) with the iMIS website’s existing pages.
This article focuses on setting up front-end, client-based iParts developed with modern frameworks such as Vue, React, and Angular, testing on a local server instead of directly online via a browser.
Why Client-Based Applications?
Client-based iParts on iMIS offer significant benefits, allowing organizations to tailor their engagement management systems to specific needs. These applications leverage advanced development tools to implement complex functionalities that extend beyond the capabilities of the built-in tools of the iMIS platform. Moreover, they allow developers to test more conveniently on localhost, rather than directly online, enhancing flexibility, integration, and potential performance. This adaptability ensures that the customized iParts can evolve with the organization, maintaining a unified and effective management platform.
Here’s a reference to the commonly used iMIS Restful APIs: iMIS REST API.
In addition, you can use Postman (Download Postman | Get Started for Free), a popular collaboration platform for API development, to perform the design or testing before making the API call in the application.
Handling Token Authentication
The development process for a customized iMIS iPart is similar to that of developing applications locally, both relying on third-party tools such as Vue, React, or Angular. To integrate with the iMIS front-end, developers might need to fetch data from the iMIS backend, such as IQA results, via REST API calls that require token authentication. Conventionally, tokens are retrieved directly from the browser’s local storage post-login. However, when deploying and testing on a local server, this method isn’t feasible due to the separation between the web token in the browser and the local server.
A temporary solution I used was manually copying the token from the browser console and embed it within the application, although this requires frequent updates due to token expiration. The following screenshot is an example of including bearer token in the Postman.
Likewise, if the API call is performed by JavaScript, you will also need to attach the token to the HTTP request header as shown in the screenshot below:
A more durable solution during the local testing phase is to embed credentials in the application code, make an API call to retrieve the latest token when the application starts, and attach this token to subsequent API requests. Please remember to remove the credentials before uploading the code to the iMIS platform because clients can read the exposed credentials by sniffing the network traffic. Using a public account without sensitive information or applying further security encryption can mitigate this issue.
Overcoming the CORS Issue
During testing on localhost, the client-side application and the iMIS platform backend, which handles REST API requests, are on different origins. Browsers enforce Cross-Origin Resource Sharing (CORS) policies (Cross-origin resource sharing – Wikipedia) to restrict requests to different domains than the one serving the initial web page. Without the ability to modify the iMIS backend to enable CORS, requests from the application would be blocked. To bypass this, developers can use a proxy server deployed on the same origin as the client-based application (usually both on the localhost) (example code: javascript – How to create a simple http proxy in node.js? – Stack Overflow).
During testing on localhost, the client-side application runs in a browser, and because it is hosted on the same origin as the proxy server, the browser does not enforce CORS restrictions on communications between them. The proxy server then handles the transmission of these requests to the iMIS backend. Since this part of the communication is server-to-server — not passing through the browser — it does not trigger CORS restrictions. Once testing is complete, and the application is deployed on the same origin as the iMIS backend, CORS issues no longer apply.
Deploying the Client-Based Application on iMIS
iMIS provides a comprehensive guide for developing a client-based iPart: Developing a client-based iPart (imis.com), which, however, doesn’t emphasize a critical point on modifying the original client application’s HTML for deployment. During local development, developers often place source files in the same directory as the HTML, allowing it to reference these files directly.
However, when deploying to the iMIS platform, it’s essential to adjust these references to align with the new directory structure. Before uploading the application, developers need to update the HTML to correctly point to the relative paths of the source files within the iMIS platform’s file system to avoid linkage errors and guarantee seamless functionality. Alternatively, for simpler applications, developers can merge all JavaScript and CSS into one HTML file and embed this into a Content HTML iPart, sidestepping the path reference issue.
Client-based iParts developed with modern frameworks can significantly enhance the complexity and advanced functionalities of a website. As a developer still exploring this field, I am committed to seeking out more efficient and effective approaches for developing on the iMIS platform and am eager to share my latest insights with everyone.
