Monday, June 22, 2020

Building User Registration Form With Reactive Forms in Angular 7

Building User Registration Form With Reactive Forms in Angular 7

In this tutorial, you'll learn how to handle Angular web app forms using Reactive Forms. From the official documentation,

Reactive forms use an explicit and immutable approach to managing the state of a form at a given point in time. Each change to the form state returns a new state, which maintains the integrity of the model between changes.

Reactive forms use a model driven approach to handle form input values. Let's see how to use Reactive forms in Angular.

The source code from this tutorial is available on GitHub.

Creating a User Registration UI Using Reactive Forms

Let's start by creating an Angular app from scratch and see how you can use Reactive forms in Angular 7.

Assuming that you have already installed the Angular CLI in your system, let's create an Angular app using the Angular CLI command.

ng new form-app

The above command creates an Angular project with some boilerplate code. Let's have a look at the boilerplate code.

Inside your form-app/src/app folder, you'll find the default AppComponent. Let's remove the default component from the project. Remove all files from the app folder except the app.module.ts file.

Once you have removed the default component, let's create a root component for the Angular app.

ng generate component root

Update the app.module.ts file to remove the AppComponent and update the bootstrap property in NgModule to RootComponent.

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { ReactiveFormsModule } from '@angular/forms';

import { RootComponent } from './root/root.component';

@NgModule({
  declarations: [
    RootComponent
  ],
  imports: [
    BrowserModule,
    ReactiveFormsModule
  ],
  providers: [],
  bootstrap: [RootComponent]
})
export class AppModule { }

Save the above changes and try running the Angular app.

npm start

You'll be able to see the default app running.

Let's start creating the form UI. You'll be making use of the FormBuilder to create a Reactive form. Inside the RootComponent class, import the FormBuilder module.

import { FormBuilder } from '@angular/forms';

Instantiate the FormBuilder module inside the RootComponent constructor.

constructor(private formBuilder: FormBuilder) { }

Using the FormBuilder module, create a form group which will define the fields in the form.

ngOnInit() {
    this.userForm = this.formBuilder.group({
      firstName: [''],
      lastName: [''],
      email: [''],
      password: [''],
    });
  }

Once you have defined the form builder group, set up the RootComponent form with the form group userForm. Add formGroup directive to the form inside root.component.html file.

<form [formGroup]="userForm" class="text-center border border-light p-5">

    <p class="h4 mb-4">Sign up</p>

    <div class="form-row mb-4">
        <div class="col">
            <input type="text" id="defaultRegisterFormFirstName" class="form-control" placeholder="First name">
        </div>
        <div class="col">
            <input type="text" id="defaultRegisterFormLastName" class="form-control" placeholder="Last name">
        </div>
    </div>

    <input type="email" id="defaultRegisterFormEmail" class="form-control mb-4" placeholder="E-mail">
  
    <button class="btn btn-info my-4 btn-block" type="submit">Sign in</button>

    <hr>

</form>

Add the formControlName to each element in the form as in the userGroup.

<form [formGroup]="userForm" (ngSubmit)="onSubmit()" class="text-center border border-light p-5">

  <p class="h4 mb-4">Sign up</p>

  <div class="form-row mb-4">
      <div class="col">
          <input type="text" formControlName="firstName" id="defaultRegisterFormFirstName" class="form-control" placeholder="First name">
      </div>
      <div class="col">
          <input type="text" formControlName="lastName" id="defaultRegisterFormLastName" class="form-control" placeholder="Last name">
      </div>
  </div>

  <input type="email" formControlName="email" id="defaultRegisterFormEmail" class="form-control mb-4" placeholder="E-mail">

  <button class="btn btn-info my-4 btn-block" type="submit">Sign in</button>

  <hr>

</form>

Save the above changes and point your browser to http://localhost:4200/. You will be able to see the user form.

Validating The User Registration Form Fields In Reactive Forms

You can validate the form using the Validators module. Import the Validators module inside the RootComponent.

import { FormBuilder, Validators } from '@angular/forms';

While initializing the form group elements, you can set validation for each of the fields using the validators module. For setting up a required field validation, you can use Validators.required as shown:

    this.userForm = this.formBuilder.group({
      firstName: ['', [Validators.required]],
      lastName: ['',[Validators.required]],
      email: ['', [Validators.required]]
    });

