Interview Preparation

[eziceice]

Solid Principale

• SRP - The Single Responsibility Principle 单一责任原则
• OCP - The Open Closed Principle 开放封闭原则
• LSP - The Liskov Substitution Principle 里氏替换原则
• ISP - The Interface Segregation Principle 接口分离原则
• DIP - The Dependency Inversion Principle 依赖倒置原则

Single Responsibility Principle

• One class should have one and only one responsibility.

Open Closed Principle

• Software components should be open for extension, but closed for modification.
  • This means that our classes should be designed such a way that whenever fellow developers wants to change the flow of control in specific conditions in application, all they need to extend our class and override some functions and that’s it
• Try to use Java Enum to replace multiple if statement and then only enum will be modified instead of the method itself. Or use interface and implements the interface to extends the functions.

Liskov’s Substitution Principle

• Derived types must be completely substitutable for their base types.

Interface Segregation Principle

• Clients should not be forced to implement unnecessary methods which they will not use.

Dependency Inversion Principle

• Depend on abstractions, not on concretions.
• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

[eziceice]

REST API DESIGN

Basic Design Guide

• Identifying the objects which will be presented as resources.
• Idempotent: GET, HEAD, OPTIONS and TRACE methods are defined as safe, meaning they are only intended for retrieving data and should not change a state of a resource on a server.
• Version:
  • Custom Header: Adding a custom X-API-VERSION (or any other header of choice) header key by client can be used by a service to route a request to the correct endpoint
  • Add version in header Accept.
  • Embed the version in the URL such as POST /v2/users
• Pagenation:
  • Filter - GET /users/123/posts?state=published
  • Search (Multiple Filters) - GET /users/123/posts?state=published&ta=scala
  • Sorting - GET /users/123/posts?sort=-updated_at
• Status Code:
  • 2xx Success 200 OK: Returned by a successful GET or DELETE operation. PUT or POST can also use this, if the service does not want to return a resource back to the client after creation or modification. 201 Created: Response for a successful resource creation by a POST request.
  • 3xx Redirection 304 Not Modified: Used if HTTP caching header is implemented.
  • 4xx Client Errors 400 Bad Request: When an HTTP request body can’t be parsed. For example, if an API is expecting a body in a JSON format for a POST request, but the body of the request is malformed. 401 Unauthorized: Authentication is unsuccessful (or credentials have not been provided) while accessing the API. 403 Forbidden: If a user is not Authorized to perform an action although authentication information is correct. 404 Not Found: If the requested resource is not available on the server. 405 Method Not Allowed: If the user is trying to violate an API contract, for example, trying to update a resource by using a POST method.
  • 5xx Server Errors These errors occur due to server failures or issues with the underlying infrastructure.

Caching Guide

• Using HTTP headers, an origin server indicates whether a response can be cached and if so, by whom, and for how long. Caches along the response path can take a copy of a response, but only if the caching metadata allows them to do so.
• Optimizing the network using caching improves the overall quality-of-service in following ways
  • Reduce bandwidth
  • Reduce latency
  • Reduce load on servers
  • Hide network failures
• Related cache headers:
  • Expires: The Expires HTTP header specifies an absolute expiry time for a cached representation. Beyond that time, a cached representation is considered stale and must be re-validated with the origin server. To indicate that a representation never expires, a service can include a time up to one year in the future.
    • Expires: Fri, 20 May 2016 19:20:49 IST
  • Cache-Control: The header value comprises one or more comma-separated directives. These directives determine whether a response is cacheable, and if so, by whom, and for how long e.g. max-age or s-maxage directives.
    • Cache-Control: max-age=3600, private/public, No-cache/No-store
    • No-Cache: User agent has to always ask the server if it's OK to use what it cached.
    • No-Store: User agent is not allowed to cache that response.
    • Private: Default value. Sets Cache-Control: private to specify that the response is cacheable only on the client and not by shared (proxy server) caches
    • Public: Sets Cache-Control: public to specify that the response is cacheable by clients and shared (proxy) caches.
  • ETag: An ETag value is an opaque string token that a server associates with a resource to uniquely identify the state of the resource over its lifetime.
    • ETag: "abcd1234567n34jv"
  • Last-Modified: Whereas a response’s Date header indicates when the response was generated, the Last-Modified header indicates when the associated resource last changed. The Last-Modified value cannot be later than the Date value.
    • Last-Modified: Fri, 10 May 2016 09:17:49 IST

[eziceice]

Code coverage

• Statement Coverage: Use this type of coverage to determine whether every statement in the program has been invoked at least once.

  • Statement coverage = (Number of executed statements / Total number of statements) *100

