Swagger – The emerging API Framework
Swagger – The emerging API Framework Avakash Dekavadiya APIs are important component of almost every project. Most of the apps use APIs to make them lightweight by moving heavy logic at server side to ensure smooth and cutting-edge user experience. Even today, people use their own implementation for API specification, which makes all the API specifications different all across the world. It also leads to lot of ambiguities. Swagger is the solution for this problem. Swagger is standard and eminently useful framework to Describe, Design, Build, Document, Visualize and Consume RESTful APIs. By the introduction of initial major version of Swagger in 2012, it has resolved the problem of specifying the REST APIs and is easy to understand and use. Swagger is ambiguity free. The swagger specification is based on the OpenAPI Specification (OAS) and is developed in an open, transparent and collaborative community to standardize the way RESTful interfaces are defined. The primary initiative is focused on creating, evolving and promoting a vendor neutral description format. Features Swagger can be used by everyone for every kind of user roles: Project lead/manager Can easily design and specify the APIs Developer(backend and mobile both) Mobile team can easily mock all the APIs and can continue the development while API are under development mode in server Client (technical and semi-technical) With good technical knowledge With partial technical knowledge QA Can get all the APIs with specifications at one place and test directly within the browser Specification is a unique attribute of Swagger. It clearly defines each and every parameter and all the aspect to cover every possibility of specifying the API. It allows to specify all kind of specs at one place in one document. It also provides easy Editor which helps to write the specs and provides a user friendly GUI for each API. It provides code generation functionality to generate client and server side code to kickoff the project with all the API specification in code. It supports almost all languages which are widely used all over the world. Also, it gives browser UI to visualize the APIs which can be useful for less technical users. Additionally, you can test each API directly from the browser by providing necessary parameters and observe the response. Figure 1 & 2 demonstrate how easily APIs can be viewed with simple & clean UI in any browser without addition of any extra tool/software. Figure 1 API VisualizationFigure 2 API Visualization Advantages The specification is human and machine readable. Thus, it removes the middle layer that was used earlier for conversion between them. Swagger specifications are unique and firm. All teams like documentation team who defines the initial APIs, server team who writes the backend code for RESTful APIs and app developers can be in sync. This makes the team fast and efficient. Figure 3 API Specification It is a language agnostic. Irrespective of programming language used for implementation of REST API, the behaviour will be same as described in specs. Any user can easily understand and consume services without any prior knowledge of server implementation or access to the server code. Gives clear insight into how the API responds to various parameters and situation. Another advantage is the ability to generate the specs from the existing system/project. One of the major advantage is that it is open source, so everybody has the access of code and can also modify it if required. Comprehensive and intelligible for developers and non-developers. Future The current major version is Swagger 2. For the next major version Swagger 3, the implementor draft is released. So no major changes is expected after the 3rd version, only minor fixes and syntax change may be there. It is expected to be released in next 6-9 months. Swagger is improving continuously with the constant efforts by the open community worldwide and has a strong chance to become a de facto API specification tool as git is there for version control. P.S: Swagger is donated to OpenAPI, so newer version will now be called as OpenAPI specification 3.0 making the version 3 Swagger 3 and OpenAPI 3 will be the same. skip render: ucaddon_next_prev_post
Managing the Data Volume with MongoDB
Managing the Data Volume with MongoDB Avakash Dekavadiya MongoDB MongoDB is a cross-platform and schema less database. It provides high performance, high availability, and easy scalability. It works on concept of collectioan and document.Collection is equivalent of a RDBMS table while a document is a set of key-value pairs, just like tuple/row in RDBMS.It stores data in BSON which is binary JSON. Sharding Sharding is the mechanism of storing data across various machines to meet the needs of growing data. A single machine may not be enough to store data when data grows exponentially. Sharding solves this growing data problem with horizontal scaling. It connects multiple machines to support the data volume and address the challenge of multiple read and write operations simultaneously. Types of Server Shard Server :- A shard is a MongoDB physical instance which stores data records. Shard server can be either a single MongoDB instance or a replica set. Config Server :- Config servers are important MongoDB instances which store the metadata for a sharded cluster. It maps App server to Shard server. So, it is recommended to use three config servers for production deployments. App Server :- It connects Users with Shard server using metadata of Config server which decide which Shard server to connect. App server also executes read/write operation on sharded clusters.If you want to divide client request, then use multiple App server which is more reliable for robust applications. Multiple users can access simultaneously. Fig.1 Sharding Server Replication Replication provides redundancy and increases data availability.There are two kinds of sever in it: primary and secondary. We can write data into primary and only read from secondary and acts during Automatic Failover. When a primary does not communicate with the other members of the set for more than 10 seconds then secondary node becomes primary node automatically.So replication helps our application to be redundant without failure. Fig. 2 Replication Sharding and Replication Sharding and Replication both are combined to harness the benefits of both the features of MongoDB. Sharding addresses data growth and Replication provides for automatic failure recovery. To configure Sharding and Replication in local, we will demonstrate with one App server, one Config server, two Shard servers and one Replica server corresponding to each primary server. For production environment, it is ideal to use more than one App server to distribute client side requests. More than three Config servers are required in production to avoid single point failure. If the Config server is inaccessible, the cluster is not accessible. More than two shard must be configured or add more shards according to your application. It is recommended to use at least two replica set for each primary node in production for failure recovery. Fig. 3 Sharding and Replication Configuring Sharding and Replication Servers Create Config server mongod –configsvr –port 27010 –dbpath D:/Mongo_Cluster_Example/configDb mongod –configsvr –port 27010 –dbpath D:/Mongo_Cluster_Example/configDb mongod –configsvr –port 27010 –dbpath D:/Mongo_Cluster_Example/configDb Create App server mongod -configdb localhost:27010 –port 27011 mongod -configdb localhost:27010 –port 27011 mongod -configdb localhost:27010 –port 27011 Create Shard 1 MongoDB -shardsvr –replSet shard1 –port 27012 –dbpath D:/Mongo_Cluster_Example/db1 MongoDB -shardsvr –replSet shard1 –port 27012 –dbpath D:/Mongo_Cluster_Example/db1 MongoDB -shardsvr –replSet shard1 –port 27012 –dbpath D:/Mongo_Cluster_Example/db1 Create Shard 2 mongod -shardsvr –replSet shard 2 –port 27014 –dbpath D:/Mongo_Cluster_Example/db2 mongod -shardsvr –replSet shard 2 –port 27014 –dbpath D:/Mongo_Cluster_Example/db2 mongod -shardsvr –replSet shard 2 –port 27014 –dbpath D:/Mongo_Cluster_Example/db2 Create ReplSet 1 mongod –replSet shard1 –port 27013 –dbpath D:/Mongo_Cluster_Example/db1A mongod –replSet shard1 –port 27013 –dbpath D:/Mongo_Cluster_Example/db1A mongod –replSet shard1 –port 27013 –dbpath D:/Mongo_Cluster_Example/db1A Create ReplSet 2 mongod –replSet shard 2 –port 27015 –dbpath D:/Mongo_Cluster_Example/db2A mongod –replSet shard 2 –port 27015 –dbpath D:/Mongo_Cluster_Example/db2A mongod –replSet shard 2 –port 27015 –dbpath D:/Mongo_Cluster_Example/db2A Connect replica set 1 to primary shard mongo –host localhost –port 27012config = {_id: “shard1”, members: [ { _id: 0, host: “localhost:27012”} , { _id: 1, host: “localhost:27013”} ] }rs.initiate(config)rs.status() mongo –host localhost –port 27012config = {_id: “shard1”, members: [ { _id: 0, host: “localhost:27012”} , { _id: 1, host: “localhost:27013”} ] }rs.initiate(config)rs.status() Connect replica set 2 to primary shard mongo –host localhost –port 27014config = {_id: “shard2”, members: [ { _id: 0, host: “localhost:27014”} , { _id: 1, host: “localhost:27015”} ] }rs.initiate(config)rs.status() mongo –host localhost –port 27014config = {_id: “shard2”, members: [ { _id: 0, host: “localhost:27014”} , { _id: 1, host: “localhost:27015”} ] }rs.initiate(config)rs.status() mongo –host localhost –port 27014config = {_id: “shard2”, members: [ { _id: 0, host: “localhost:27014”} , { _id: 1, host: “localhost:27015”} ] }rs.initiate(config)rs.status() Set App Server metadata mongo –port 27011 –host localhostsh.addShard( “shard1/localhost:27012,localhost:27013” )sh.addShard( “shard2/localhost:27014,localhost:27015” )use mongodb;db.createCollection(“clustering”)sh.enableSharding(“mongodb”)sh.shardCollection(“mongodb.clustering”, {“_id” : 1})for ( i = 1; i < 999; i++ ) { db.clustering.insert({ type: “sharding”, score : i}); db.clustering.insert({ type: “replication”, score : i });}sh.status() mongo –port 27011 –host localhostsh.addShard( “shard1/localhost:27012,localhost:27013” )sh.addShard( “shard2/localhost:27014,localhost:27015” )use mongodb;db.createCollection(“clustering”)sh.enableSharding(“mongodb”)sh.shardCollection(“mongodb.clustering”, {“_id” : 1})for ( i = 1; i < 999; i++ ) { db.clustering.insert({ type: “sharding”, score : i}); db.clustering.insert({ type: “replication”, score : i });}sh.status() mongo –port 27011 –host localhostsh.addShard( “shard1/localhost:27012,localhost:27013” )sh.addShard( “shard2/localhost:27014,localhost:27015” )use mongodb;db.createCollection(“clustering”)sh.enableSharding(“mongodb”)sh.shardCollection(“mongodb.clustering”, {“_id” : 1})for ( i = 1; i < 999; i++ ) { db.clustering.insert({ type: “sharding”, score : i}); db.clustering.insert({ type: “replication”, score : i });}sh.status() Check in shard 1 PRIMARY mongo –host localhost –port 27012use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() mongo –host localhost –port 27012use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() Check in shard 1 SECONDARY mongo –host localhost –port 27013rs.slaveOk()use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() mongo –host localhost –port 27013rs.slaveOk()use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() Check in shard 2 PRIMARY mongo –host localhost –port 27014use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() mongo –host localhost –port 27014use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() Check in shard 2 SECONDARY mongo –host localhost –port 27015rs.slaveOk()use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() mongo –host localhost –port 27015rs.slaveOk()use mongodbdb.clustering.find().sort({_id : 1}).limit(1).pretty() Here, Step 1 to 6 are for connecting all necessary nodes. Steps 7 , 8 and 9 for connecting them together. Step 10 to 13 are for testing your configuration. You will find same data in shard1 and it’s replica set, similarly for shard 2 and it’s replica set. Also data which is inserted through App server are distributed across both shard servers. Concept of connected devices and better internet services
Integrating Slack Webhooks for Collaboration
Integrating Slack Webhooks for Collaboration Avakash Dekavadiya What is Slack? Slack founded by Stewart Butterfield is a cloud-based set of team collaboration tools and services. Slack provides features like direct-messaging, voice call, public and private channels, notifications and alerts, document sharing, search and more. Slack offers integration with many third-party applications and services, including Google Drive and Dropbox. Incoming Webhooks Slack supports both incoming and outgoing Webhooks. Incoming Webhooks is way to post messages from external sources into Slack Channel, using HTTP requests with a JSON payload that includes the text message and some other advanced options like message attachments. Steps to Integrate Webhooks Create App:- It provides custom functionality for your team and allows to integrate third party app. Create Incoming Webhooks:- After Creating App you will be redirected to page from where you can create webhooks by turning it on. Now, on the same page below click Add New Webhook to Team. After that you will have dropbox which will allow you select your channel name in which your third party app will be integrated and you will find your input message to that channel. Once you have selected your channel, you will be redirected to page of HTTP URL. URL will be used for posting data in that channel. Sending Message:- Send a HTTPS POST using given webhook URL with header Content-type: application/json and payload as shown below. If you want to send bold payload then place your text in between “*” and for new line use “n”. After sending this HTTPS request You will get back your payload in correspondence channel. POST https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX Content-type: application/json{ “text”: “This is *Bold*.nThis is new line.”} By leveraging Slack incoming webhooks, organizations can create virtual collaboration space for projects and departments quickly. The ease of integrating with other applications is an added advantage for as teams can access the resources from a single-window operation. AIMDek has deployed Slack at multiple client locations and has received a wonderful response. For more details on Slack as a collaboration platform, please reach out to sales@aimdek.com skip render: ucaddon_next_prev_post
Digital Insurance – The future of insurance carrier
Digital Insurance – The future of insurance carrier Avakash Dekavadiya The core transformation investments of many insurance companies stand unrealized to their maximum value, and are eventually leading their operational capabilities into the 21st century. It seems eminent to shift focus on digital strategies to fuel growth in such scenario. The digital strategies envelop everything from communicating with clients to managing social media to search engine optimization.It is vital for insurance companies to have a good intranet and extranet platform to address their pressing business need. The linchpin of insurance company’s digital strategy is the portal that allows to a achieve all the objectives at one go Intranet portals are hosted on private network and are accessible only to the organization’s staff. It acts as an important focal point for internal communication and collaboration, while providing single window to access all internal resources. While. extranet Portals reside on public network and allows controlled access to suppliers, vendors, partners, customers, or other business stakeholders. Benefits of Portal Portals make it easier for employees, captive agents, independent agents to access their policyholders’ details from central server with like products, billing history, claims, etc. A good portal also equips its users with easy-to-use interface and dashboard personalization. For example: a user can update their personal details, information about their owned policies, billing transactions, claims, etc. They act as a single-window for simple & quick online policy purchase, easy filing of claims, policy renewals, E-proofs etc. For Policyholders Account Opening: Supports simple and integrated account opening. For instance, to open an account, users need only an ID and password, to simply signup without purchasing a policy Online Policy Purchase: Simple & quick online purchase, easy claim settlement, policy renewal, e-proofs. Personalized User Data: Policyholder can access following information Policy details Fund price information(including push notifications) Account information(investment linked accounts) Personal information Advisor information For Captive Agents Helps captive agents measure their performance and maintain their relationships with policyholders. Captures policyholders’ interactions and information, leading to improved communication and relationship management Enables cross-selling based on the profile and need of policyholder For Independent Agents Supports agents’ business transactions with carriers and maintaining relationships with policyholders Provides the ability to view and manage personalized incentives and compensation reports. For Service Center Personnel Enables better client service Supports account services such as billing plan updates and payment reconciliations Supports agent licensing with state insurance departments and facilitates appointment between agents and potential/existing policyholders. For Sales Product Information including new products Target based marketing with personalized offers Auto notification of portal activity to the advisor (potential sales events) Promotion of annual checkup Communication Secure email channel to enable most service transactions and provide an easy route for non-urgent communication Secure email channel to enable most service transactions and provide an easy route for non-urgent communication Integrate with SMS Customer surveys The portal allow role-based access to employees. While it provides secure channel for internal communication, it also allows community based discussion platform for organization and its stakeholders. The tag based search functionality helps in quick search through content making it a centralized knowledge base. Various technologies can be leveraged to build portals for Life Insurance, Health Insurance, Automobile Insurance, Electronic Gadgets Insurance, property & Casualty Insurance, etc. Leading technologies are listed below: Liferay IBM WebSphere Portal. Oracle WebCenter Portal. SAP NetWeaver Portals have evolved from being functional to collaborative in nature. The transition from basic knowledge bank to self-service hub can’t be overlooked. Organizations have realized the value portals bring to connect their internal and external stakeholders. They are partnering with technology partners to customize and integrate their portals to make it a powerful communication tool. To know more about Portal, reach us at sales@aimdek.com. skip render: ucaddon_next_prev_post
