Other Flashcards
Cors
Cross origin resource sharing
Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.
An example of a cross-origin request: the front-end JavaScript code served from https://domain-a.com uses XMLHttpRequest to make a request for https://domain-b.com/data.json.
For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers.
What is SOLID
Single Responsibility Principal Open Closed Principal Liskov Substitution Principal Interface Segregation Principal Dependency Inversion Principal
CQRS
CQRS stands for Command and Query Responsibility Segregation.
Apattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security.
What is Agile
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
Whereas the traditional “waterfall” approach has one discipline contribute to the project, then “throw it over the wall” to the next contributor, agile calls for collaborative cross-functional teams. Open communication, collaboration, adaptation, and trust amongst team members are at the heart of agile. Although the project lead or product owner typically prioritizes the work to be delivered, the team takes the lead on deciding how the work will get done, self-organizing around granular tasks and assignments.
Agile isn’t defined by a set of ceremonies or specific development techniques. Rather, agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement.
Cloud native
The term cloud native refers to the concept of building and running applications to take advantage of the distributed computing offered by the cloud delivery model. Cloud native apps are designed and built to exploit the scale, elasticity, resiliency, and flexibility the cloud provides.
As defined by the Cloud Native Computing Foundation (CNCF), Cloud native technologies empower organizations to build and run scalable applications in public, private, and hybrid clouds. Features such as containers, service meshes, microservices, immutable infrastructure, and declarative application programming interfaces (APIs) best illustrate this approach.
These features enable loosely coupled systems that are resilient, manageable, and observable. They allow engineers to make high-impact changes frequently and with minimal effort.
Benefits of cloud native
Benefits of a cloud native application
Cloud native applications—or native cloud applications (NCAs)—are programs designed for a cloud computing architecture. They have many benefits.
Independence: Their architecture makes it possible to build cloud native applications independently of each other. This means you also can manage and deploy them individually.
Resiliency: A well-designed cloud native application is able to survive and stay online even in the event of an infrastructure outage.
Standards-based: For interoperability and workload portability, cloud native services are often based on open source and standards based technology. This helps reduce vendor lock-in and results in increased portability.
Business agility: Cloud native applications enable flexible deployment options across the network, and are also smaller than traditional apps, which makes them easier to develop, deploy, and iterate.
Automation: Cloud native applications use DevOps automations features and enable continuous delivery and deployment of software changes that get released on a regular basis. Additionally, developers can use methodologies like blue-green and canary deployments to make improvements to the apps without any disruption to the user experience.
No downtime: Thanks to container orchestrators such as Kubernetes, you can deploy a software update with essentially zero downtime.
Cloud native - server less functions
Functions
The term serverless functions describes an architecture style that focuses on increasing developers’ productivity. A serverless application lets you write code on a platform that functions as a service (FaaS) using event-driven architectures and various backend-as-a-service (BaaS) models. This eliminates the need to worry about provisioning, patching, scaling, security, high availability, and so forth. With FaaS platforms, such as Oracle Functions, applications are broken up into small pieces of code (nanoservices), which are dynamically scheduled and run on demand when triggered by an event. The advantage of this approach is that code is called and executed only when needed, and you pay only for the resources used during the execution duration. This differs from a classic server approach, in which applications are loaded into a server and spend most of their time idle, waiting for requests. Thus, in serverless computing, you pay only for computing resources you actually use, rather than paying for idle resources.
Programming Paradigm
A programming paradigm can be termed as an approach or a style of writing code. Most of the modern programming languages fall into two general paradigms: imperative (procedural, OOP etc.) and declarative(functional etc.).
Declarative vs imperative examples
Popular examples of declarative languages are database query languages such as SQL, markup languages like HTML and CSS, and in functional and logic programming languages.
Popular examples of imperative languages are Java,C++ and C#
DRY principal
Don’t repeat yourself
Git Bisect
The idea behind git bisect is to perform a binary search in the history to find a particular regression. Imagine that you have the following development history:
… — 0 — 1 — 2 — 3 — 4* — 5 — current
You know that your program is not working properly at the current revision, and that it was working at the revision 0. So the regression was likely introduced in one of the commits 1, 2, 3, 4, 5, current.
You could try to check out each commit, build it, check if the regression is present or not. If there is a large number of commits, this can take a long time. This is a linear search. We can do better by doing a binary search. This is what the git bisect command does. At each step it tries to reduce the number of revisions that are potentially bad by half.
You’ll use the command like this:
$ git stash save
$ git bisect start
$ git bisect bad
$ git bisect good 0
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[< … sha … >] 3
After this command, git will checkout a commit. In our case, it’ll be commit 3. You need to build your program, and check whether or not the regression is present. You’ll also need to tell git the status of this revision with either git bisect bad if the regression is present, or git bisect good if it is not.
Binary Search Algorithm
Binary Search is a searching algorithm used in a sorted array by repeatedly dividing the search interval in half. The idea of binary search is to use the information that the array is sorted and reduce the time complexity to O(Log n).
The basic steps to perform Binary Search are:
Begin with an interval covering the whole array.
If the value of the search key is less than the item in the middle of the interval, narrow the interval to the lower half.
Otherwise, narrow it to the upper half.
Repeatedly check until the value is found or the interval is empty.
REST
A REST API (also known as RESTful API) is an application programming interface (API or web API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer and was created by computer scientist Roy Fielding.
SOA
SOA, or service-oriented architecture, defines a way to make software components reusable via service interfaces. These interfaces utilize common communication standards in such a way that they can be rapidly incorporated into new applications without having to perform deep integration each time.
SOA vs Microservice
SOA vs. microservices
Experts have filled a few thousand of print and digital pages comparing SOA and microservices and defining the subtleties of their relationship to one another. For the purposes of this article, the chief differences between the two are the coupling of components and scope of use:
SOA is an enterprise-wide concept. It enables existing applications to be exposed over loosely-coupled interfaces, each corresponding to a business function, that enables applications in one part of an extended enterprise to reuse functionality in other applications.
Microservices architecture is an application-scoped concept. It enables the internals of a single application to be broken up into small pieces that can be independently changed, scaled, and administered. It does not define how applications talk to one another—for that we are back to the enterprise scope of the service interfaces provided by SOA.
Microservices architecture emerged and gained steam with the rises of virtualization, cloud computing, Agile development practices, and DevOps. Most of the advantages of microservices in these contexts arise from the complete decoupling of the components, which simplifies and improves the following:
Developer agility and productivity: Microservices enable developers to incorporate new technologies to one part of the application without catching up the rest of the application. Any component can be modified, tested, and deployed independently of the others, which speeds iteration cycles.
Scalability: Microservices can take maximum advantage of cloud scalability—any component can be scaled independently of the others for the fastest possible response to workload demands and the most efficient use of computing resources.
Resilience: Again, thanks to decoupling, the failure of one microservice does not impact the others. And each microservice can perform to its own availability requirements without staking the other components or the entire application to greatest common availability requirements.
