WTF is Vuex? A Beginner's Guide To Vuex 4

Vuex is an essential tool in the Vue.js ecosystem. But developers new to Vuex may be repelled by jargon terms like “state management pattern” and confused as to what they actually need it for.

Here’s the primer on Vuex that I wish I’d had when I started learning. In it, I’ll cover the high-level concepts of Vuex and show you how to use Vuex in an app.

Table of contents:

  • Vuex
  • The problem that Vuex solves
  • Flux
  • Principle #1: single source of truth
  • Principle #2: data is read-only
  • Principle #3: mutations are synchronous
  • Cool, so what exactly is Vuex?
  • Setting up a Vuex to-do app
  • Installing Vuex
  • Creating a Vuex store
  • Adding the store to a Vue instance
  • Creating a simple app
  • Defining store state
  • Defining mutations
  • Using mutations i.e. “commits”
  • Reading store data
  • Defining getters
  • Do you actually need Vuex?

Vuex

Vuex. Is it pronounced “vewks”, or “veweks”? Or maybe it’s meant to be “vew”, pronounced with a French-style silent “x”?

My trouble with understanding Vuex only began with the name.

Being an eager Vue developer I’d heard enough about Vuex to suspect that it must be an important part of the Vue ecosystem, even if I didn’t know what it actually was.

I eventually had enough of wondering, so I went to the documentation with plans of a brief skim through; just enough to get the idea.

To my chagrin, I was greeted with unfamiliar terms like “state management pattern”, “global singleton” and “source of truth”. These terms may make sense to anyone already familiar with the concept, but for me, they didn’t gel at all.

The one thing I did get, though, was that Vuex had something to do with Flux and Redux. I didn’t know what those were either, but I figured it may help if I investigated them first.

After a bit of research and persistence, the concepts behind the jargon finally started to materialize in my mind. I was getting it. I went back to the Vuex documentation and it finally hit me…Vuex is freaking awesome!

I’m still not quite sure how to pronounce it, but Vuex has become an essential piece in my Vue.js toolbelt. I think it’s totally worth your time to check it out too, so I’ve written this primer on Vuex to give you the background that I wish I’d had.

The problem that Vuex solves

To understand Vuex it’s much easier if you first understand the problem that it’s designed to solve.

Imagine you’ve developed a multi-user chat app. The interface has a user list, private chat windows, an inbox with chat history, and a notification bar to inform users of unread messages from other users they aren’t currently viewing.

Millions of users are chatting to millions of other users through your app daily. However, there are complaints about an annoying problem: the notification bar will occasionally give false notifications. A user will be notified of a new unread message, but when they check to see what it is it’s just a message they’ve already seen.

What I’ve described is a real scenario that the Facebook developers had with their chat system a few years back. The process of solving this inspired their developers to create an application architecture they named “Flux”. Flux forms the basis of Vuex, Redux, and other similar libraries.

Flux

Facebook developers struggled with the “zombie notification” bug for some time. They eventually realized that its persistent nature was more than a simple bug - it pointed to some underlying flaw in the architecture of the app.

The flaw is most easily understood in the abstract: when you have multiple components in an application that share data, the complexity of their interconnections will increase to a point where the state of the data is no longer predictable or understandable. Consequentially the app becomes impossible to extend or maintain.

The idea of Flux was to create a set of guiding principles that describe a scalable frontend architecture that sufficiently mitigates this flaw. Not just for a chat app, but in any complex UI app with components and shared data state.

Flux is a pattern, not a library. You can’t go to Github and download Flux. It’s a design pattern like MVC. Libraries like Vuex and Redux implement the Flux pattern the same way that other frameworks implement the MVC pattern.

In fact, Vuex doesn’t implement all of Flux, just a subset. Don’t worry about that just now though, let’s instead focus on understanding the key principles that it does observe.

Principle #1: single source of truth

Components may have local data that only they need to know about. For example, the position of the scroll bar in the user list component is probably of no interest to other components.

But any data that is to be shared between components, i.e. application data, needs to be kept in a single place, separate from the components that use it.

This single location is called the “store”. Components must read application data from this location and not keep their own copy to prevent conflict or disagreement.

import { createStore } from "vuex";

