What is GraphQL and why you should care?

Hello dear reader!

First of all I would like to apologise for not having been able to post in the last few weeks, I have been swamped with work. Before continuing, I’d like to wish you all a very happy new year (better late than never), and I couldn’t think of a better post for the start of this year than this one.

graphqlAs you all know, most Apps depend on a backend system. This backend is responsible for communicating and serving data among the different users.This involves having an API (Application Programming Interface) to access the data. Most APIs are REST (Representational State Transfer) APIs. However, good old Facebook started to see some limitations and thought they could come up with a better and more efficient system. In this post we will do a bird’s eye of how it works and what advantages it brings to the table.

In a nutshell, GraphQL is a syntax that describes how to ask for data, and is generally used to load data from a server to a client. GraphQL has three main characteristics:

  • It lets the client specify exactly what data it needs.
  • It makes it easier to aggregate data from multiple sources.
  • It uses a type system to describe data.

So how did this come to be?

For example, imagine you need to display a list of posts, and under each post a list of likes, including user names and avatars. So, you tweak you like array to contain avatars. Such as shown below.

gql1

But now, it’s time to work on your mobile app, and it turns out loading all that extra data is slowing things down. This translates in the fact that you need two endpoints, one with the likes and one without them.

Furthermoire, imagine if the “likes” and the “avatar” where to be stored on different storage types (MySQL for Avatar and MongoDB for likes for instance). Well now, we are in a bit of a mess. Extrapolate this scenario to however many data sources and API clients Facebook has to manage, and you can imagine why good old REST APIs were starting to show their limits.

The Solution

The solution Facebook came up with is conceptually very simple: instead of having multiple “dumb” endpoints, have a single “smart” endpoint that can take in complex queries, and then massage the data output into whatever shape the client requires.

What this means, is that there is a layer between the client and multiple data sources that is in charge of receiving requests and deciding how to serve them. Let’s have a quick metaphor example: The old REST model is like ordering pizza, then getting groceries delivered, then calling your dry cleaner to get your clothes. Three shops, three phone calls.

gql2

GraphQL on the other hand is like having a personal assistant: once you’ve given them the addresses to all three places, you can simply ask for what you want (“get me my dry cleaning, a large pizza, and two dozen eggs”) and wait for them to return.

gql3

In other words, GraphQL establishes a standard language for talking to this magical personal assistant. Why Facebook decided not to call it Siri is beyond me ;).

The best way to understand more about GraphQL and its possibilities is by practical examples. Let me know if you are interested and what you would like to see in the next post.

Thanks for reading!

Until next time!

Advertisements

Madrid Youth Entrepreneurship Award

Hello dear reader!

