6^th Practical Class:
BackEnd finalization!

Auth

The Problem: You need to kepp the isLoggedIn information somewhere.

Server side stored login

First option is to store it on the server - server login. Eg, somewhere in server storage you have information user1 is logged, with bunch of associated informations. The you need to know which client belongs to which logged-in user. Common example can be PHP session login style - persistent session is created and stored on server, then identifier of said session is sent to client, stored in cookie / localStorage.

This approach has major disadvantage - it is hard to scale this solution for thousands of active users. Also when the storage fails, every logged status information can be lost.

Client side stored login

When user successfully finishes login, server sends back signed object with claim userId=1234. Then client sends this object with every request to server. Server then uses this object to validate if request has enough rights to access the resources. Common implementation is JWT - Json Web Token;

Client side stored login must ensure it can thrust claims that are sent from client. With this ensured, the solution is scalable to milions without major problems.

JWT

Currently wery common approach how to do auth process. In a nutshell, server is sending out JWT tokens, which look like this (without the break-lines :) ):

• First part is used for meta-information
• Second part is used for payload - the actual information you want to send to client. At least userId should be here
• Third part is signature. Signature is generated from frist two sections and private key (which must be kept secure!), signed and encoded. This is used to validate claims in seconds section when using the JWT token.

Let's see the code

BackEnd performance optimizations

First let's repeat golden rule of performace optimizations:

Premature optimization is root of all evil

When you have signs that your page is slow, follow this checklist:

• Identify which pages are slow, under which conditions, which actions need to be taken to trigger the efect (reproducibility)
• Measure speed
• Write down measurements
• Analyze measurements
• Implement changes
• Start measurements again
• Compare data and pick better solution

Let's see example

Note on GraphQL + SQL optimizations. By nature of GraphQL, nested queries can produce really inefective / slow requests. My recomendation - start with naive / simple implementation. Measure if you really have performance problem. If so, please do send the code & problem description my way, we can think of optimizing this use-case. And we can show it on future practical lesson :) I was thinking of preparing some artificial examples, but ended up with bunch of theoretical confusing wiblity woblity code & talk... So specific use-case will be better :)

Secondary note - BE performance needs change quite rapidly with ammount of users & use-case of server. With milions of users, event 5% server speed-up can cave quite a lot of money. And servers which are made for buld data-processing can require way different approach.

Third note - slow BE with lot of users? Add cache. And optimize slow requests.