Service Oriented Architecture – Basics
 

The Service Oriented Architecture (SOA) is not a technology instead it is a collection of Services. Precisely it is an architectural style for building business applications using loosely coupled services which communicates with each other.

SOA      =    Messages + Services

Services – Self-contained business functionality and communicate using messages.

Messages – It is a discrete unit of communication.  It should be cross-platform, secure, asynchronous, reliable, follow the industry standard, and able to describe and discover the service.

The SOA shifts your thinking from classes and objects to messages.

The webservice is nothing but a service available over the web (Or method of communication between two devices over a network) while API (Application Programming Interface) acts as an interface between two different applications so that they can communicate with each other. The API may or may not be web-based.  Having said that all the all the web services are APIs but all APIs are not web services. The webservice always needs a network while for API it may/may not be needed.

WebServices are mainly of two types

  1. SOAP
  2. RESTFul

Let’s understand the differences between SOAP and REST

  1. SOAP stands for Simple Object Access Protocol. REST stands for Representation State transfer.
  2. SOAP is an XML based protocol which uses WSDL for communication between source and recipient. REST is an architecture style protocol which uses XML and JSON to communicate between consumer and provider.
  3. SOAP uses RPC while REST directly uses URL.
  4. The transfer is over HTTP, FTP, SMTP and other protocol for SOAP while for REST it is HTTP only.
  5. SOAP is hard to implement over REST.
  6. The performance is slower compared to REST.
  7. SOAP is more secure since it does define its own security. The REST is less secure. The transport defines the security. (Smart consumer and provide while dumb pipe).

The SOAP message is large.  The core element of SOAP message is a SOAP envelope. The SOAP envelope defines the start and end of the message. It has two parts 1. SOAP HEADER 2. SOAP BODY

WSDL – Web Service Description Language

The WSDL is an XML based interface that is used to describe the functionalities of the webservices .

Microservices to Micro-Frontends – Simple explanation
 

Microservices

Microservices is one of the newer concepts and a variant of a Service Oriented Architecture (SOA). Although SOA has been there for almost two decades while the Microservices came into existence in 2012.

Microfrontends

The idea is to have small autonomous services to work together to build a large complex application. The approach focuses on individual business sub-domains and building small services making them easier to maintain, and promotes independently deployable pieces thus ensuring that internal changes in one service do not affect or require the redeployment of other services. In today’s software development landscape, most applications are monolithic and one of the drawbacks of this approach is that business owners get to take a very limited number of decisions in a year (slower response times because of dependencies). For instance, upgrading a product, adding newer functionality that is significant in size, etc within a set of related services requires a concerted effort of all concerned parties to deliver changes in a synchronized manner. Microservices allow you to take more far-reaching business decisions more spontaneously as each microservice works independently and an individual team who is managing that has a good control over the changes. This is also helped by the fact that well-implemented microservices attempt to steer clear of the ‘shared database’ model of development (mentioned later in this post).

The microservices architecture allows each team to decide the technology and infrastructure that works best for them, which may be completely different from other microservices that it interacts with for the very same product. Another aspect of choice is seen when attempting to scale a Monolith application, where you need to scale every component as all components under one product typically run under the same process. This usually reduces flexibility that may require only a small subset of the features to be scaled (eg. performance bottleneck in one piece of a payment processing pipeline). Given such circumstances, scaling a monolithic application as a whole may soon turn into an expensive affair. On the other hand, each set of microservices can (potentially) be scaled independently of the others, thus helping focus resources on areas where the problem truly lies.

I have been reading building microservices by Sam Newman and really liked the 8 keys principles explained by him. In this post, I am attempting to provide a high-level overview of those principles and I highly encourage you to read his book to get a more detailed understanding of these concepts.

You can buy this book by clicking it on below book

The eight key principles are

1. Modeled around business domain 

Focus on your business domain and identify individual subdomains and build services. A good way to start would be to follow the principles of Domain-Driven Design.

2. Culture of automation

Infrastructure automation is what smart companies are focusing on today.  Provisioning a new machine, operating system and service should be automated.

Automation testing and continuous delivery are critical as well so as to deploy/release your software frequently and reliably.

3. Hide implementation details.

Hide your database, and hide your functionality. Each service should have its own database and if shared information is needed from other services, leverage service endpoints designed for the specific subdomain to extract what is expected. While migrating a monolithic application to a microservice(ish) structure, it is often considered easiest to tease apart application level code while leaving the (shared) underlying database as is. There is often a variety of rationale provided for doing this ranging from a lack of confidence in the success of this migration to potential issues faced for data analysis and report aggregation purposes. However, this shared database continues to serve as a source of coupling between the independent services far greater than the decoupling achieved by spinning off the application level services.