// Instantiate our Vuex store
const store = createStore({

  // "State" is the application data your components
  // will subscribe to

  state () {
    return {
      myValue: 0
    };
  }
});

// Components access state from their computed properties
const MyComponent = {   
  template: "<div>{{ myValue }}</div>",
  computed: {
    myValue () {
      return store.state.myValue;
    }   
  } 
};

Principle #2: data is read-only

Components can freely read data from the store. But they cannot change data in the store, at least not directly.

Instead, they must inform the store of their intent to change the data and the store will be responsible for making those changes via a set of defined functions called “mutations”.

Why this approach? If we centralize the data-altering logic than we don’t have to look far if there are inconsistencies in the state. We’re minimizing the possibility that some random component (possibly in a third-party module) has changed the data in an unexpected fashion.

const store = createStore({ 
  state() { 
    return {
      myValue: 0
    };
  }, 
  mutations: { 
    increment (state, value) { 
      state.myValue += value;
    }
  } 
});
// Need to update a value?
// Wrong! Don't directly change a store value.
store.myValue += 10;
// Right! Call the appropriate mutation.
store.commit('increment', 10);

Principle #3: mutations are synchronous

It’s much easier to debug data inconsistencies in an app that implements the above two principles in its architecture. You could log commits and observe how the state changes in response (which you can indeed do when using Vuex with Vue Devtools).

But this ability would be undermined if our mutations were applied asynchronously. We’d know the order our commits came in, but we would not know the order in which our components committed them.

Synchronous mutations ensure state is not dependent on the sequence and timing of unpredictable events.

#vuex #vue #javascript #programming #web-development

What is GEEK

Buddha Community

WTF is Vuex? A Beginner's Guide To Vuex 4

WTF is Vuex? A Beginner's Guide To Vuex 4

Vuex is an essential tool in the Vue.js ecosystem. But developers new to Vuex may be repelled by jargon terms like “state management pattern” and confused as to what they actually need it for.

Here’s the primer on Vuex that I wish I’d had when I started learning. In it, I’ll cover the high-level concepts of Vuex and show you how to use Vuex in an app.

Table of contents:

  • Vuex
  • The problem that Vuex solves
  • Flux
  • Principle #1: single source of truth
  • Principle #2: data is read-only
  • Principle #3: mutations are synchronous
  • Cool, so what exactly is Vuex?
  • Setting up a Vuex to-do app
  • Installing Vuex
  • Creating a Vuex store
  • Adding the store to a Vue instance
  • Creating a simple app
  • Defining store state
  • Defining mutations
  • Using mutations i.e. “commits”
  • Reading store data
  • Defining getters
  • Do you actually need Vuex?

Vuex

Vuex. Is it pronounced “vewks”, or “veweks”? Or maybe it’s meant to be “vew”, pronounced with a French-style silent “x”?

My trouble with understanding Vuex only began with the name.

Being an eager Vue developer I’d heard enough about Vuex to suspect that it must be an important part of the Vue ecosystem, even if I didn’t know what it actually was.

I eventually had enough of wondering, so I went to the documentation with plans of a brief skim through; just enough to get the idea.

To my chagrin, I was greeted with unfamiliar terms like “state management pattern”, “global singleton” and “source of truth”. These terms may make sense to anyone already familiar with the concept, but for me, they didn’t gel at all.

The one thing I did get, though, was that Vuex had something to do with Flux and Redux. I didn’t know what those were either, but I figured it may help if I investigated them first.

After a bit of research and persistence, the concepts behind the jargon finally started to materialize in my mind. I was getting it. I went back to the Vuex documentation and it finally hit me…Vuex is freaking awesome!

I’m still not quite sure how to pronounce it, but Vuex has become an essential piece in my Vue.js toolbelt. I think it’s totally worth your time to check it out too, so I’ve written this primer on Vuex to give you the background that I wish I’d had.

The problem that Vuex solves

To understand Vuex it’s much easier if you first understand the problem that it’s designed to solve.

Imagine you’ve developed a multi-user chat app. The interface has a user list, private chat windows, an inbox with chat history, and a notification bar to inform users of unread messages from other users they aren’t currently viewing.

Millions of users are chatting to millions of other users through your app daily. However, there are complaints about an annoying problem: the notification bar will occasionally give false notifications. A user will be notified of a new unread message, but when they check to see what it is it’s just a message they’ve already seen.