Let's set a submit button method on the user form. Add (ngSubmit)="onSubmit()" on the root.component.html file. Add the onSubmit method inside the RootComponent class.

  onSubmit(){
    if(this.userForm.valid){
      alert('User form is valid!!')
    } else {
      alert('User form is not valid!!')
    }
  }

To check if the userForm field is validated, you can use userForm.valid as shown in the onSubmit method.

Save the above changes and click the form with empty fields. You will get an alert saying User form is not valid.

Similarly, you can add custom validation based on regular expression patterns to the form fields. Let's add a pattern to allow only strings in the first name and last name field and email in the email field.
Add the validators to the user form group in the root.component.ts file.

ngOnInit() {
    this.userForm = this.formBuilder.group({
      firstName: ['', [Validators.required, Validators.pattern('^[a-zA-Z]+$')]],
      lastName: ['',[Validators.required, Validators.pattern('^[a-zA-Z]+$')]],
      email: ['', [Validators.required, Validators.email]]
    });
  }

Save the above changes and try to submit the form with numeric values in the first name or last name. You will be able to see an alert message saying that the values are not valid.

Protect your Angular App with Jscrambler

Submitting The Reactive Form

For submitting the reactive form, you'll need a REST endpoint to POST the form. So, first, you'll be creating a simple Express REST API endpoint returning the posted form values.

Creating The REST Endpoint

Let's get started by creating a Node Express server with a REST endpoint. Create a project folder called node-app. Navigate to the project folder and initialize the Node project.

mkdir node-app
cd node-app
npm init

You now have a Node project created in the node-app folder. You'll be using the Express framework for creating the REST API. Start by installing Express using npm.

npm install --save express

The command above installs the express framework to your Node project and also saves the dependency in the package.json file.

Create a file called app.js which will act as the root file of the server. Require the Express module inside the app.js file and create an Express app.

const express = require('express')
const app = express()

Using Express, create a route which will act as a REST API endpoint.

app.post('/api/userCreate', (req, res) => {
    res.json({
        data: req.body
    })
})

The route defined above returns the request parameters posted to the REST API endpoint URL.
You need to bind the Express app to a port address to run the server. So, here is how the app.js file looks:

const express = require('express')
const app = express()
const port = 3000

app.post('/api/userCreate', (req, res) => {
    res.json({
        data: req.body
    })
})

app.listen(port, () => console.log(`Server listening on port ${port}!`))

For parsing the form request body parameters, you'll need to use a module called body-parser. Install the body-parser and include it inside your Express app.

npm install --save body-parser

After adding body-parser to your Express app, here is how the app.js file looks:

const express = require('express')
const bodyParser = require('body-parser')

const app = express()
app.use(bodyParser.urlencoded({ extended: false }))
app.use(bodyParser.json())
const port = 3000

app.post('/api/userCreate', (req, res) => {
    res.json({
        data: req.body
    })
})

app.listen(port, () => console.log(`Server listening on port ${port}!`))

Save the above changes and start the Express app server using Node.

node app.js

You'll be having the REST API endpoint running at http://localhost:3000.

Posting The Form

Once you have a REST API endpoint to make a POST request, let's see how to POST our reactive form to the API.

You need to add a proxy configuration to the Angular app to redirect the API calls request to the Express REST API endpoint. Inside the Angular project folder form-app, add a proxy config file called proxy.conf.json. Here is how it looks:

{
    "/api/*": {
      "target": "http://localhost:3000",
      "changeOrigin": true
    }
  }

The above defined proxy redirects all the /api calls to the application running at http://localhost:3000.

Inside the RootComponent, import the HttpClient to make the API calls.

import { HttpClient } from '@angular/common/http';

Initialize the HttpClient inside the RootComponent constructor method.

constructor(private formBuilder: FormBuilder, private http: HttpClient) { }

Inside the onSubmit method, when the form is valid, you can use the HttpClient to make the POST request to the API endpoint.

  onSubmit(){
    if(this.userForm.valid){
      this.http.post('/api/userCreate', this.userForm.value)
      .subscribe((response)=>{
        console.log('repsonse ',response);
      })
    }
  }

Save the above changes and submit the user form with the valid details filled. You will be able to see the response returned from the REST API endpoint in the browser console.

Conclusion

In this tutorial, you learned how to use Reactive Forms to create a user form in an Angular app. You also saw how to post the reactive form to a REST API endpoint. Hopefully, this will be useful for your current or future Angular web apps.

