2. Made sure that the form uses some basic client-side html5 validation. i.e.

means that the form is expecting this field to have a string that matches an email format, and if it doesn’t, will raise an error before submitting.

3. IMPORTANT: Created a form that POST’s the data to /submit-registration-sync. As noted here:

and ultimately with:

because we haven’t built anything to handle it yet.

So what’s actually taking place here?

We’re saying that when someone submits this form, send a POST request to /submit-registration-sync.

What is POST? POST is one of the four (common) methods possible in HTTP (the protocol that is the base for all web communications on the internet). The other methods are: GET, PUT, and PATCH. (Actual spec can be found here)

For example, GET’s are the bulk of the internet. When you click on a link to this article on medium, your browser initiates a GET request to https://medium.com/p/9d01869dc97e/edit and the response will contain the html of this post.

POST’s are the method that is used to send data.

Don’t believe me?

Let’s try this out.

Handling the posted data.

We’re getting a 404 when the form posts right now because there’s nothing to handle it. So..LETS HANDLE IT! Inside the /routes/index.js, add the following snippet:

2. Now lets see if our form posts! Restart the server (Ctrl+C, npm start) then submit some test data in the form and check your console.

This picture was taken right after hitting submit.

As you can see here, the form submitted the form data to the server.

Store user in database.

We should also probably “store” the user in our “database”. In this case, we are using a simple .json file, and we will do so by adding the following lines:

So now when we restart the server and re submit the form, we can see the following:

And if we check inside the database.json file:

Great success!

We’re still not done though. We might notice that to the end-user, they’re still seeing the sign-in page with:

The endless loading loop

This is because the server hasn’t responded with anything yet. How rude.

Lets change that.

Send back the successful registration page.

First we need to build a successful registration page. Inside /views, create a page called signup-successful-sync.ejs with the following code:

This is the code for the page that will be shown to the user after signing up to make them feel happy about being successful!

Now, we need to ensure that the user is sent this page once they’ve sent the form.

To do that, we need to add some more code to the routes/index.js.

Which if we now try (remember to restart your server), we get the following after submitting:

Great!

Synchronous Data Retrieval

Now to the final synchronous feature, show us a list of all the currently signed up users.

The story is this:

“If someone accesses http://localhost:3000/users-sync , we want to show them list of currently signed up users!”

So, lets start off by creating a route for that. In this route, we want to query the database to get all the users, and then feed it into the users-sync view.

2. Next, lets create the actual view itself in file /views/users-sync.ejs:

And after restarting and heading to http://localhost:3000/users-sync, we should see a table of all our users!

Voila. All requirements met using the synchronous model.

So what do we know now?

Using the synchronous model means that the whole “page” is sent to the server, and another page is also sent back from the server.

So why don’t we just do everything synchronously?

Because, (1) it’s expensive. A whole page needs to be sent and received. That should be okay for people browsing your web-app from a desktop, but what about those using a phone? That’s a lot of $$ in data.

(2) Makes the interactions very rigid. There’s only two states, either you’re sending or receiving. This would make an app like Twitter almost impossible to use because it would require constant refreshes:

The solution? AJAX.