The Backend Engineering Show with Hussein Nasser

GraphQL Pros and Cons, examples and when to use over REST GraphQL is an open source query language developed by facebook that allows clients to formulate queries to get different results. Its main goal is to combine multiple services into one endpoint. In this video we will discuss what is GraphQL, why facebook developed it, go through some examples using github GraphQL API, finally we will discuss the pros and cons and when you should use this technology. What is GraphQL? Examples Pros and Cons when to use REST vs GRAPHQL What is GraphQL Schema Query language Nesting Mutation and subscription Examples Schema intro Github API Rest api Pros Flexibility efficient response : payload back only get what you want of fields since you know the schema No round trips- Avoiding multiple round trips (HATEOS REST) Uniform single interface API endpoint Self documenting Cons Complexity Typed system - ( use it to know if a type is available or not and fork logic) slows down adoption.. same as soap No Caching etag since always POST Error management non-standard for HTTP. Over engineering can lead to Inefficiency of the joins can lead to performance and DOS

Consistency vs Eventual Consistency Consistency is the property of having expected result in view of the data or during reads while working with a database system. It is one of the ACID properties in relational databases. Eventual consistency is another term that was born recently specifcally as NOSQL databases got emerged. In this video we will talk discuss the difference the different kind of consistencies and we will explain what Eventual consistency and how both relational databases and NO SQL databases have this kind of consistency with some examples. Cache Leader Following Consistency in Data Your data broken into multiple normalized tables/collections is consistent. Consistency in Reads If you write a value new transactions will pick up that new value. If you do not have consistency in data you do not have eventual consistency, your data will not magically correct itself. If you have do not have consistency in reads you might have eventual consistency, you reads might eventually become consistent. Eventual Consistency means that your reads will become consistent as time pass time. This is true for both NOSQL and relational database system especially if you have leader/follower module. In this video we will talk about an example of eventual consistency and this is tolerable when it’s not. Eventually Consistency Benefits Twitter timeline (Eventual Consistency is good) Let’s say you tweeted something and you have a follower in Spain and a follower on New Zealand 🇳🇿 furthest two countries on Earth. Your Spain follower might see your tweet before your New Zealand one does. This depends on which datacenter your write goes to first. That eventual consistency is tolerable and its ok if New Zealand don’t see your tweets. Benefits Write scales much better, you can write to different locations and have them synced. Add more machine to scale to more and more users. Twitter privacy example (Eventual Consistency is bad) However take this scenario, you are Taylor Swift (Taylor swift wishes) a celebrity with 85 million followers. You tweeted something that you regretted later and decided to delete that tweet! That tweet better be deleted instantly to all your 85 million follows. Eventual consistency is not tolerable here otherwise people lose faith of the system. Well, you can always say well I’m gonna take a screenshot of Taylor Swift tweet. To which I would say I’ll give you another example, let’s say you changed your privacy setting to private and you tweeted something right after, that change should be immediately take effect and NO public user should see that tweet unless they are obviously in your followers. Problems: Users lose faith in the system. Cards 4:30 ACID https://www.youtube.com/watch?v=pomxJOFVcQs

ACID ACID are four properties of relational database, they Atomocity, consistency, isolation and durability, and I think any one working with a relational database like postgres, mysql, sqlserver oracle, should understand these properties. In this video we will go through the four properties and explain why each is critical to make a relational database we will also talk about why some people are moving to  NOSQL database Atomicity  All or none. if a failure happened during transaction, db failure, or one of the queries failed.  Example Isolation Concurrency, is transaction isolated from other inflight transactions? if a transaction is in flight does it see changes from other inflight transactions? Does is it see any changes? Does it only see committed changes. Does leading to inconsistent results.  Problems arising from isolation (read phenomenons)  dirty reads Non repeatable reads Phantom reads  Isolation levels Read uncommitted Read committed  Repeatable read  Serializable  Durability When I commit a transaction does my changes stay durable after the database restarts/crashes etc.  See if your data still there.  Consistency Consistency from referential integrity keys  Does the number of likes on a picture = the number of rows that the picture got on another table? If a delete a picture does all the likes of that pictures go away on the other table. Consistency in reads  If I committed something does everybody see it immediately or are they going to get an old value? Consistency in concurrency Is the view of a transaction in flight consistent? Are other inflight transactions making changes to the database affects that transaction view? Jump Codes 2:00 What is a Transaction? 4:30 Atomicity  7:00 Isolation * 9:30 Isolation - Read phenomena * 11:40 Dirty Reads 14:40 Non-repeatable Read 17:00 Phantom read 18:53 Isolation Levels*2 19:20 Read uncommitted 19:55 Read committed 21:05 Non-repeatable Read 23:40 Serializability  25:00 Isolation Levels vs Read phenomena Table 27:45 Consistency  28:30 Consistency in Data 33:50 Consistency in Reads 35:00 Eventual Consistency  40:30 Durability  Cards 27:40 Exclusive lock vs shared lock

  REST stands for Representational state transfer its is an architecture that became very popular in build web APIs. It was the dissertation of Roy Fielding. In this video we discuss what makes an API RESTFUL, the REST APIs constrains, ill the show you an example of a RESTFUL api in github.  Representation and State transfer  Representational  The resource is a representation or meta data, but the actual backend could be something else and stored differently. An  Example, could be a user resource could be represented as a JSON object but it is stored on the backend as relation DBMS tables such as postgres.  State transfer The application server is stateless, and when we want communicate we transfer the current state of with each request. Thus the state transfer.   Example, lets say you are uploading a 5MB file in 5 chunks each is 1 MB in size and assemble it on the backend. The REST api end point takes the content along with a upload sequence, then persist it on a storage backend such as S3. Each chunk request could hit a completely different stateless server and the transfer will work fine since we are transferring the state (upload sequence) with every request. The client maintains the state in this case.  Rest constraints Client/server architecture Is there separation of concern? Can you upgrade your server without upgrading client? Can you upgrade the server without upgrading the client?  Statelessness Is your api stateless? Can you restart your backend server and clients of your api resume working normally without failing? Can you add a non sticky load balancer and transfer the load between the servers without the client breaking? Cachablity  Can resources that can be cached be cached with your api? And is there a way to identify stale resources?  Layered systems Can I insert gateways and proxies and firewalls silently without this architecture breaking? Load balancers  Uniform interface Resource identification (uri)  Resource Representation (json)  HATEOAS Hypermedia as an engine to application state Initial link can link to the rest ( github)  Github  Emojis 

