Implementing API services using a scoped Application   

Introduction: A well-known platform makes it easy to write workflows involving Service desk operations.  A scoped application is a custom plugin on that platform that implements a specific functionality that is usually not found on the platform. Most applications are like self-contained micro-services with their own set of tables, scripts, and user interface. This article tries to elaborate on what it takes to implement APIs as part of those offerings from a scoped application.  

Description: The platform mandates that the logic and data are packaged in artifacts that conform to pre-existing entities. There are entities for scripts, UI pages, and even custom tables but there is no description for implementing API services. APIs are powerful because they enable clients to be across the wire while self-containing all logic. Micro-services and their popularity are a demonstration of the power of APIs especially when the callers are mobile applications and personal desktops.    

API logic is authored in jar files. But there is no platform entity to register jar files other than the MID server Jar files which store specific rules. The scoped application can import APIs from the platform by bringing in dependencies many of which are jar files. The pom.xml file for building the scoped application can list these dependencies but the target of the build is usually a zip file of artifacts that the platform knows how to import. This calls for the API to be written in a scripting language.   

Both JavaScript and PHP allow API servers to be written such that they can be shipped as text files which is an artifact that can be registered to the platform alongside the others in a scoped application. They require to be started and monitored but usually the traffic to a scoped application does not need to concern itself overly with scalability and performance as much as it must be secure.  

The ways to secure APIs are usually independent of the implementation language because most usually follow the REST convention. The use of authorization headers, encrypted requests, API keys, and tokens make these endpoints securable. The logic of the API itself is usually conforming to the HTTP verbs to create, update, delete and list semantics. There might be some operational APIs such as to get statistics or for usage information or to populate metrics or to indicate that the API server is alive, but these are usually few. The bulk of the APIs is organized around the actions associated with those resources. These resources are also as custom as the scoped application. Platform resources are usually having their own APIs, so it is advisable to not write anything that pertains to the platform.  

A scoped application that collects feedback in terms of source UI page and corresponding user rating can, for example, allow a programmability aspect to the feedback collection table with the logic that makes it easy to query that table or for correlation with platform tables and UI pages.  The ability to enhance the logic in a scoped application and providing a programmability aspect that improves automation, scripting, and invocations via external scripts, applications, and services will tend to make the application more popular.  

Conclusion: It is possible and easy to implement API services in a scoped application where the application is dropped just like a tar ball and written using JavaScript.  

Reference: for sample scoped application discussion: https://1drv.ms/w/s!Ashlm-Nw-wnWyBYIKC6_TDLdliTd?e=NEldrF 

 

Lessons learned when writing the first Vue.js application.

The application I wrote and shared at https://1drv.ms/u/s!Ashlm-Nw-wnWyB2rx30dmeEoNxt_?e=ZHiGjt for the purposes of a Feedback user interface as discussed here was a series of trial and error because I was experimenting with different vue packages. As such the Vue framework works very well out of the box in terms of organizing and maintaining the code and data for a user interface but there was a learning curve associated due to the following reasons: 

1. The rendering library to package the single composable file (SCF) for a view in terms of a template, style and script are better chosen to be WebPack rather than relying exclusively on Vue-CLI-service although both allow compiling and running the Vue code. By the way, I love the similar sounding ‘Vue’ name since it rhymes with ‘View’ 

2. The Vue-CLI-service requires a separate set of commands to be put on the package.json scripts section as opposed to the webpack which is rather nifty with simple “npm run dev”. That is just the surface, the chores required to get to that stage can cost you if you did not plan ahead with one of the two choices rather than both. 

3. The webpack also performs well when the application is clearly written in the form of the file organization required by the webpack because the module compilation and invocation on the console as well as on the browser developer tools is helpful to walk through. Any deviation for whatever reason might require a wild goose chase. 

4. Packages that help with logging when running ‘npm run dev’ with vue.js applications. Please note that we skip the discussion on ‘-ddd loglevel’ with that command. 

5. Npm require loglevel 

• Single lightweight  

• Invocable in page with the script tag 

• Small footprint 

• Npm install Winston 

• One of the most popular configurable logging block 

• By default or for redundant logging 

• Npm install Jaeger 

• Specifically helpful to vue applications for trace.

• Prefer advanced functionality 

•  

6. There are quite a few dependencies that are tempting to add to the application with “vue add” or “npm install” but less is more in this case and while you are at it, prefer the npm install over the other. 

7. The HTML, style and script have their place and yes the composability is appealing but please stick to getting the HTML right because typos are extremely hard to find overall unless you are willing to view the page source and search for the section that will let you know where you made it. 

8. Please prefer the host as ‘0.0.0.0’ and port in the upper 8000 if you are using your environment for hosting other applications and allow disableHostCheck in build/webpack.dev.conf.js 

Sample Application: https://1drv.ms/u/s!Ashlm-Nw-wnWyB2rx30dmeEoNxt_?e=QPBgRa