4. Decentralize all the things

Focusing on autonomy (giving people as much freedom as possible to do the job in hand), self-service (do you have to create a ticket to provision a machine or you can do it all by your self), shared governance (making architecture work) and avoiding complex messaging is important.

5. Deploy independently

If you have 4 services and all of them have to be deployed together due to dependency then fix that before you create 5th service. Having one service per host makes life very easy for everyone. Docker is getting a lot of traction for such isolation of operating environments.

In such an environment of independent deployments, consumers drive contracts where when you make a change, the consumer service has expectations about not facing challenges when you deploy changes.

When there are co-existing endpoints, for instance in an upgrade scenario, the consumer service would switch to a newer version while the provider continues supporting the existing version for a limited time period this providing some time for other services to migrate without holding the entire system hostage to its changes.

6. Consumer First

As the creator of an API, it is very important that you make your service easy to consume. The documentation plays an important role here.

7. Isolate Failures

Microservice architecture doesn’t automatically make your systems more stable. To the contrary, it makes the overall system more vulnerable to certain types of network and hardware related issues (more points of failure). You should have ways to isolate failures and look for ways to recover such as failover caching and retry logic.

8. Highly observable

It is very important to know what is happening in your system with so many moving parts. Each service may depend on multiple services and vice versa.  There needs to be constant observation and monitoring to ensure the whole integration is smooth.

Microservices often communicate via HTTP/REST (Synchronous) or utilizes Asynchronous protocols like JMS, RabbitMQ etc.  It is perfectly fine and acceptable to use Synchronous protocols for public APIs while when dealing with microservices internal communications, you should go with Asynchronous protocols.

In a typical monolith application when you want to fetch the data to show in search functionality, all you have to do is join multiple tables and present it to a user. If you want to achieve the same using microservices, there is going to be a big performance hit as you need to retrieve it from each and every microservices which may not be a good idea.   In this situation, I would recommend you to go with Elasticsearch. You can display the high-level data coming from one table. When a user clicks on an individual item, you can always go to all microservices. Moreover, you can run them all in parallel on top of it. This can significantly reduce the pain of performance bottlenecks in homegrown solutions.  There are multiple scenarios like this that entice teams and organizations to avoid going with microservices while an easier way out exists. I would be discussing some of the very common challenges and their resolution in details in my upcoming blogs

Micro-Frontends

Microservices architecture gives you enormous benefits when done right. When implementing a microservices architecture, you certainly want to keep your services small.  Most of the companies and teams I have come in contact with having a tendency to do so with the backend, primarily for two reasons.

  1. It is expensive in terms of time and money.
  2. Knowledge gap

Although you are better off going with a monolith application while you would not gain most of the benefits as you cant deploy your backend services independently without the front end.  In such scenarios, not only is application scaling a challenge,  you also need to update the front end whenever an API is deployed with breaking changes.

 

The idea with a Micro-Frontend is to decompose your application into smaller units based on screens representing domain-specific functionality instead of writing large monolithic front-end applications. The front-ends are self-contained and can be deployed independently. SPAs (single page applications) are the best way identified so far to go this route and domain driven architecture helps achieve this to a great extent. You can have backend, frontend, data access layer, and database, everything required for a subdomain in one service. Every piece of the service should be worked by an independent team. Collaboration and communication play an important role here and as long as you adhere to best practices and principles of microservices, you are most likely to get successful and gain maximum out of your product/software.

Benefits of Micro-Frontends

  1. The individual development team can choose their own technology.
  2. The development and the deployment are very quick.
  3. The benefit of microservices can be leveraged in a much better way. The dependency is drastically reduced.
  4. Helps in continuous deployment.
  5. The maintenance and support are very easy as the individual team owns a specific area.
  6. The testing becomes simple as well as for every small change, you don’t have to go and touch the entire application.

Challenges

  1. The UX consistency is an important aspect. The user experience may become a challenge if the individual team goes with their own direction hence there should be some common medium to ensure UX is not compromised.
  2. The dependency needs to be managed properly. The collaboration becomes a challenge at a time. The multiple teams working on one product should be aligned and have a common understanding.

 

The most basic Java Script Interview Questions
 

JavaScript developed by Netscape. JS is a client side as well as a server-side scripting language. It is interpreted programming language as well with object orientated capabilities.

1. How do you create a class in JavaScript?

Answer – There are multiple ways you can create a class in JS. For example

Method 1 – Using functions

// This is a class name