Join our upcoming webinar on "Securing Enterprise JavaScript Applications"! June 25th at 6 pm BST / 1 pm EDT / 10 am PDT. Simply fill the form below:

Share this Blog Post

Saturday, June 20, 2020

Microservice Architecture (Examples and Diagram)


A graph depicting examples of microservice architecture

Introduction

It certainly makes sense to evaluate the “Microservice Architecture” with examples and diagrams since it has become an important pattern.

You must consider application architecture when designing your application. Why should you do so? Well, over the years, many different software development paradigms have come and gone. A constant theme, however, has been the need to componentize software systems in a modular way.

You gain many benefits if you modularize software systems. You will find it easier to understand and follow the source code, and programmers can easily visualize the codebase. Modularizing also helps developers to know where they should look for defects. As a result, you can maintain your software with relative ease.

If you architect software systems well, then they scale better. This helps immensely when you have more users for your application.

You can also manage your development process better if you architect the software well. New developers can easily learn such a system, therefore, they become productive quickly. A well-architected software also follows the application coding standards. This further improves your productivity.

There are many approaches to architecting software projects such as N-Tiered, Service Oriented Architecture (SOA) or Microservice Architecture to name a few.  In this post, however, aimed at software developers, development managers and CTO’s we specifically look at Microservice Architecture and cover the following topics:

By the time you’ve read this blog post you’ll have a solid understanding of what microservice architecture is, its benefits, if you should consider it and how to go about structuring an application to adopt this architectural paradigm, so let’s get started!

What is Microservice Architecture?

A diagram depicting Microservice architecture

In the past decades, applications have been developed in a monolith fashion, coded from top to bottom as one single unit, sometimes with no real structure or thought for future maintenance which can cause a range of problems.  Poorly architected software solutions can also be problematic to debug or extend with new features and in general, aren’t very nice to work on.

Microservice architecture is a form of service-oriented architecture (SOA) whereby software applications are built as a collection of loosely coupled services, as opposed to one monolithic software application.  Each microservice can be created independently from the other, or even in a completely different programming language and run on their own.

At the core of it all, each microservice tries to satisfy the specific user story or business requirement that you’re working on.  It is an ideal architectural design pattern in today’s ever increasing interconnected world and helps support multiple platforms and devices that can span the cloud, mobile, Internet of Things (IoT) and even wearable devices.

A popular way to implement microservices is to use protocols such as HTTP/REST alongside JSON, as an architectural design pattern, we’re seeing a lot of the main SaaS providers adopt microservices into their solutions and services.

From Microsoft to IBM and much more, software vendors and service providers are implementing the microservice architecture.  Major players like Twitter, Netflix, eBay, and Amazon have also favored microservice architecture as it helps with the development, scalability and continuous delivery of their services.  This brings us to some of the benefits of microservices architecture.

Benefits of Microservice Architecture

An infographic explaining the difference between the Microservices approach and the traditional approach

As an architectural practice, microservice architecture has been growing in popularity in recent years, this is down the benefits that it can bring software development teams and the enterprise.  As software increased in complexity, being able to componentize functional areas in the application into sets of independent (micro) services can yield many benefits, which include, but are not limited to the following:

  • More efficient debugging – no more jumping through multiple layers of an application, in essence, better fault isolation
  • Accelerated software delivery – multiple programming languages can be used thereby giving you access to a wider developer talent pool
  • Easier to understand the codebase – increased productivity as each service represents a single functional area or business use case
  • Scalability – componentized microservices naturally lend themselves to being integrated with other applications or services via industry-standard interfaces such as REST.
  • Fault tolerance – reduced downtime due to more resilient services
  • Reusability – as microservice are organized around business cases and not a particular project, due to their implementation, they can be reused and easily slotted into other projects or services, thereby reducing costs.
  • Deployment – as everything is encapsulated into separate microservices, you only need to deploy the services that you’ve changed and not the entire application.  A key tenet of microservice development is ensuring that each service is loosely coupled with existing services.

But don’t just take our word for it, here are some real-world examples of microservices in action how this architectural design pattern as benefited Walmart and Amazon.

Microservice Architecture in Action in the Real World

A graph depicting a typical microservice architecture on AWS

