fedeisas / web-101

A simple project done to help fellow recursers get into web development

web-101

A simple project done to help fellow recursers get into web development

Introduction

This is intended to be explained and then used as a way to explore how a client side integrates with a server side, to produce something (maybe) useful.

I am not presenting here best practices, actually looks more what you would not do in the industry, but, I believe it could be a nice way for getting people started, provided little programming experience.

I am going to assume some level of experience in programming, what's enough for you to get along with your pc and progress in the use of this simple project. For any doubts or questions feel free to open an issue.

How to use this

You will need node and npm installed on your computer.

Installing

Open a console and

$ npm install

Starting the server

Open a console and

$ npm start

This will start the server, but any change you will make to it will not be picked up, unless you

$ npm run dev

which will restart the server for any change you make to the project files.

Note that the server does not persist the actions you perform, so a restart, or a termination of the server process will result in a loss of the data you entered.

Seeing the client

Point your browser to http://localhost:3000, you should see a few HTML components, that will let you see, delete, create, and update contents in the server.

From the console

If you like I've committed the scripts I've used to code the server, you will find them in the server/ folder.

Doing something

You should now have your browser pointing at http://localhost:3000.

Right click on the page and choose something that reads like "inspect", you should see a panel appearing, you will then notice a few tabs also, we are interested in:

• Console - which shows all errors or message we log using console.log('something')
• Network - which shows all calls happening between the client and the server

All the buttons you see perform some actions, which are then picked up by the server, which in turn applies them to the data structure holding all the posts.

Get yourself familiar with the flow:

• list all posts - you should see a {} appearing in the console, meaning there are none, and a funny image in the middle :)
• choose a name and a description, then click the button to create a post now you will have a post in your server data structure

How would you find out how many posts you have in the server?

Now let's say you've made a mistake in your description, show all posts on the server and notice that in the data structure you see there are some long strings formed by numbers and string, those are unique ids of each post, grab one and put it in the correct place of the update section along with a description, then press the button.

If everything went ok you know how have an updated post in yur server and a way to check that this assumption is true.

How would you find delete a post from the server?

Focusing on calls

Switch away from the "Console" tab and go to the "Network" one.

Now get all the posts from the server. You should see the call to the server appear, if you put your mouse over it you should see a popup window with "http://localhost:3000/api/posts" inside.

Click that, you will see all the informations related to that call.

A call to a server represents a need the client has, the response from the server will inform the client if that request was legitimate and if so with a proper message saying so.

The architecture I am presenting here is called REST, it focuses mainly on readability for us humans, so a developer looking at

• a POST on /api/posts will expect that to create something on the server
• a PUT on /api/posts/1 will expect that to update the post with id 1
• a GET on /api/posts will expect that to return all posts
• a DELETE on /api/posts/1 will expect that to delete the post with id 1

REST focuses on verbs (POST, PUT, GET, DELETE, ...) being called on endpoints specifying a noun, so POST /api/posts is computer language for create a post.

Of course this could change a lot in terms of how to choose the endpoints, like

• POST /api/1.1/post with a version 1.1 and the singular instead of plural
• PUT /api/post some people will perform a PUT to create something, it's still ok under some circumstances
• POST /api/posts/42 with an id specified by the client and not generated by the server (as this project does)

but the principle remains the same, you apply a verb to a resource to create contents.

Note that POST calls are usually implemented as not idempotent, this could lead to inconsistencies when, for example, networking errors happen between the client and the server, while a call is being made.