function Flat(aptName, location){

// You can define object properties

this.aptName = aptName;

this.location = location;

this.getLocation = getLocationInfo

}

// The method can be defined as

function getLocationInfo{

return “The location is “ + this.location;

}I

// You can even define function of a class like this

Flat.prototype.getFlatInfo = function() {

alert (“The apartment name is” +   this.aptName + “ and the location is “ + this.location = location);

// Instantiate new object of Flat class

var myFlat = new Flat(“Manjeera”, “Kukatpally”);

// Invoke methods like this

alert myFlat.getLocationInfo();

Method 2 – Using object literals

Var Flat = {

this.aptName = “manjeera”;

this.location = “kukatpally”;

this.getLocation = function() {

return “The location is “ + this.location;

}

}

Apart from using functions, and object literals, you can use object constructor as well to create JavaScript class.

2. What is the difference between ‘==’ and ‘===’?

Answer –       ‘==’ checks for equality only

‘===’ checks for equality and type

For example

false == 0 returns TRUE

false === 0 returns FALSE

3. What is isNan? Give example?

Answer – This would return true of the argument is not a number. For example

isNaN(23) returns false

isNaN(“2/3/2017”) returns true

4. What are the difference comments available in JavaScript?

Answer – There are two types of comments available in JavaScript

A. Single line comments

// This is a single line comment

B. Block comments

/*

This can be used

For block comments

..

*/

5. What are the types used by JavaScript?

Answer – There are six types used in Java Script

Boolean (True and False)

Null (null)

Undefined (undefined)

Number (Integers, floating etc.)

String

Object (Objects, Array, Functions etc.)

6. Is JavaScript a case sensitive?

Answer – Yes, JavaScript is case-sensitive.

7. How can you create an object in JavaScript

Answer – You can use object literal as shown below

var student  = {

name: “Sandeep”,

age: 36

};

Alternatively, you can use below (As explained in question number 1)

var myFlat = new Flat(“Manjeera”, “Kukatpally”);

8. Does JavaScript support exception handling?

Answer – Yes, it does support exception handling by means of try and catch. It supports try, catch, finally, throw etc. keywords to handle exceptions.

9. What is the difference between break and continue?

Answer – Break statement causes program control to exit from the loop.

The continue statement causes program control to continue with next statement.

10. What is the primary difference between ViewState and SessionState?

Answer – ViewState represents a page in session while SessionState is specific to user specific data which can be accessed all across in the web application.

 

 

 

 

 

 

 

 

Bloated Domain Objects And CQRS
 

Problem of Bloated Domain objects

In business software applications, the domain objects (entities) are used to represent the business domain. As the application grows and adds more business logic, the service layer, mappers and other patterns gets applied. This sector has held promise for many software developing companies, and has often been touted as the future of work. Often this leads to domain object becomes bloated and the related components become huge & un-maintainable.

CQRS solves the common problem of having a bloated Domain objects. The domain objects get bloated largely because of bounded context. The series of contexts which makes developers think that a single domain object is sufficient to handle all the related things. For example, a large Invoice object for handling Invoice, Shipment and handling change of address for customer . But in reality, these contexts (invoicing, shipment and change) need not be related to same Invoice entity.

What is Command, Query Responsibility segregation (CQRS)?

In order to simplify the Domain objects, CQRS proposes to have two types of domain entities.

  • those serving the command (ordering/assertion services)  – For example, SaveCustomer, CreateInvoice, ShipProduct etc
  • those serving a Query (request) – examples include GetCustomerAddress, SearchCustomer etc

With this separation, the complexity (number of fields, methods) of entities used becomes simplified. And hence the Data mapper layers & the service layers becomes more simplified.

Where can I use CQRS?

  • Largely complex system: Applying CQRS on a simple CRUD operation based system is a over kill. When there is a domain heavy system, like banking and financing systems, LOB applications where business logic, lots of boundary conditions are heavy. Where it makes DDD (Domain driven design) provides high value.
  • Situations where you will apply Microservices, Eventual consistency and Event Sourcing. When we have separation of concerns using CQRS, the microservices becomes much simpler to design and maintain. With Event sourcing we are focused on getting the data (query) from other related sources and is what CQRS propagates.

Final words

CQRS is a carefully thought out pattern for simplifying & solving large and complex systems.

50 Tips and Tricks for Web Performance
 

I came across the below video on the web performance improvement tips and tricks. This is fantastic.

In this video, Jatinder talks about Six fundamental principles for improving web application performance. He also talks a lot about how we go about Decreasing CPU time and increasing parallelism on the client machine to achieve faster web performance.

While I went through the video, I captured all the tricks he talks about. And thought will be useful for others while they watch it. Please find below the tricks.

Quickly respond to network request

  • Avoid 3XX Redirections (63% of top websites use redirect)
  • Avoid Meta refresh
  • Minimise Server time for Requests
  • Use Content distribution Networks (CDN)
  • Maximise concurrent connections.
  • Reuse connections – don’t sent connection close.
  • Know your other servers – you are only fast as your weakest link
  • Understand your network timing

Minimise bytes downloaded

  • GZIP Compression Network traffic
  • Persist application resources locally (Windows 8 applications)
  • Cache dynamic resources in the application Cache (html5 app cache)
  • Provide cacheable content
  • Send Conditional request
  • Cache Data requests (jQuery AJAX calls)
  • Standardize File name capitalization convention.

Efficiently structure markup

  • Load pages in latest browser mode
  • Use http header to specify legacy IE mode
  • Link CSS in the top of the page header, never on the bottom.
  • Avoid using @import of hierarchical styles
  • Avoid embedded and inline CSS
  • Only include necessary styles in the page.
  • Always link JS at the end of the page.
  • Avoid linking JS in the header (use the defer & async attribute)
  • Avoid Inline JS
  • Remove Duplicate code (52% of the web have duplicate code
  • Standardise on a single framework

Optimise your media usage

  • Avoid death by too many images
  • If possible use Image Sprites
  • Use png image file format
  • Use Native image resolutions
  • Replace Images with CSS3 Gradients, border Radius
  • Leverage CSS3 Transforms
  • Use Data URI’s for Small Single view images
  • Avoid complex SVG paths
  • Video : Use preview images
  • Minimize media plugin usage
  • Proactively download Future media

Write Fast JavaScript

  • Stick to Integer math (Math.Floor)
  • Minify your JavaScript
  • Initialize JavaScript on Demand
  • Minimize your DOM Interactions
  • Built in DOM methods always more efficient (firstchild, nextsibling methods are faster)
  • Use Selectors for Collection access (document.querySelectorAll)
  • Use .innerHTML to construct your page
  • Batch your markup changes
  • Maintain smaller DOM (less than 1000 elements)
  • JSON always faster than XML (possible myth)
  • Use Native JSON methods
  • Use regular expressions Sparingly

Know what your app is doing

  • Understand JavaScript Timers (setTimeout, SetInterval)
  • Combine Application Timers
  • Ensure dormant timers are not running
  • Align timers to display Frame (16.7)
  • Use window.requestAminationFrame(renderLoop) for Animations
  • Know when your application is visible (document.hidden, Visibilitychange (event))

Conclusion

The web optimisation is not easy and needs exhaustive, deep look and hopefully this check list helps while optimising your pages. Enjoy coding high performing applications. If you have more tips please provide them in the comments.

 

Micro-Services, Eventual Consistency and Event sourcing patterns
 

Microservices is a really becoming a famous architectural pattern that most of the new software written these days, just apply them. One of the most important differentiation between the traditional web services and micro-services pattern is the amount of common stuff across different subject areas. This calls for a discussion on how Eventual Consistency pattern is mandatory for successfully implementing microservices.

The micro frontend if gaining lots of popularity.  You can read about microservices principles and micro frontends at

Microservices and Microfrontends

Micro-Service Pattern

Generally, in a micro-service pattern, the API’s are split into small subject areas. For example for a CRM application, the subject areas are

  • Customer information – like name, address, email, phone
  • Appointment information – which customer, salesperson, when, where
  • Relationship management – sales/manager, what products, interests
  • Campaign data – offers, deals etc

Then micro-services are built for each of the subject areas.  The microservices are logically and physically separated from each other. ie there is no sharing (code, database, component etc) between any of these micro-services of these subject areas. Pictorially its looks something like this.

Applying Eventual Consistency Pattern

In Micro-services, there is no data that is shared across the micro services. In order to synchronize the data across these isolated storages of these services, we need to apply the eventual consistency pattern. You can read more about applying the pattern correctly here. The simpler way we can achieve consistency across these micro-services is through Event Sourcing pattern.

Event Sourcing

Event sourcing is a process of capturing application state changes in the form of events.  An example of events are customer created, customer updated, Deal created, etc.  Other systems listen to these events and they take relevant action. You can read more about event sourcing here.

Conclusion

Event sourcing is the new way of storing changes to systems and help in making micro-services eventually consistent. These patterns together form well maintainable, reliable and scalable systems in the modern world.

 

 

MEAN stack Part 2 – Yeoman and generator-angular-fullstack
 

This is the second post in the Getting started with MEAN series where we start looking at the Node ecosystem for stable web application frameworks for our application. A brief glance through the Express framework showed that express by itself would be time consuming start off with from scratch. On the other hand, the Express.js website links to a number of frameworks built on top of Express. This looked like a good place to start exploring.

Going through the list of frameworks mentioned there, however, we quickly noticed that a number of options were either targeted only (or primarily) towards APIs, lacked sufficient documentation for our needs, or did not appear to have a sufficiently large community behind them. Mind you, the assessment wasn’t entirely objective, as I did have previous experience with generator angular fullstack.

Why generator-angular-fullstack

Generator angular fullstack is a Yeoman generator that provides an application skeleton as well as sub generators that allow the developer to quickly scaffold various UI and API components. The generator supports a number of customizations through questions asked before generating the app. The ones I found most useful were:

Client Side

  • Html templating : HTML, PUG (previously Jade)
  • Angular Router : ngRouter, ui-router
  • Stylesheets : css, stylus, sass, less
  • CSS frameworks : bootstrap (with the option to include UI Bootstrap)

Server Side:

  • Scripts : javascript, Typescript
  • Databases : none, Mongodb, SQL
  • Authentication boilerplate
  • oAuth integration with Facebook, Twitter and Google Plus
  • Socket IO integration

Phew! That was a lot of options built into the generator itself, stuff that teams and products usually like to customize according to their convenience. This by itself is a strong reason to select the framework, because none of the other frameworks that we evaluated came anywhere close in terms of customizability and out of the box functionality. The generator also comes with built in hooks to deploy your application to Heroku or Openshift, although I found that part to be a little broken (more on that later)

A lot of things have changed though, since my last experience. For one, the guys over at generator-angular-fullstack added support for Typescript. Typescript in fact, is a superset of javascript, but brings a number of enhancements (including transpile time type safety) to the table. On the other hand, the generator still works with Angular 1.x, although the alpha version does support Angular 2. But then, working with the alpha version for a project needing quick turnaround times didn’t sound like an exciting thought.

Anyway, coming back to getting started with the application.

Getting Started

Installing Yeoman

 npm install -g yo

Installing the angular fullstack generator and its prerequisites

npm install -g yo gulp-cli generator-angular-fullstack

On a side note, please read node-gyp’s installation guide before going any further to get the application to run successfully. Node-gyp is required to compile native drivers for each platform and on windows, there are a couple of different ways to support the compilation process. Personally, I was able to get option 2 on the link mentioned above working (see: “Option 2: Install tools and configuration manually”)

Initializing the App

Finally! Coming down to the crux of the matter. Initializing the app

Run : yo angular-fullstack

The installer asks a number of questions about customization, including the ones mentioned above, and once the installer has completed, you have a fully functional app (with authentication if you selected it during install) ready for you to work on.

Running the app is as simple as running : gulp serve

You just need to make sure that if you selected a database, it is running on your local box so the node API can connect to it. If the DB is not found, the application will simply crash, but you already knew that would happen 🙂

Stay tuned for the next article about the getting familiar with the code generated by the Yeoman generator

Most frequently asked .NET interview questions for 5 years or less
 
  1. What is the difference between System.Array.CloneTo() and System.Array.CopyTo()?
  2. What is the difference between an interface and an abstract class? Give examples of their use in real life?
  3. Can you use “this” with the static class?
  4. What is the primary difference between “read-only” and “constants”?
  5. What is a garbage collector? Can we force the garbage collector to run? Is that guaranteed that it would run?
  6. What is public, static, void, and main?
  7. Can we execute multiple catch blocks written for the same try block?
  8. What is the difference between Finalize() and Dispose() method?
  9. What is a sealed class in C#? Explain with examples?
  10. What is the difference between a HashTable and a dictionary? When to use what? Give an example of each?
  11. What is “out” and “ref” parameter in C#?
  12. What is “protected internal” in C#?
  13. What is a “finally” in exception handling? How does it differ from finalize?
  14. What is generics?
  15. What is the difference between a connection pooling and an object pooling? How and where do you set the connection pooling parameter?  What is the default value?
  16. What is multiple inheritance? Is it allowed in C#? How do you achieve that?
  17. What is boxing and unboxing? Give examples of each?
  18. What is a copy constructor?
  19. What is a static constructor?
  20. What is the difference between overriding and overloading? Give examples?
  21. What do you mean by virtual method?
  22. What types of comments are used in C#?
  23. What is abstraction, inheritance, polymorphism, and encapsulation?
  24. What is the relation between data hiding and encapsulation?
  25. What all the access modifiers you have in C#?