Here we explore how adopting microservice as a software architecture could add real business value and bring a whole range of benefits for Amazon and Walmart.

MICROSERVICES RESCUE WALMART’S AGING SOFTWARE ARCHITECTURE

The Canadian arm of retail giant Walmart has serious issues with their existing software architecture, especially around Black Friday – for two consecutive years.  At its peak, the Walmart site couldn’t handle 6 million page views per minute and ultimately made it practically impossible for visitors to have any positive sort of user experience.

Part of the problem was that Walmart’s software architecture was design for the internet of 2005 which was centered around desktops and laptops.  The use of mobile, smart and IoT devices hadn’t fully peaked back then.  The firm decided to re-platform its legacy system in 2012 using microservices and have set a target that by 2020 to be able to service 4 billion connections!

By migrating to a microservices architecture, Walmart identified that:

  • Mobile orders increased by 98% –
  • Zero downtime on Black Friday and Boxing Day (Canadas Black Friday)
  • Conversions increased by 20%

AMAZON

Amazon the retail and now logistics giant is no stranger to delivering software at scale.  Rob Birgham, senior AWS Product Manager shared a story of how microservice architecture was used in conjunction with DevOps.

Back in the early 2000’s Amazon’s site was developed as one, big, monoliths solution and to be fair, a lot of business started out that way.  Over time, however, as functional areas were built, from multiple teams of developers or bugs were fixed, not to mention, as the platform grew, the job of integrating all this work started to impact on overall productivity.

Days or sometimes whole weeks were dedicated to merging developer changes into a master version of the product, merge conflicts had to be resolved which again, all had an impact on productivity.

Realising quickly that operating like this wasn’t sustainable, Amazon took the decision to decouple their monolith codebase by adopting a microservice architecture.  Each service was responsible for a single purpose as was accessible through web service APIs.

Once this exercise was complete, this paved the way for Amazon to create a highly decouple architecture where each service could operate independently – providing each developer adhered to the respective web service interface definitions.

NETFLIX

Netflix uses the Microservice architecture pattern to great effects. The company had a monolithic architecture and its datacentre aligned with it.

In 2008, Netflix was still using its monolithic architecture. A program had a missing semicolon, and the effect of that was substantial. This single bug brought down the Netflix website, and it took several hours to recover from it.

That’s not surprising given the monolithic architecture has various components coupled together tightly. One error in one component can significantly impact the entire software. Naturally, Netflix needed its engineers from all areas to take part in troubleshooting when something went wrong.

Around the same time, Netflix noticed how they were finding it hard to scale. The popularity of Netflix was growing, however, the company wasn’t able to build data centers fast enough. This limitation had started to hamper its growth.

Netflix started to transition from its monolithic architecture in 2009. We in the development community weren’t even using the term “microservice” at that time, however, Netflix took the plunge!

The company began its transition to AWS cloud-based microservice architecture. In the beginning, Netflix moved an application that wasn’t a customer-facing one. This was a smart decision since the company needed to contain the impacts if anything was to go wrong with the move. The first to move was the movie encoding application, and the move was successful.

Subsequently, Netflix started to move various customer-facing functions to AWS. This included its functions like account sign-up, movie selections, TV selections, etc. The company achieved success with these too.

Netflix completed its move to the microservice architecture by December 2011. With this move, Netflix now had hundreds of microservices instead of a giant monolith application that they had earlier.

As of December 2015, the Netflix microservice architecture featured an API gateway that handled 2 billion API requests daily. You can read about this transition in “Why you can’t talk about microservices without mentioning Netflix”.

Challenges of Microservice Architecture

An infographic discussing the challenges of microservice architecture

As with every new software programming architecture, each has the list of pros and cons, it’s not always peaches and cream and microservices aren’t an exception to this rule and it’s worth pointing some of these out.

  • Too many coding languages – yes, we listed this as a benefit, but it can also be a double-edged sword.  Too many alternative languages, in the end, could make your solution unwieldy and potentially difficult to maintain.
  • Integration – you need to make a conscious effort to ensure your services as are loosely couple as they possibly can be, otherwise, if you don’t, you’ll make a change to one service which has a ripple effect with additional services thereby making service integration difficult and time-consuming.
  • Integration test – testing one monolithic system can be simpler as everything is in “one solution”, whereas a solution based on microservices architecture may have components that live on other systems and/or environments thereby making it harder to configure and “end to end” test environment.
  • Communication – microservices naturally need to interact with other services, each service will depend on a specific set of inputs and return specific outputs, these communication channel’s need to be defined into specific interfaces and shared with your team.  Failures between microservices can occur when interface definitions haven’t been adhered to which can result in lost time.

