Greetings, dear readers! I hope you enjoyed your break during the Easter and Ramadan season.

Now that the holidays are over, I'm excited to present the 12th episode of Biweekly Engineering. Without further ado, let's get started!

Today, we have interesting articles to read from PayPal, LinkedIn, and the Pragmatic Engineer blog.

GraphQL adoption story at PayPal

#paypal #graphql

In the last episode, I shared a blog post from PayPal. If you missed the episode, feel free to check it out from here:

In 2018, the checkout team at PayPal decided to use GraphQL to serve its clients. The success story of that team created a drive within the company to adopt GraphQL even more. In today’s article, PayPal shared their adoption story in nice detail.

The first question that pops up - why GraphQL? Like other companies, teams at PayPal were facing the typical issues that companies face before deciding to use GraphQL. Two popular reasons we frequently see are over-fetched data in every API call and increased latency due to multiple roundtrips. So it was a matter of time to find a better and more manageable solution. Given that the checkout team succeeded with GraphQL, the other teams at PayPal were happy to follow suit.

With the wide adoption of GraphQL, PayPal started to see the significant benefits of the technology. For example, developer productivity increased a lot, API and schema exploration became much simpler, shipping time reduced substantially, number of roundtrips from frontend to backend reduced, etc.

The article discusses why PayPal widely adopted GraphQL, how the adoption effort was scaled across multiple teams and organisations within the company, what are the advantages witnessed, what challenges were faced, and how the higher leadership was convinced for adopting the technology. In the end, the article also shares some ideas on how to adopt GraphQL for people in other companies.

Real-time analytics on network flow data at LinkedIn

#linkedin #realtime #analytics #apachepinot #olap #apachekafka #apachesamza #streamprocessing

This one is an interesting article that showcases how far engineers might go to increase observability in their systems. As discussed in the post, LinkedIn built a system called InFlow that monitors and tracks network flow - the movement of a packet through a network.

LinkedIn blog also has an article on InFlow:

Just like any analytics system, the first step to build InFlow was to collect data. This was done directly from the network devices. Then the data is enriched using Apache Kafka and a popular stream processor framework named Apache Samza. Finally, the data is persisted in Apache Pinot - a powerful online-analytical processing (OLAP) database.

The greatest benefit of using Apache Pinot here is that the database provides sub-second latency. Also, since the data is enriched and persisted in real-time, new network flow data is very quickly queryable: in a minute.

Critical thinking for software engineers

#thepragmaticengineer #gergelyorosz #criticalthinking

Yet another blog post from my favourite author Gergely Orosz.

In this interesting piece, Gergely discusses critical thinking and its importance for software engineers. In spite of being a crucial skill, too many software engineers tend to forget about it and don’t put active effort to build and improve the habit of critical thinking.

Summarising Gergely’s discussion in this post, we can think of critical thinking in terms of three steps:

1. Ask questions and sometimes challenge others during a discussion. If there are technical jargons used, ask for clarification.

2. Research and validate yourself, and go deep into topics to understand them.

3. Be consistent in this practice.

The author elaborately explained how to pursue the habit of critical thinking. Don’t forget to give it a go.

One important point the author makes is the usage of jargons. There are software engineers who intentionally or unintentionally tend to use jargons that might throw you off as a junior or a new member in the team. Don’t get bothered by this. Using jargons is not a credit, and sometimes it might mean the people using jargons are not themselves knowledgeable enough. Un-jargon the jargon. Try to understand things well enough so that you can make others understand.

Time to say goodbye for today. I hope this episode brought something interesting for each one of you. Don’t forget to be consistent and make reading the articles I share a habit. You will surely be benefited.

If you have been finding the newsletter useful, please share with your peers. We are growing as a community (250+ members now) and we should keep growing!

To subscribe: https://biweekly-engineering.beehiiv.com/subscribe

See you in the next episode!