• Condition Coverage: Condition coverage analyzes statements that include conditions in source code.

  • Condition coverage = (Number of executed condition outcomes / Total number of condition outcomes) *100

• Boundary Coverage: Boundary code coverage examines code that has boundary execution.

• Function Coverage: Function coverage determines whether all the functions of your code have been called during simulation.

• Branch coverage: Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed? For example, given an if statement, have both the true and false branches been executed? Notice that this one is a subset of Edge coverage.

[eziceice]

Microservices

Monolith

Traditionally web applications are big. You write one piece of software that runs on a server and answers requests in form of HTML, XML or JSON. If you want your web application to do something new, you add that functionality to the existing application. Such big systems are called "monolithic" (a monolith is a very big rock).

Monoliths are problematic, because they usually grow in size and complexity over time. This is a problem when developing something in a team. Developers are adding new code to the system and can't change or re-use the existing code, because there is many dependencies between the code pieces. They are also too afraid of removing old code because it might be used somewhere.

When delivering such code to clients, e.g. by putting it on the internet, we call that "deploying". Deploying and the usual testing after deployment is difficult, because within a big system there is a lot of things that can break. Finding out what is going wrong and who should fix it, is very difficult and requires people to know the whole thing.

Another disadvantage is the scalability. By that we mean "how can we serve more users at the same time?" A single web server computer can only handle a certain amount of users accessing it in parallel. Upgrading that computer to better hardware makes it serve more users, but you will soon hit the boundaries of what is possible with hardware. This upgrading is called vertical scaling. We could also put our web application on two or more servers, so that we can handle more users. This is called horizontal scaling. Monolithic applications are traditionally made only with vertical scaling in mind.

Microservices

In order to simplify the workflow with big applications, we can split it into smaller parts. Each part serves one particular purpose. We call that a "(web) service". These web services are very flexible to use. You can use them from within your existing monolithic application, either in the server part, or in the client part. You can also have a web service that uses other web services.

The split into single web services allows you loosely couple your application. This means that as a user of the service you only depend on the service being up, available and working. You no longer need to take care of its dependencies, its compilation, deployment or testing.

You can give that responsibility to a different developer or team. You can't break their web service because you do not access it through the source code. They can even use a different programming language and you could still use their service.

This independence is made possible by deciding on using a common format and common protocols(a protocol is a way of communicating). For web services the most popular formats are JSON and XML. The protocol used the most is HTTP, because it's simple, well-supported by all existing software and your browser is using it, too.

The word "micro" in "microservices" just emphasises the idea to make these web services as small as possible. If you need a more complex service, it is usually better to create a new service that depends on one or more others.

Advantages and Disadvantage of Microservices

• Disadvantages:
  • Complexity: The biggest disadvantage of a microservices architecture is its increased complexity over a monolithic application.
    • As each service has its own database, transaction management and data consistency can become a nightmare
    • The initial refactoring of a monolithic application can be exceedingly complex for large enterprise applications
    • Increases in documentation overhead as organization has to keep schemas and interface documents up to date.
    • Low latency network will be highly required as network communication among those services are the fundamental of the microservices.
      • Security: Each microservices must be secured and ensure only valid user can access its data.
• Advantages:
  • Improve fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
  • Working with new technology: each module is not limited in one programming languages. A lot of options are available if it meets the requirements.
  • Ease of Understanding and Maintaining: With added simplicity, developers can better understand and maintain the functionality of a service.

[eziceice]

CI/CD

Continuous integration

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch. Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

• What is needed?
  • Automated tests need to be created for each new feature, improvement or bug fix.
  • Some CI tools Jenkins/Bamboo which could monitor changes from git and build it and run test automatically.
  • Changes need to be merged in main branch quite often, at least daily.
• What you gain?
  • Less bugs get shipped to production as regressions are captured early by the automated tests.
  • Building the release is easy as all integration issues have been solved early.
  • Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.
  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
  • Your QA team spend less time testing and can focus on significant improvements to the quality culture.

Continuous delivery

Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button. In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

• What is needed?
  • Jenkins/Bamboo to do auto deployment.
• What you gain?
  • Time. Doesn't need to prepare several days for the release.
  • Accelerating the feedback from real users.

Continuous deployment

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production. Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it.

• What is needed?
  • Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.
  • Your documentation process will need to keep up with the pace of deployments.
• What you gain?
  • You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
  • Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.

Diagram about CI/CD

[eziceice]

Docker and Kubernetes

Docker

Docker (and containers in general) solve the problem of packaging an application and its dependencies. This makes it easy to ship and run everywhere.

Kubernetes

Kubernetes is one layer of abstraction above containers. It is a distributed system that controls/manages containers.