What I’ve described is a real scenario that the Facebook developers had with their chat system a few years back. The process of solving this inspired their developers to create an application architecture they named “Flux”. Flux forms the basis of Vuex, Redux, and other similar libraries.

Flux

Facebook developers struggled with the “zombie notification” bug for some time. They eventually realized that its persistent nature was more than a simple bug - it pointed to some underlying flaw in the architecture of the app.

The flaw is most easily understood in the abstract: when you have multiple components in an application that share data, the complexity of their interconnections will increase to a point where the state of the data is no longer predictable or understandable. Consequentially the app becomes impossible to extend or maintain.

The idea of Flux was to create a set of guiding principles that describe a scalable frontend architecture that sufficiently mitigates this flaw. Not just for a chat app, but in any complex UI app with components and shared data state.

Flux is a pattern, not a library. You can’t go to Github and download Flux. It’s a design pattern like MVC. Libraries like Vuex and Redux implement the Flux pattern the same way that other frameworks implement the MVC pattern.

In fact, Vuex doesn’t implement all of Flux, just a subset. Don’t worry about that just now though, let’s instead focus on understanding the key principles that it does observe.

Principle #1: single source of truth

Components may have local data that only they need to know about. For example, the position of the scroll bar in the user list component is probably of no interest to other components.

But any data that is to be shared between components, i.e. application data, needs to be kept in a single place, separate from the components that use it.

This single location is called the “store”. Components must read application data from this location and not keep their own copy to prevent conflict or disagreement.

import { createStore } from "vuex";

// Instantiate our Vuex store
const store = createStore({

  // "State" is the application data your components
  // will subscribe to

  state () {
    return {
      myValue: 0
    };
  }
});

// Components access state from their computed properties
const MyComponent = {   
  template: "<div>{{ myValue }}</div>",
  computed: {
    myValue () {
      return store.state.myValue;
    }   
  } 
};

Principle #2: data is read-only

Components can freely read data from the store. But they cannot change data in the store, at least not directly.

Instead, they must inform the store of their intent to change the data and the store will be responsible for making those changes via a set of defined functions called “mutations”.

Why this approach? If we centralize the data-altering logic than we don’t have to look far if there are inconsistencies in the state. We’re minimizing the possibility that some random component (possibly in a third-party module) has changed the data in an unexpected fashion.

const store = createStore({ 
  state() { 
    return {
      myValue: 0
    };
  }, 
  mutations: { 
    increment (state, value) { 
      state.myValue += value;
    }
  } 
});
// Need to update a value?
// Wrong! Don't directly change a store value.
store.myValue += 10;
// Right! Call the appropriate mutation.
store.commit('increment', 10);

Principle #3: mutations are synchronous

It’s much easier to debug data inconsistencies in an app that implements the above two principles in its architecture. You could log commits and observe how the state changes in response (which you can indeed do when using Vuex with Vue Devtools).

But this ability would be undermined if our mutations were applied asynchronously. We’d know the order our commits came in, but we would not know the order in which our components committed them.

Synchronous mutations ensure state is not dependent on the sequence and timing of unpredictable events.

#vuex #vue #javascript #programming #web-development

Monty  Boehm

Monty Boehm

1640622240

Automatically Tag A Branch with The Next Semantic Version Tag

Auto-Tag

PyPI PyPI - Implementation PyPI - Python Version codecov PyPI - License

Automatically tag a branch with the next semantic version tag.

This is useful if you want to generate tags every time something is merged. Microservice and GitOps repository are good candidates for this type of action.

TOC

How to install

~ $ pip install auto-tag

To see if it works, you can try

~ $ auto-tag  -h
usage: auto-tag [-h] [-b BRANCH] [-r REPO]
                [-u [UPSTREAM_REMOTE [UPSTREAM_REMOTE ...]]]
                [-l {CRITICAL,FATAL,ERROR,WARN,WARNING,INFO,DEBUG,NOTSET}]
                [--name NAME] [--email EMAIL] [-c CONFIG]
                [--skip-tag-if-one-already-present] [--append-v-to-tag]
                [--tag-search-strategy {biggest-tag-in-repo,biggest-tag-in-branch,latest-tag-in-repo,latest-tag-in-branch}]