LogoTJMonday November 27th, was an extremely important day for me. I have received the Madrid Youth Entrepreneurship award (http://www.carnejovenmadrid.com/es/ventajas/otros-planes/iii-premios-talento-joven-carne-joven-comunidad-de-madrid,731). This award is aimed at people who have created projects that are pushing the boundaries of innovation and creating job posts. It is an immense pride to be the winner of this year’s edition and I will continue to work tirelessly to be worthy of this honour.

It is amazing to see how something that starts as an idea, turns into a full-fledged product that is used by millions of users. At the beginning, everyone thought we were crazy, that location sharing was never going anywhere. We have always argued the need of real time location sharing that expires after a certain time, always with an agreement from both parties, and with total security and privacy. Flashforward three years and we have been able to raise numerous investment rounds, acquire over 10 million users, expand all over the globe and see how other giants like WhatsApp, Google, Facebook and Telegram copy our model. Days like today prove that we are on the right track and we will continue to rocket Wave to the moon.

I would like to thank all the Youth Organization of Madrid, the council of Madrid and Wolters Kluwer for awarding me with this distinction.

You can read all the different press releases about the event below:

You can also read my latest interview while you are at it 😉

https://global-m.co.uk/journal/day-in-the-life-of-a-cto-pablo-clemente-wave

And you can also check out some cool pictures below.

 

 

This slideshow requires JavaScript.

Thank you very much for reading!

Until next time!

Is Serverless the way to go? – Part 2

serverlessIn my last post (https://pabloclementeperez.wordpress.com/2017/09/18/is-serverless-the-way-to-go-part-1/) we looked at many problems developers and enterprises encounter when trying to scale up their systems and handle heavy traffic at irregular intervals.

Serverless is a new and fresh perspective where your code is encapsulated and contained in a virtual environment, this environment is then moved on demand through different types of architecture so that you are always able to meet the demand you need. What really happens is that big companies like Amazon have huge infrastructure provision, so what they do is they take their servers and deploy your code in different instances according to demand, they then charge you by time execution (usually per 100ms of execution time). This means that you only pay for the actual time your code is run, and not for the number of instances you need.

Amazon is so proud of Lambda it decided to make one of their videos you can watch below:

 

You probably are thinking that this all sounds great and that why the hell would anyone go for a normal infrastructure like paradigm. Well, there are many drawbacks, the first one is that every time your virtual container is run on a new instance you need to set up your environment, load your libraries and dependencies, and start the system. This costs precious seconds, which means your users would have to wait over 5 seconds to receive their API call for instance. This time is lower if you use lightweight languages like Node.js or Python, but can be terrible if you use Java (since you need to load the Java Virtual Machine which is extremely resource hungry). There is a very interesting article about this here https://read.acloud.guru/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda-a15e26d12c76

One more thing to consider is that if you run a website, Lambda is not the best way to so do, as your content could take a lot to be available, and you would need space on the instance to serve your content. So, it is extremely oriented towards event driven architectures, such as APIs. Another thing to bear in mind is that the less frameworks you use, the faster load times will be, if you decide to use a lightweight language with your own custom implementation (Python with as few frameworks as possible for instance) you’ll get amazing performance.

What do you think about serverless? Drop me a line in the comments!

Thank you for reading!

Is Serverless the way to go? – Part 1

If you are currently in the IT business and rely on Internet infrastructure to serve data you probably know what a pain it is to manage those IT systems. Constantly having to manage servers to increase throughput, lower costs, ensure autoscaling and keep latency at bay is a tremendous effort. It has even spun a new role in the industry, the Dev Ops.

servers

Amazon Web Services (I’ll be using them as the example since they are the leader, but other providers have similar resources) have made giant efforts to try to help developers with this aspect. One of the resources they offer is what they call Elastic Beanstalk. This effectively is a system that allows you to provision code to a number of instances that are behind a load balancer. The load balancer is the key, as it can deploy code into instances by taking them out of the group until they are ready and it handles auto scaling. Auto scaling is handled via triggers, for instance, if you use a CPU trigger, when the overall CPU usage goes over X% the load balancer will spun a new instance with your code and add it to your group, and when it goes below X% it will remove instances. Basically, it helps you manage instances while you maintain full control of everything. So, everything covered no? Amazon felt it was so great three years ago they made a strange video with a curious voice over (honestly, with the budget these guys handle you think they could do better) you can watch below.

However, the truth is this system has immense limitations, the first of which is what happens if you get a traffic spike. When you know you are expecting heavy traffic you can get ready for it by provisioning more instances, but what when that catches you by surprise? Imagine a blog post you don’t expect or some other type of uncontrolled media like an influencer. You are basically screwed, since the load balancer is not particularly agile at sensing something that doesn’t grow in a linear fashion (it typically uses health checks every 1 to 5 minutes), so your system would probably go down as your instances serverlesswould get saturated.
So how do you solve this? How do you prepare for situations like this without having to spend vast amounts of money of infrastructure provision? One of the possibilties is going serverless, and we will analyse what it is and how it works in the next blog post 😉

 

Hope to see you there!

SwiftQR – The fastest QR code reader

A few weeks ago I started looking into Metal (https://developer.apple.com/metal/) on iOS. This is basically a technology that allows you to access graphics chips on iOS devices on a much lower level than typical OpenGL drivers and thus translates in a huge speed boost.

One of the things that pains me most about iOS is that there is no perfect QR code scanner, and they are all painfully slow, so I wondered what could happen if I applied metal imaging technology to QR code recognition and the results blew me away. It is by far the fastest QR code scanner on the App Store. Just try it and see for youself.

As a treat for my readers, it will remain free for a limited period of time. So grab it before it is too late!

qrApp1024Oh, and the name of this beauty? SwiftQR, because it is fast and build in Swift 😉 (how geeky is that!). You can view the description below, the download link, and some screenshots.

Until next time!

 


How many QR codes do we see every day? They are everywhere, from leaflets and magazines to buildings and cars. Wish there could be a faster way to read them? Well wish no more! Leveraging powerful image recognition techniques this is the fastest QR code reader out there. Just give it a try and see for yourself!

Plus, all the QR codes will be saved to your history so that you can view them later and organise them. And if all that wasn’t enough, you can easily create your own QR codes and share them!

Upgrade your QR code scanning experience today!

Available_on_the_App_Store_(black)

When did iOS App review become so intrusive?

Hi dear reader!

Today I wanted to talk about something that has been bothering me lately, and that is the iOS App review process. For those of you who don’t know, this is the process Apple uses to check that the Apps you submit to the App store are secure enough for their ecosystem.

app_store

This on paper sounds great, it feels like an excellent way to ensure that apps are secure and developers go the extra mile to make sure privacy is maintained at all costs. Despite many arguments coming from Android convicts, I actually think this, although sometimes excessive, helps keep iOS safe.

However, lately reviewers have decided to change a bit their path and focus, THey are not looking for security as much, and are more focused on the fact that Apps create what they believe are “Great experiences”. For instance, lately at Wave we were forced to make sure the App allowed you to continue without having access to your contacts (which is as cumbersome as a chat app where you have no one to talk with).

But it gets worse, I am bulding a pet project based around a QR code reader using Swift 3 and Metal that will be the fastest QR scanner out there. And they have rejected it because they say that if the user has no QR codes, then the App is useless. This seems so absurd I am providing hard evidence below.

Apple App rejectionJPG

Why someone would open a QR code scanner without a QR code is beyond me, but you have to play by their rules, so you get rejected and have to add extra functionalities.

What do you think about this? Do you find this appropiate? Or is Apple going too far? One thing is ensuring securirty and forcing updates in old apps, but questioning your App’s utiltiy is a bit of a stretch for me. Considering that this is just an opinion from a random reviewer. Furthermore, sometimes submitting the same app to get another reviewer, means you get accepted direclty.

What do you think? Drop me a line in the comments.

Thanks for reading!

A week in San Francisco and Silicon Valley

Hi dear reader!

This week we are going to be in beautiful San Francisco, it has been a great chance to immerse ourselves in the most advanced start-up ecosystem in the world, and we are learning and shaping the future of Wave. We have met with many people, companies and VCs. You can check out our super photo at Facebook’s Hacker Square ;). We still have a few days left, so if you would like to meet us please drop me a line to reserve you a space as soon as possible.

IMG_1711

We’ll continue our busy schedule and enjoying the beautiful San Francisco. You can check out some photos below to see how beautiful this place is.

In the next post, we’ll be sharing some insights we have learnt!

Until next time dear reader!