The Backend Engineering Show with Hussein Nasser

This is unacceptable and the entitlement towards open-source maintains needs to STOP!   Danial’s blog https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/  Support curl by becoming a backer  https://opencollective.com/curl#backer

Let us go through an absolutely fantastic article and journey of how a single change in HAProxy config drove this SRE into a frenzy to find out what went wrong. A fantastic read.  https://about.gitlab.com/blog/2021/01/14/this-sre-attempted-to-roll-out-an-haproxy-change/?utm_medium=social&utm_source=linkedin&utm_campaign=blog

From time to time I like to loiter on people’s GitHub Repos look through issues submitted and see if there are interesting hidden gems and bugs that would make a good lesson or learning experience and boy did I find one for you. This bug is caused in stripe-node code in AWS Lambda serverless environment where requests are failing intermittently. We discuss how AWS serverless container re-use can cause this and how stripe solved it.   Resources https://github.com/stripe/stripe-node/issues/1040 Intermittent Error: write EPIPE when running stripe client in AWS Lambda · Issue #1040 · stripe/stripe-node · GitHub https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/

XMPP or the Extensible Messaging and Presence Protocol  originally named Jabber[1]) is an open communication protocol designed for instant messaging (IM), presence information, and contact list maintenance. it is used by almost all large messaging systems such as whatsapp, facebook, google talk and others. In this video we will go through XMPP architecture, explain how it works and then finallly show how to spin up an XMPP chat server and connect to it from node js.

In this video I go over the critical timeouts on a Proxy system such as reverse proxy or load balancer and how can you configure each one to protect against attacks or outages. Nginx and HAProxy just a few proxies that you can configure to be load balancers.    

Guys this is absolutely genius and nuts! I have never seen anything like this before. This guy got access to paypal json and saw some private packages.. created public ones with a similar name and then made them do bad things, then thing because firewalls will shut those down.. he used DNS DNS requests are practically safe so firewalls allow them 11:05 chrome root https://youtu.be/qpC1YH0FhuY https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

Reads and Writes don’t have to live in the same database, data model or even the same service. Let us discuss CQRS no separation one service that does read/write partial separation You can keep one service but backend have multiple connections with different users same database full separation Read services / write services two databases OLAP / OLTP Pros scalability security Cons complex and very hard to follow, what we see with microservices.. resources https://martinfowler.com/bliki/CQRS.html http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

In this video, I will discuss the new TLS extension Encrypted Client Hello which is a new mechanism to encrypt the entire client hello, very interesting and elegantly design but I have my few reservations and criticisms. Let us discuss. Intro 0:00 Classic TLS with SNI 7:00 ESNI 9:30 ECH 12:30 Limitations and Problems 21:00 Let's say the backend server hosts example.com with the cert of example.com and let us call this the “real” SNI. To support ECH, the same server should also host a client facing cert, lets call it server-ech.com with corresponding server-ech.com cert. So your server IP address is hosting two domains. example.com and ( server-ech.com just to support ech) So when you perform an oDoH/DoH query looking for example.com you will get back the IP address of example.com, (which is the same ip address as server-ech.com), you will also get the ephemeral public key of example.com from the HTTPSSVC DNS record. This will be used to encrypt the inner client hello, and finally, you will get a record of the front-facing server domain name which is server-ech.com. The client prepares the TLS ECH, it builds the outer client hello with the SNI value as server-ech.com, and the inner client hello with the real SNI (example.com) along side ALPN and other stuff.. It then uses the public key of example.com retrieved from the HTTPS DNS record to encrypt the inner client hello. The client sends the ECH. Server receives the ECH, and attempts to decrypt the inner client hello with the corresponding ephemeral private key, if it succeeds it then completes the server hello and key exchange as normal. if it fails to decrypt the inner client hello with its own private key that means the public key used, was stale, outdated, bad etc.. . The client then uses the outer client hello and it checks, do I have server-ech.com, yes I do have a cert for that, let me just finish the key exchange and server hello with that instead, and btw, here is my REAL public key for example.com so you can use it for future ECHs. the public key is going to be encrypted for sure (that was something not clear in the article) because its TLS 1.3 and things are immediately encrypted from the server. The client then finishes the handshake and finds out the public key and immediately terminate the connection and re-establishes it with brand new encrypted inner client hello that uses the new server public key which we know this time its going to work .. I can image getting into an infinite loop if the server accidentally gave a wrong public key. also some cons of ECH comes to mind is the larger client hello + the additional backend management to host that client facing server and cert. Also another question, what If I’m hosting 100 domains on my single IP address, do I get a single ephmeral public key for ECH? or is it per domain? and how does my server know what private key to use to decrypt, does it just try them one by one? or is there an indication to which public key was used to encrypt the inner client hello.. (I’m guessing there is ) https://blog.cloudflare.com/encrypted-client-hello/

MySQL is clustered by default on the primary key which means inserts have to be ordered, let us discuss why UUID (random in nature) has bad performance in MySQL and whether postgres wins here. We will also explain why Sequential Writes are Faster than Random in MYSQL and     https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/

This is a very interesting article that I encourage you to read it as it has lots of useful lessons in postgres. Using partial indexes, full vacuum, dropping unused indexes and much more helped this company save 70G worth of disk space.    https://hakibenita.com/postgresql-unused-index-size