A proxy is a software that intercepts traffic and forward it to the destination on behave of the client. This extra layer provide several advantages such as caching, load balancing, content filtering and much more. Some implementations of proxy can be used by governments to spy on its citizens. We made a video about proxy vs reverse proxy check it out if you want to learn more about the difference. In this video we will explain the different types of HTTP proxies and the benefits and use cases of using each coming up.  Transparent proxy (gateway)  HTTP insecure proxy Service Mesh Proxy Transparent proxy It is mostly used by the ISPs, clients don’t know they are connected to transparent proxy. The way it works is it looks at TCP/IP layer 4/3 and forward it to the destination, it might do some content filtering based on the IP address or the port so it blocks certain sites. But thats pretty much it. transparent proxy cannot know which pages are you viewing or your what youtube videos are you watching. It can block you from watching youtube all together but it cannot block you from watching lets say a specific youtube channel that is critical of the government ISP is located at.  Transparent proxy doesn’t change the content.  HTTP Proxy (insecure)  This kind of proxy is used alot, especially in service meshes like linkerd. This kind of proxy have to be configured in the client to use it. Each request will always be targeted to the proxy IP address / port. So when want to make a GET request to husseinnasser.com, and you have a proxy configured, when you look at the TCP packet for that request the destination IP and port is those of the proxy. The proxy looks at the GET request and specifically the HOST header and establishes another TCP connection to the actual destination on husseinnasser.com. So this kind of proxy maintains two tcp connections. Client to proxy and proxy to destination. The proxy have access to the content, it can block the website. It can know what exact page you are viewing. It knows everything because HTTP is insecure. Assuming youtube uses just HTTP, if you have a proxy setup it can block a specific channel or even video from being viewed. 1:05 proxy vs reverse proxy https://www.youtube.com/watch?v=ozhe__GdWC8 2:50 TLS https://www.youtube.com/watch?v=AlE5X1NlHgg Kazakhstan government is now intercepting all HTTPS traffic https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/

The podcast delves into the evolution of HTTP protocols from 1.0 to HTTP/3 over QUIC, showcasing enhancements like compression, multiplexing, and server push. It also covers the components of an HTTP request, status codes, and headers, offering insights into the development of client-server models.

NAT network address translation is a process of mapping an IP address or IP port pair to another IP address or IP: port. You might be wondering what a software engineer like me doing making a video on a low level networking concept? I have good reasons for that. NAT was originally designed to solve the ipv4 limited IP addresses, but since been used for port forwarding and layer 4 load balancing through the virtual ip address such as Haproxy thats why I decided to make a video about NAT from a software engineer view. In this video we will explain how NAT works and we will explain its applications. 