.....

How it Works

The flow is as follows:

  • figure our repository based on the argument
  • load detectors from file if specified (-c option), if none specified load default ones (see Detectors)
  • check for the last tag (depending on the search strategy see Search Strategy
  • look at all commits done after that tag on a specific branch (or from the start of the repository if no tag is found)
  • apply the detector (see Detectors) on each commit and save the highest change detected (PATH, MINOR, MAJOR)
  • bump the last tag with the approbate change and apply it using the default git author in the system or a specific one (see Git Author)
  • if an upstream was specified push the tag to that upstream

Examples

Here we can see in commit 2245d5d that it stats with feature( so the latest know tag (0.2.1) was bumped to 0.3.0

~ $ git log --oneline
2245d5d (HEAD -> master) feature(component) commit #4
939322f commit #3
9ef3be6 (tag: 0.2.1) commit #2
0ee81b0 commit #1
~ $ auto-tag
2019-08-31 14:10:24,626: Start tagging <git.Repo "/Users/matei/git/test-auto-tag-branch/.git">
2019-08-31 14:10:24,649: Bumping tag 0.2.1 -> 0.3.0
2019-08-31 14:10:24,658: No push remote was specified
~ $ git log --oneline
2245d5d (HEAD -> master, tag: 0.3.0) feature(component) commit #4
939322f commit #3
9ef3be6 (tag: 0.2.1) commit #2
0ee81b0 commit #1

In this example we can see 2245d5deb5d97d288b7926be62d051b7eed35c98 introducing a feature that will trigger a MINOR change but we can also see 0de444695e3208b74d0b3ed7fd20fd0be4b2992e having a BREAKING_CHANGE that will introduce a MAJOR bump, this is the reason the tag moved from 0.2.1 to 1.0.0

~ $ git log
commit 0de444695e3208b74d0b3ed7fd20fd0be4b2992e (HEAD -> master)
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 21:58:01 2019 +0300

    fix(something) ....

    BREAKING_CHANGE: this must trigger major version bump

commit 65bf4b17669ea52f84fd1dfa4e4feadbc299a80e
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 21:57:47 2019 +0300

    fix(something) ....

commit 2245d5deb5d97d288b7926be62d051b7eed35c98
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:52:10 2019 +0300

    feature(component) commit #4

commit 939322f1efaa1c07b7ed33f2923526f327975cfc
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:51:24 2019 +0300

    commit #3

commit 9ef3be64c803d7d8d3b80596485eac18e80cb89d (tag: 0.2.1)
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:51:18 2019 +0300

    commit #2

commit 0ee81b0bed209941720ee602f76341bcb115b87d
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:50:25 2019 +0300

    commit #1
~ $ auto-tag
2019-08-31 14:10:24,626: Start tagging <git.Repo "/Users/matei/git/test-auto-tag-branch/.git">
2019-08-31 14:10:24,649: Bumping tag 0.2.1 -> 1.0.0
2019-08-31 14:10:24,658: No push remote was specified
~ $ git log
commit 0de444695e3208b74d0b3ed7fd20fd0be4b2992e (HEAD -> master, tag: 1.0.0)
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 21:58:01 2019 +0300

    fix(something) ....

    BREAKING_CHANGE: this must trigger major version bump

commit 65bf4b17669ea52f84fd1dfa4e4feadbc299a80e
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 21:57:47 2019 +0300

    fix(something) ....

commit 2245d5deb5d97d288b7926be62d051b7eed35c98
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:52:10 2019 +0300

    feature(component) commit #4

commit 939322f1efaa1c07b7ed33f2923526f327975cfc
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:51:24 2019 +0300

    commit #3

commit 9ef3be64c803d7d8d3b80596485eac18e80cb89d (tag: 0.2.1)
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:51:18 2019 +0300

    commit #2

commit 0ee81b0bed209941720ee602f76341bcb115b87d
Author: Matei-Marius Micu <micumatei@gmail.com>
Date:   Fri Aug 30 19:50:25 2019 +0300

    commit #1

Detectors

If you want to detect what commit enforces a specific tag bump(PATH, MINOR, MAJOR) you can configure detectors. They are configured in a yaml file that looks like this:

detectors:

  check_for_feature_heading:
    type: CommitMessageHeadStartsWithDetector
    produce_type_change: MINOR
    params:
      pattern: 'feature'


  check_for_breaking_change:
    type: CommitMessageContainsDetector
    produce_type_change: MAJOR
    params:
      pattern: 'BREAKING_CHANGE'
      case_sensitive: false

Here is the default configuration for detectors if none is specified. We can see we have two detectors check_for_feature_heading and check_for_breaking_change, with a type, what change they will trigger and specific parameters for each one. This configuration will do the following:

  • if the commit message starts with feature( a MINOR change will BE triggered
  • if the commit has BREAKIN_CHANGE in the message a MAJOR change will be triggered The bump on the tag will be based on the higher priority found.

The type and produce_type_change parameters are required params is specific to every detector.

To pass the file to the process just use the -c CLI parameter.

Currently we support the following triggers:

  • CommitMessageHeadStartsWithDetector
    • Parameters:
      • case_sensitive of type bool, if the comparison is case sensitive
      • strip of type bool, if we strip the spaces from the commit message
      • pattern of type string, what pattern is searched at the start of the commit message
  • CommitMessageContainsDetector
    • case_sensitive of type bool, if the comparison is case sensitive
    • strip of type bool, if we strip the spaces from the commit message
    • pattern of type string, what pattern is searched in the body of the commit message
  • CommitMessageMatchesRegexDetector
    • strip of type bool, if we strip the spaces from the commit message
    • pattern of type string, what regex pattern to match against the commit message

The regex detector is the most powerful one.

Git Author

When creating and tag we need to specify a git author, if a global one is not set (or if we want to make this one with a specific user), we have the option to specify one. The following options will add a temporary config to this repository(local config). After the tag was created it will restore the existing config (if any was present)

  --name NAME           User name used for creating git objects.If not
                        specified the system one will be used.
  --email EMAIL         Email name used for creating git objects.If not
                        specified the system one will be used.

If another user interacts with git while this process is taking place it will use the temporary config, but we assume we are run in a CI pipeline and this is the only process interacting with git.

Search Strategy

If you want to bump a tag first you need to find the last one, we have a few implementations to search for the last tag that can be configured with --tag-search-strategy CLI option.

  • biggest-tag-in-repo consider all tags in the repository as semantic versions and pick the biggest one
  • biggest-tag-in-branch consider all tags on the specified branch as semantic versions and pick the biggest one
  • latest-tag-in-repo compare commit date for each commit that has a tag in the repository and take the latest
  • latest-tag-in-branch compare commit date for each commit that has a tag one the specifid branch and take the latest

Download Details: 
Author: Mateimicu
Source Code: https://github.com/mateimicu/auto-tag 
License: View license

#git #github 

Tia  Gottlieb

Tia Gottlieb

1596336480

Beginners Guide to Machine Learning on GCP

Introduction to Machine Learning

  • Machine Learning is a way to use some set of algorithms to derive predictive analytics from data. It is different than Business Intelligence and Data Analytics in a sense that In BI and Data analytics Businesses make decision based on historical data, but In case of Machine Learning , Businesses predict the future based on the historical data. Example, It’s a difference between what happened to the business vs what will happen to the business.Its like making BI much smarter and scalable so that it can predict future rather than just showing the state of the business.
  • **ML is based on Standard algorithms which are used to create use case specific model based on the data **. For example we can build the model to predict delivery time of the food, or we can build the model to predict the Delinquency rate in Finance business , but to build these model algorithm might be similar but the training would be different.Model training requires tones of examples (data).
  • Basically you train your standard algorithm with your Input data. So algorithms are always same but trained models are different based on use cases. Your trained model will be as good as your data.

ML, AI , Deep learning ? What is the difference?

Image for post

ML is type of AI

AI is a discipline , Machine Learning is tool set to achieve AI. DL is type of ML when data is unstructured like image, speech , video etc.

Barrier to Entry Has Fallen

AI & ML was daunting and with high barrier to entry until cloud become more robust and natural AI platform. Entry barrier to AI & ML has fallen significantly due to

  • Increasing availability in data (big data).
  • Increase in sophistication in algorithm.
  • And availability of hardware and software due to cloud computing.

GCP Machine Learning Spectrum

Image for post

  • For Data scientist and ML experts , TensorFlow on AI platform is more natural choice since they will build their own custom ML models.
  • But for the users who are not experts will potentially use Cloud AutoML or Pre-trained ready to go model.
  • In case of AutoML we can trained our custom model with Google taking care of much of the operational tasks.
  • Pre-trained models are the one which are already trained with tones of data and ready to be used by users to predict on their test data.

Prebuilt ML Models (No ML Expertise Needed)

  • As discuss earlier , GCP has lot of Prebuilt models that are ready to use to solve common ML task . Such as image classification, Sentiment analysis.
  • Most of the businesses are having many unstructured data sources such as e-mail, logs, web pages, ppt, documents, chat, comments etc.( 90% or more as per various studies)
  • Now to process these unstructured data in the form of text, we should use Cloud Natural Language API.
  • Similarly For common ML problems in the form of speech, video, vision we should use respective Prebuilt models.

#ml-guide-on-gcp #ml-for-beginners-on-gcp #beginner-ml-guide-on-gcp #machine-learning #machine-learning-gcp #deep learning

Abigail betty

Abigail betty

1624226400

What is Bitcoin Cash? - A Beginner’s Guide

Bitcoin Cash was created as a result of a hard fork in the Bitcoin network. The Bitcoin Cash network supports a larger block size than Bitcoin (currently 32mb as opposed to Bitcoin’s 1mb).

Later on, Bitcoin Cash forked into Bitcoin SV due to differences in how to carry on its developments.

That’s Bitcoin Cash in a nutshell. If you want a more detailed review watch the complete video. Here’s what I’ll cover:

0:50 - Bitcoin forks
2:06 - Bitcoin’s block size debate
3:35 - Big blocks camp
4:26 - Small blocks camp
5:16 - Small blocks vs. big blocks arguments
7:05 - How decisions are made in the Bitcoin network
10:14 - Block size debate resolution
11:06 - Bitcoin cash intro
11:28 - BTC vs. BCH
12:13 - Bitcoin Cash (ABC) vs. Bitcoin SV
13:09 - Conclusion
📺 The video in this post was made by 99Bitcoins
The origin of the article: https://www.youtube.com/watch?v=ONhbb4YVRLM
🔺 DISCLAIMER: The article is for information sharing. The content of this video is solely the opinions of the speaker who is not a licensed financial advisor or registered investment advisor. Not investment advice or legal advice.
Cryptocurrency trading is VERY risky. Make sure you understand these risks and that you are responsible for what you do with your money
🔥 If you’re a beginner. I believe the article below will be useful to you ☞ What You Should Know Before Investing in Cryptocurrency - For Beginner
⭐ ⭐ ⭐The project is of interest to the community. Join to Get free ‘GEEK coin’ (GEEKCASH coin)!
☞ **-----CLICK HERE-----**⭐ ⭐ ⭐
Thanks for visiting and watching! Please don’t forget to leave a like, comment and share!

#bitcoin #blockchain #bitcoin cash #what is bitcoin cash? - a beginner’s guide #what is bitcoin cash #a beginner’s guide

A Beginner’s Guide to Setting Up a Web Application with Typescript and Express

Web applications are types of software applications that run on remote servers (source). Examples of web applications can range from word processors, to file scanners, video editing tools, shopping carts, and more. Web applications can be great additions to any website; they can even function as websites themselves (Facebook, Gmail, and Udacity’s classroom are all examples of popular web applications), so understanding how to set up and implement a web application is a fantastic skill to have.

For this guide, I am assuming that you already have a basic knowledge of npmnode and whatExpress Requests and Responses are (or that you at least know what they are used for in their basic sense). Also, I assume that you know what the npm install and mkdir commands do. You have to know basic Typescript to implement — or at least know basic JavaScript to read and understand — the code below. Finally, this is the base for the backend of a web application. You still need to create a frontend application using a framework like Angular or an HTML/CSS file to make requests and display responses.

Before you start, it’s important that you create a folder in your favorite place on your computer. This can be anywhere as long as you have a sense of how you are going to find it later when you come up with an awesome project to start developing.

The Process:

Image for post

#web-development #backend #software-development #beginners-guide #beginner