So now that we’ve talked about what microservice architecture is, what some of its benefits are and look at a few examples of microservice architecture in the real-world as well as the benefits of this paradigm, you might be wondering if microservices architecture is for you or your software project and it’s a valid question to ask.

Should You Adopt Microservice Architecture?

image005

You don’t want to implement a microservice architecture in your project just for the sake of it, so we’ve put together some points to consider that will help you decide if that’s architectural pattern is right for you or your project.

If you answer yes to any of these questions, then you might want to consider implementing a microservice bases architecture:

  • Is your current application monolith and difficult to maintain?
  • Do you anticipate that your application will have to deal with high volumes of traffic?
  • Is modularisation and code reusability the main priority?
  • Does your application need to be accessed on multiple device types such as mobile, IoT and web?
  • Do specific areas your application need to be able to scale -on demand?
  • Are you looking to improve your software products build and release process?

If you answer yes to most of these, however, you can probably get away with a traditional monolithic application architecture:

  • Do just need to ship and MVP, to test the market?
  • Do already have a stable product/team that will continue to work on the product until you retire it?
  • Is your product “in the wild”, generating revenue and the user community is happy? If so, no sense in reinventing the wheel

Sample Microservice Architecture

A diagram showing examples of microservice architecture

Now that we’ve introduced the microservice architecture, discussed some of the benefits, respective challenges and looked a few examples of how microservices have been deployed in the real world, it’s time to look at a basic microservice in terms of its architecture and how it can be designed.  In the image above, you can see the following 3 microservices:

  • Account Service
  • Inventory Service
  • Shipping Service

As this microservices architecture diagram shows, each microservice is accessed in one of two ways in this fictitious application:

  • From an API gateway (via a mobile app)
  • From a Web application (via the user’s web browser)

Note: There could be theoretically may be more as the architecture lends itself to that.

You can see that each microservice also exposes a dedicated REST API, this is the interface which defines the operations that can be executed against the respective microservices and will detail the data structures, data types, or POCOSs that can be passed into the microservice as well as its return types.  For example, the Inventory service REST API definition may contain an endpoint called GetAllProducts which allows consumers of the microservice to fetch all products in the e-commerce store, this could return a list of Product objects is JSON, XML or even C# POCO.

As each microservice has its own set of responsibilities and can only ever interact with its respective database, a solution architected like this makes it easier for more than one developer to make changes to the system.  By implementing a microservice like the one we’ve just detailed, you will gain some of the benefits that we outlined earlier. As you roll out an architecture using this approach, it’s important to ensure that each microservices architecture example can operate completely independently, otherwise, it defeats the purpose of pursuing this architectural approach.

Best practices you should consider when implementing the microservice architecture

How would you implement the microservice architecture effectively? I recommend that you seriously consider the following best practices:

  • Determine if this architecture pattern works for you.
  • Define your microservices carefully.
  • When you design your microservices, use “Domain-Driven Design” (DDD).
  • Get buy-in from the senior leadership in your organization since a transition to the microservice architecture can be hard.
  • Use RESTful APIs since they can help you to implement this architecture pattern. Remember to design your APIs based on their domain, and document the APIs well.
  • Organize your team around your microservices.
  • Plan for separate data storage for each microservice.
  • Invest in high-quality DevOps and application monitoring solutions.

Wondering how you can learn more about these best practices? Our guide “10 best practices for building a microservice architecture” is just what you need!

Summary

So, there you have it, an overview of Microservices architecture.  In this blog post, we’ve looked at microservices architecture, we covered the key concepts, the benefits this architectural design pattern can bring to the enterprise and how it can help software development professionals better structure their products.

We’ve also outlined the main components of an application that adopts a microservice architectural pattern and give you some ideas as to why you might want to introduce microservices to your project. In case you do, it’s best to hire expert developers capable of building an exceptional product. Feel free to comment or share this article with your friends or colleagues, or if you have a comment then leave one below!

Free hosting web sites and features -2024

  Interesting  summary about hosting and their offers. I still host my web site https://talash.azurewebsites.net with zero cost on Azure as ...