Tunneling protocol Tcp tunneling Tunneling is the process of encapsulating content from a protocol A into another protocol B, usually because protocol A is blocked or unavailable. In this video we will explain how TCP tunneling works, the applications of TCP tunnels and the pros and cons. Coming up! * TCP Tunneling * Applications * Pros and Cons TCP Tunneling Here is how TCP Tunneling works. Lets say your goal is to access a website that your ISP proxy blocks www.server2.com this is hosted on server2 on port 80. Lets say there is another Server1 that you have access to and Server1 have direct access to Server2. So if you can make Server1 make the request on your behave to Server2 and somehow deliver the results back to you, you just created a tunnel between You and Server1. Here is how it actually works. You create a legit tcp connection over a known protocol such as SSH between you and Server1. You then create a tcp packet that is intended for Sever2 so you tag it with Server2:80. Then you package that packet into another TCP packet intended for Server1! Huh ! Server1:22. You then forward the packet over, your ISP police will see that there is a packet intended to Server1 on port 22. Proxy approves and forwards it over not knowing that you are smuggling content in that packet. Also the proxy cant even look in the content because its encrypted with RSA. Server1 unpacks the package, decrypt and discover that its an other tcp packet. Here is where the shady stuff happen. Server1 now looks and see that the smuggled package is intended for Server2:80, created a connection and delivers the package it, it changes the source ip to its self and keeps track somehow of that. Once it receives the package it knows that this package has to go back to tunnel. The client now have access to the blocked site! What does this look like guys? Yes you guessed it its a VPN. It’s literally like smuggling content inside a package 📦 that looks legitimate. Server1 and Server2 can be the same server There are many types of tunneling Local port forwarding: Remote connection, Socks Proxy: forward pretty much anything (VPN) Reverse Tunneling : Expose local web server publically Applications VPN Securing an insecure connection Anonymity Bypass firewall SOCKS 4 proxy redirect all your traffic regardless of the port to an internal proxy instead which tunnels it. Dynamic port forwarding Pros Secure connection Access blocked services Anonymity Expose internal traffic Cons TCP meltdown (TCP over TCP) Slow retransmission Stateful Local port forwarding Just one app gets forwarded when the local port is requested Socks All apps goes through the proxy Http tunneling TCP VS UDP 1:00 11:00 OSI model 15:40 private vs public ip 18:35 proxy vs reverse proxy 24:30 TLS 11:20 local 16:20 reverse 20:40 socks

  TLS which stands for transport layer security is a protocol for securing communication between client and server. Specifically for HTTPS. Thats what the S is stands for.  In this video, we will learnq how insecure vanilla HTTP works, HTTPS, then we will learn how HTTPS is possible via the transport layer security and finally we will talk about the improvements in 1.3 that was published August 2018.  Vanilla HTTP HTTPS  TLS 1.2 handshake TLS 1.3 enhancements Vanilla HTTP  Before we discuss TLS, HTTPS or anything else lets go through how HTTP request work. You can type in the browser www.husseinnasser.com , the OSI magic kicks in, client figures out the IP address of husseinnasser.com by calling the DNS which uses UDP. Then HTTP application layer makes a GET / request passes in the IP address and port 80 (default for insecure http). This creates an underlying TCP connection. GET / string among other stuff into the packet and send it over. TCP does its thing server receives GET / calls the appropriate process at the backend which could be just return index.html sets content type text/html and sends back big response for client. All of this obviously is plain text no encryption any kind and if you watched the OSI video we made you can tell that people can sniff/snoop packets and get packets they aren’t supposed to get HTTPS Works by negotiating a symmetric key so they can both secure messages. Watch the video we did on encryption. Before we jump to GET request there must be a handshake 🤝 that must occur between the client and server. The tricky part is exchanging that key. Same thing as above except port is 443 instead of 80. Remember once we lose the TCP connection we will have to renegotiate the key. But beauty of this is HTTP is stateless so it remains working just fine.  Tls handshake 🤝  The original TLS handshake involves 4 roundtrips. A client hello which the client includes which encryption algorithms it supports (Both symmteric and asymmetric). The server receives the request then replies back with the server certificate which includes the server public key and also the encryptions that they will change to. The client receives the server hello, generates the premaster key, encrypts it with the server’s public key then send it over. The Server decrypts the message, gets the premaster generates the symmetric key finally tells the client that we are good to go.  Tls 1.3  TLS 1.3 involves much shorter and much secure communication using only deffie hellman as key exchange and just two round trips. 

Encryption is the process of scrambling data to protect personal files, secure communication, hide identities and much more.  In this video we will learn about the different type of encryptions we will talk about symmetric encryption, asymmetrical encryption, where they are used for and the pros and cons of each one.  Symmetric encryption Asymmetrical encrypt  Pros and cons of sym va asym  Symmetric encryption  Might as well just call it classic encryption I would argue and i think this is the first encryption known to us. I have some thing I dont want anyone to see I use a lock key to lock it. Only I can open it unless I have a lock.  The same key you use to encrypt is the same key to Decrypt.  Examples Examples of popular symmetric-key algorithms include  AES Twofish Serpent  DES Twofish, Serpent, AES (Rijndael), Blowfish  CAST5, Kuznyechik, RC4, DES, 3DES, Skipjack, Safer+/++ (Bluetooth), and IDEA  Asymmetrical encryptions  We had symmetric encryptions for a long time, then internet came and networking and we needed to encrypt messages going back and forth. We said cool lets use AES. Then we said wait a second.. the other computer doesnt really have my key so we need to encrypt it..  Also called Public key encryption  1977  Rivest–Shamir–Adleman (RSA)  Diffie–Hellman key exchange protocol DSS (Digital Signature Standard), which incorporates the Digital Signature Algorithm ElGamal Various elliptic curve techniques Various password-authenticated key agreement techniques Paillier cryptosystem RSA encryption algorithm (PKCS#1) Cramer–Shoup cryptosystem YAK authenticated key agreement protocol