Forem: Jaden Baptista

The Jamstack Identity Crisis: an Even-Handed Overview

Jaden Baptista — Thu, 19 Aug 2021 15:04:20 +0000

The community is abuzz.

The last few months, we've been debating — as a community — what the Jamstack even is. In the way of a quick summary, we largely split into two groups:

The Pragmatists

This group, pioneered by people like Hashicorp advocate Jeff Escalante, Forestry developer Franck Taillander, and Layer0 CTO Ishan Anand, is pushing to drop the name Jamstack because it's growing increasingly pointless as a descriptive term. They believe its trendiness has worn off and it's becoming restrictive and ultimately vexing as we fight about what's included in the definition.
The Resolutionists

On the other side of the aisle, you've got the folks who want to fix the definition of the Jamstack to include new practices rather than ditch it altogether. In this camp, you've got industry leaders like Bud Parr of the New Dynamic, Brian Rinaldi from StepZen, CloudCannon CEO Mike Neumegen (who wrote an excellent article on this just a few days ago by the way), and the king of performance and accessibility Henri Helvetica.

So far, we've been trying to place a clear border through a fuzzy gradient. We've been asking: "where do we draw the line between Jamstack and the other?"

We're starting to see a consensus, though. Attitudes are cooling and people are starting to come together on a solution. Here's the gist of what they're agreeing on:

The Jamstack as a set of best practices.

It's not a dichotomy anymore. The question is no longer, "is this site Jamstack?" The question is now, "how many Jamstack techniques does this site incorporate?"

That undercuts the whole premise of the earlier debate. If the Jamstack is no longer a restrictive and exclusive category, then you don't have to drop the name entirely to start using some non-Jamstack techniques like dynamic rendering on a monolithic server. You also don't need to redefine the Jamstack to start doing bigger and better things, because you can use the Jamstack label to talk about some of your site without sounding like a purist. Now, we don't need to draw a clear border through a fuzzy gradient, trying to separate Jamstack from the other. We don't even have to place our site on that spectrum at all.

Here are some of those principles:

Jamstack sites don't rely on dynamic page-building code on the server.
As much content as possible is baked into the markup at build time.
Extra functionality is primarily added with third-party APIs.
Any necessary custom server-side code is organized in manageable, atomic, decoupled microservices.
Most of the necessary assets for the site to load are held close to the client in a CDN.

Perhaps you are prerendering most of your site, but the backend API you've created for yourself is based around a monolithic architecture because your particular use case requires it. That doesn't have to be controversial! You've just used some Jamstack techniques in combination with some more traditional techniques to create an application that works best for you. We can all agree that a hybrid approach like this will — in many but not all situations — work better than either extreme, right?

Consensus is good...right?

Gif from the article linked below

From one point of view, absolutely! People who were, at one point, not seeing eye to eye are now cooperating, and that sure is lovely to see.

On the other hand, one of our favorite business articles over here at TakeShape, a 2016 post on the blog "Conferences that Work" entitled "When consensus is dangerous", makes a great point:

"The value of consensus is in the process of seeking it — not a “yes, we have consensus!” outcome."

It's the old adage "it's the journey, not the destination" playing itself out over again. If we focus on the outcome of what the community largely feels the Jamstack is, we might be missing the underlying lesson. This whole ordeal just goes to prove that the people who are participating in this discussion are doing so because they have a passion for whatever they feel the name "Jamstack" represents. That's what's really binding this otherwise heterogenous and diverse community together!

So let's find something new to argue about.

At the Jamstack Philly: Summer of Jamstack event that we organized on July 1 and August 4, 2021, the closing keynote argued that we'll see the next few years of Jamstack development marked by four major trends:

We'll take Astro's motto to heart and start seriously shipping less JavaScript. That means going back to the simplicity and bare-bones, lightweight structure of the first Jamstack tools (like Jekyll) while retaining all the functionality of the big platforms that came later (like Next.JS).
We'll help non-developers to work with us on equal footing, finding ways to get them interacting with us in the same tools and codebases with clever and intuitive GUIs.
We'll see tools that we've come to love like Netlify or Vercel start to separate from the pack with platform-specific features in order to stay relevant.
We'll adopt new terminology for the newest techniques we're using (for example, DPR) that are far less specific — in other words, get rid of that spectrum entirely. Some are suggesting calling it just "modern" development.

Let's talk about those! Let's ask new questions to keep the process of consensus going:

How far can we push HTML and CSS (and WASM?) to replace the need for the slow and burdensome JavaScript?
What tools can we create to remove the encumbrances of our non-developer colleagues and help them work with us on the same plane?
If platforms have to innovate independently to stay in business, how can they maintain the cross-platform values that the Jamstack is based upon?
If the term Jamstack grows insufficient as we consider more and more practices "best" outside of that immediate category, what terminology will we use to describe what we're doing?

Here at TakeShape, we're putting our money where our mouth is and investing in the future tooling of the Jamstack. We're building out a concept called an API mesh: a tool to stitch together the inconsistent APIs and external services we use all the time in the Jamstack. That's one of the most common tasks we use serverless functions for, and it sure has never been a simple task. All those inconsistencies make merging the data from those disparate services quite a bear, but by offloading that difficulty to a third-party API mesh like TakeShape, you can get only the data you need from a single GraphQL endpoint. It's the key to modern Jamstack development and part of the answer to the four questions above.

We'd love to hear your thoughts on those four questions too! Make sure to tag us on Twitter at @TakeShapeIO and @jadenguitarman with your thoughts and check out our site at TakeShape.io to learn more about our plans.

The quest for a single API: one kid's journey into devrel

Jaden Baptista — Fri, 13 Aug 2021 22:00:33 +0000

The quest for a single API: one kid's journey into devrel

So I decided to mess around with GPT-3 the other day. I typed in APIs are, and here's an excerpt of what I got back:

The lack of standards makes it difficult to provide users with consistent experiences.

sighs Even artificial intelligence gets it. APIs are tough to use because they're not consistent.

That's not to say nobody has tried.

The first APIs used XML as a data transmission system, which gave it some semblance of structure. Later on we came up with REST, and that worked for a while, but it got a bit out of hand.

There are some logical issues with REST. For example, think about Stripe's API (one of my favorites). They expose the ability to retrieve both one customer as well as a list of customers. How should Stripe handle this? Should the API expose two endpoints, /customer and /customers? Should the API use two different HTTP methods? Should they use a GET parameter to tell the difference? Should it just always return a list and force the client to sort through the data if they only want one customer? Should there be something in the headers to signify what the client is asking for? There's really no ideal answer, so most API makers handle cases like this differently.

GraphQL is the latest big attempt to resolve this issue, and it does a fantastic job. Just in case you're not up to date on GraphQL, it's a standard by which we send a single endpoint a JSON-like object without values, and then the server fills in the values and returns proper JSON. You get to request whatever data you want, and only as much as you want, as opposed to a REST query where you often ask for a haiku and get served War and Peace. There's just one problem: practically nobody uses it. If you zoom out a bit and look at the whole API landscape, it seems that many of the APIs we'd actually want to use regularly don't have GraphQL endpoints. That's a real bummer, because it would drastically improve the developer experience on so many existing APIs.

My background in development

But that's not what this article is about! It's called "The Quest for a Single API", a tale of my frustration with acquiescence to the inconsistencies of the API world and my mission to find a better way. And let's be honest, if I hadn't found a better way, I wouldn't be writing this article. But as all good storytelling questors must, I'll jump back to the beginning for you:

Back in 2018, I started development on a project called Sidus, a social media app meant to work in schools and as a general education platform. I was cyberschooled, and I always felt like there needed to be something to fill that social aspect of the typical brick-and-mortar school in a virtual setting. The team I helped assemble — made up of my classmates and a faculty member or two — seemed invincible. There were two developers (including myself) and three graphic designers; things were chugging along smoothly after we worked out some kinks in our team workflow. Before long, the other dev and I ran into a speed bump though. We were trying to fetch data from datasources like an external Redis DB, an external Postgres Db, as well as interacting with the Google APIs. This started to get a bit unwieldy because we'd have the same code repeated over and over again in different functions and files, and we'd be repeatedly reaching deep into nested returned objects trying to pull a single string out of that mess. Eventually, the other developer burned out, which caused me to take on his half of the work, which meant that development stalled out while I tried to sell the product to the potential clients (spoiler alert, this didn't happen) and find new developers to help out with the project. While I was scrambling, the designers found fewer and fewer things to do, and eventually the half-baked project was left solely in my hands and without any customers.

In 2019, I decided to repurpose the app into something more Intercom-ish, which turned out as a flop as well. I was also taking webdev college courses at the time and dabbling in a lot of APIs. Between the Sidus-clone and the college coursework, my day job as a PHP developer and yet another hobby project, I was burnt out on APIs. At one point I was dreaming about a specific API problem I was facing, and then realized that I was dreaming about using the wrong API for the task. It was terrible. But that Sidus app turned me onto a new idea: what if I could build my API so that you could ask it for a specific set of type-validated data? I actually created a whole framework to do this... and then somebody told me I had reinvented GraphQL.

One of my college courses required that I build a website for a local non-profit (which ended up not wanting the free website, so that was a blow), and I needed a CMS for it. Before long, I had come across TakeShape CMS and incorporated it into the site. I found the GUI uniquely intuitive and powerful.

So now I've got the main ingredients here: a newfound passion for GraphQL and a burdening panoply of necessary APIs. That, and the solution had been dropped right in my lap in the form of TakeShape's API Mesh technology. They invented this concept where you plug all of your existing APIs (including REST and GraphQL) into a single tool, called a mesh. I like to think of it like a phone operator's switchboard, where they can plug all the lines in and create a group call so a single caller can hear all the others all at once. That's kinda what the API mesh is doing: merging all your API "callers" into a single line so that you don't have to call them all separately. Genius, right?

And there it was: my single API. Every API I wanted to use, combined into one, ready for me to build whatever crazy idea-de-jour popped into my head.

My journey into developer relations

One day — specifically March 3, 2021 — the idea-de-jour was to peruse AngelList (a job listing site for startups), find a company whose product I could really get behind, and apply to become their developer advocate. I'd make a living helping other devs learn about something that improved my life as a dev! "How wonderful that would be", I thought. And lo and behold, look what popped up on my AngelList feed:

Well, what a coincidence.

The concept that served as the destination of a multi-year quest, the culmination of my first journey as a developer, needed a mascot. The disabled "Apply" button probably spoiled the ending, but I was so excited to hear about this opportunity that I almost broke my trackpad trying to click it. Soon enough, the awesome Mark Catalano, CEO of TakeShape, reached out to me and we set up some interviews. By May, I was hired and setting up the first Jamstack Philly event.

That's my story! That's my quest for a single API to rule all the others. That's my journey into developer advocacy. That's how I got from just some 15-year-old kid in high school trying to get a handle on Stripe to some 18-year-old kid repping the next big thing in web development. And get this: the job posting is still up! So if you want to join me at TakeShape and help us get the API mesh out there into the world, check out the Careers page on our website.

API vs. Microservices: A Beginners Guide to Understand Them

Jaden Baptista — Thu, 22 Jul 2021 17:24:56 +0000

Not so long ago, the technology used to build a website was quite simple.

HTML, CSS, and JavaScript were all you needed in the good old days. And most of the time, you didn’t even need the last one!

But now, things are getting a bit more complex. You have all these new techniques and technology you need to keep track of. While they might be confusing at first, learning about them can help make us more productive developers.

One of these concepts we hear a lot about nowadays is the microservice architecture. It caused quite a stir, especially recently, because it's not usually explained well...

Even experienced developers have no idea what microservices are, and that's alright. Usually, when asked about what they think microservices are, most web developers are going to say something like:

Doesn't that have something to do with APIs?

The answer is kind of. In the Jamstack world, we often talk about them as the same thing, but really they're complementary concepts. Learning about each idea's details can help us, especially when we only need one between APIs vs. microservices.

Let's explore these two concepts. We'll start with the dictionary definitions, but don't worry. I'll move past the janky jargon and get to the meat of it in a bit.

What are API and microservice?

API stands for Application Programming Interface. According to Wikipedia, an API "defines interactions between multiple software applications. It defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc." In the web development world, we most often use APIs that can be accessed through the Internet.

Microservices are, according to microservices.io, pieces of "an architectural style that structures an application as a collection of services that are highly maintainable and testable, loosely coupled, independently deployable, organized around business capabilities, [and] owned by a small team."

These definitions might seem a bit obtuse, so here's how I would define them:

API stands for Application Programming Interface. APIs define how two pieces of software can connect and talk to each other. If your application were a big company, your API's job would be to keep in touch with external parties (customers or company partners, for example). Most APIs are organized around some standard, like REST or GraphQL, so that everybody knows how to use them.

Microservices are pieces of software (often just isolated functions) that do a single, tiny, independent part of a bigger application. If your application were a big company, each employee would be a microservice, each playing their own specific and small role, working alongside but independently from their coworkers. This lets you make changes to individual microservices without affecting the rest of the application. In a big company replacing or retasking one employee in a large team would probably not affect the rest of the company all that much.

It's the evolution of the monolith architecture. Instead of having one block composing the whole application, every component is divided into smaller building blocks.

Put like that, does it make a bit more sense how they're different and how they can work together?

What APIs and microservices actually means IRL

Let's dive into a more practical use case to help you understand furthermore.

Say I've got this completely original payment processor service that I'm calling Tripe (you know, because it's a silly idea, not because I got inspired by any existing company in particular 😉).

There's a ton of little bits of functionality that this application is going to need. Here are some off the top of my head:

Reading from the database
Inserting into or updating the database
Creating invoice PDFs
Contacting the banks
Scheduling a recurring task for subscriptions
Running an actual transaction
Sending emails

All these little pieces of functionality are given their own functions and are all maintained separately. Boom—that's the microservice architecture in a nutshell. All of those individual tasks are microservices. That makes debugging way easier, too, since you can narrow down the problem to a single function almost immediately. And that's awesome if you're like me and hate debugging:

Let's go further with this. Tripe will probably let their users trigger some of these functions, right? Creating invoices, customers profile, subscriptions, charges, and returns are five actions the user can start, and all of them would use some of the microservices mentioned above. So the solution here would be to create five new microservices, one for each of the new actions we're exposing to the outside world.

For example, the new invoicing microservice would call the microservice reading the database, then the one that makes the PDFs, and then the one sending emails. You could think of it in terms of that analogy I gave earlier about the big company; you could have some employees whose whole job is to collect work done by their coworkers to present to people outside the company. Essentially we're creating a set of microservices that collect work done by other microservices and deliver it to users across the Internet. They only exist to interface between your application and the outside world via programmed HTTP requests.

Sound familiar? Well, it's because that's an API!

Quick sidenote: An API is technically how any two programs (including microservices themselves) communicate, but in web development, we usually mean an HTTP-facing API. An API follows a protocol like REST or GraphQL to expose data and functionality to the wider Internet. When I talk about an API in this article, that's what I'm referring to, though it's useful to know that the definition is pretty wide.

Those five microservices let users directly access Tripe's API. Not every microservice has to be part of an API, just like how not every employee needs to be part of the team communicating with customers. Many employees just do internal tasks and help out the customer-facing workers, just like how many microservices only do internal tasks or help out the API functions. There are also many ways to make an API without using microservices, so these technologies are more complementary than competing.

Let's make this more visual with the helping hand of a diagram!

Tripe's architecture would look something like this:

Our totally fictional payment processor Tripe's totally fictional architecture.
Note that the microservices are squares, and the third parties (customers, banks, etc.) are circular.

This looks a little complex on the surface, but it's a payment processor, after all. I wouldn't really be comfortable giving my credit card information to anything simpler than this...

Let's go through the columns one by one. On the far left, we have Tripe's users. They only have access to the microservices in the External API column. Combined, the endpoints in the second column (External API) make up the API. They're the only microservices with a defined way to talk to the users (through specific JSON objects set by the API docs, for example). They individually accomplish tasks independently and use some other microservices (in the Business Logic column) to do tasks users aren't allowed to trigger directly. Most business logic functions also call each other, demonstrating that the whole Tripe application is broken down into its tiniest, reusable, isolated, independent pieces.

Building your application with microservices reduces complexity and makes maintenance a lot easier because you can edit these little pieces individually. It's like building a site out of Legos: if you don't like one of them, you can just replace it and leave the rest of the site intact. That means your technical debt goes down to almost nothing, and if you keep with this approach, you'll never run into one of those lose-lose architecture dilemmas that we all hate.

Microservices and APIs real-world applications

Our Tripe graph might look pretty complex because of all the lines, but it was relatively simple when matched up against the same graph for bigger companies like Amazon or Netflix:

Microservice node graphs for Amazon and Netflix. Source: Divante

The structure starts to get a bit unwieldy to look at, but it's far easier to work with. The article where the image is taking from jokes that the Amazon microservice node graph "looks almost like a Death Star, but is way more powerful."

When you think about it, this architecture makes perfect sense for big companies like Amazon and Netflix. Their developers don't have to edit the entire codebase or redeploy the entire site when they want to make an update. Netflix's engineers, for example, are improving their product 24/7. Imagine if they had to take down the site for just a moment whenever they wanted an internal feature added. Netflix would be down constantly; bye-bye binge-watching! 😧

Instead, they only have to work with one manageable chunk of code at a time, just one of the dots on that graph.

In contrast, think about how few of the nodes on Netflix’s graph of microservices are actually meant to communicate with the outside world. Netflix has been revising their API lately so I couldn’t figure out exactly how many of the nodes are facing outward. However, it’s still quite a small amount compared to the number of microservices they actually use internally. Take this image, for example:

Source

Here's the accompanying explanation:

Suppose a user clicks the "play" button for Stranger Things Episode 1 on their mobile phone. For playback to begin, the mobile phone sends a "play" request to the API. The API, in turn, calls several microservices under the hood. Some of these calls can be made in parallel because they don’t depend on each other. Others have to be sequenced in a specific order. The API contains all the logic to sequence and parallelize the calls as necessary. The device, in turn, doesn’t need to know anything about the orchestration that goes on under the hood when the customer clicks "play".

Interesting, right? I want to highlight one phrase in particular: "The API contains all the logic to sequence and parallelize the calls as necessary." This means that the client (person watching Netflix) called the API endpoint when they pressed the "play" button, which is, in itself, a microservice.

Side note: as I understand it, the API Netflix refers to here isn't available to the public. Remember, an API is just a defined way for "two pieces of software to connect and talk to each other". Those "two pieces of software" are, in this case, Netflix's backend and Netflix's frontend. It's still an API even if you and I can't use it over the Internet because that interaction between the frontend and the backend is given a structure and rules to follow. This is an important note to remember because it means that you've probably created more APIs than you realize in your career. Anytime we internally connect two services and give them a way to talk to one another, we're making one. We should be cognizant of that because it gives us a chance to think through our architecture before it gets out of hand.

TLDR; They're complimentary.

What's the conclusion? APIs can be made up, wholly or partially, out of microservices. Microservices can be used for a lot more, though. The original definition (the really wordy, nerdy one) called microservices pieces of "an architectural style". The whole application, business logic and all, can be broken down into tiny, reusable, single-purpose chunks of code, and that's the microservice architecture.

Here's a Venn diagram if you'd like another way to visualize it. As you can see, microservices can be an API (the overlapping of the circles), but APIs aren't necessarily a microservice.

Remember how I said earlier that some APIs are made up of microservices (like our fictional Tripe API), but they don't always have to work together? Some microservices aren't part of APIs (the right section on the Venn diagram), such as the business logic in our Tripe example, because they don't have to be accessible to the outside world. On the other hand, there are a ton of ways to make an API, and most of them don't involve microservices. Most of the web backends made with the traditional backend languages (PHP, Ruby, Java, etc.) are monolithic, a.k.a. not made of microservices. Even backends made with JavaScript can be monolithic if you don't separate all the functionality into their smallest pieces.

APIs and microservices are now massive parts of the modern web development process. We can't move forward without them. So if you're making your way past the traditional monolithic web architecture and/or want to learn more about how these newer technologies work together, here are some more links for additional education:

If you've got any other questions, feel free to reach out to me on Twitter or in the comments below. I'd love to hear from you!

Making Accessibility Accessible

Jaden Baptista — Wed, 07 Jul 2021 15:41:23 +0000

I'll be honest: I've never been very accessibility-minded. I deal with mild colorblindness, so I get the need for strong color contrast, but besides that, I've always felt like accessibility was beyond me. I thought it was just something for accessibility experts, not a real problem that I needed to consider in my daily development.

That is, until I interviewed some of those experts. I'm very grateful that they took some time to sit down with me, and boy, did I learn a lot. Here's a recap of three main lessons that I learned from my interviews with Tessa Mero, developer advocate from Cloudinary and Henri Helvetica, king of web performance and accessibility.

1. Accessibility is a dichotomy, not a spectrum.

A site is either accessible or non-accessible. It's actually quite binary, since a partially-accessible site is still non-accessible. If you can't access all the features as a limited user (that includes human disabilities as well as those on devices with limited ability), then your site isn't accessible. As a way of testing our websites for potential hiccups, Henri proposed asking ourselves this question:

Can you achieve digitally, with some accessibility-related limitation, what you would have been reasonably able to do in person?

For example, imagine a banking website where you can do anything you would be able to do at a typical bank in person (within reason, of course). All of those features can be used by someone with accessibility challenges except for one: cashing a check. That's fairly simple to do at a bank (you can just hand the teller your check), but on the website, that might require the user to line up the check perfectly in their phone's camera view, which is nearly impossible if the user is blind. That's not accessible! The user could not achieve digitally, with their limitation, what they would have been able to do in person. Fixing this is quite a large task, as it would probably require rethinking the use of the camera in the first place, but asking the above question and identifying this as a potential problem area is the first step towards making their site usable by all.

2. It can be illegal to make a non-accessible site.

Do you remember the time a blind man sued Domino's Pizza because he couldn't order online? Or the time a blind woman from New York sued Beyonce because she couldn't keep up with the singer's latest news and products as easily as someone who could see?

The American Disabilities Act (and there are roughly equivalent laws in other countries, though details vary) requires that businesses that meet certain criteria for size and purpose must then keep their websites accessible to the blind, the deaf, those who must navigate by voice (for example, the paralyzed), and those with other limiting disabilities. While the law (at least in the United States) doesn't explicitly state any rules on deciding whether a website is accessible or not, it's commonly accepted that accessible websites follow the Web Content Accessibility Guidelines as established by the World Wide Web Consortium (who also set the HTML, CSS, DOM, and WASM standards). While the actual guidelines are pretty obtuse, the best practices they advocate for are found in simpler form by reputable sources all over the Internet.

3. Accessibility and user experience are one and the same.

You might've noticed earlier that when I defined "limited users", I included those on devices with limited ability. That's because, while we often think of accessibility as making your site friendly for the blind, it actually means making your website friendly for anyone with any limitation, including but not limited to:

Users on mobile devices
Users with bad internet
Users who simply prefer having a site read to them by a screen reader
Users with browser extensions that mess with the page
Users with a slow computer
Users on old browsers that don't support the newest features
Users that have set their browsers to minimize the amount of motion on the screen
Users with a broken peripheral device

Those are just the technological impairments that many of our users could potentially be dealing with. And that's in addition to the potential human disabilities they may face:

Users who have vision impairments, who might not see a button if it doesn't contrast enough with the background or if it can't be focused with a screen reader
Users who cannot hear well, who might not understand instructions if they only come in non-captioned video form
Users who must navigate the Internet by voice, who may not be able to click a link if a non-semantic tag is used instead of <a>
Users who don't intuit the things we might expect the user to know, who may not understand, for example, what a Share button looks like
Users with short-term memory impairments, who might not remember where they're supposed to click in your complex navigation
Users with perceptual disabilities like dyslexia, who may not be able to read our site if the font is too small or too thin
Users with tremors, dystrophy, arthritis, or some form of reduced dexterity, who may not be able to accurately move the mouse to keep hover-operated tooltips open

Truly, accessibility and user experience are one and the same, since the experience of such a wide swath of our users — over half are on mobile, for example — depends on us paying attention to their limitations, technological or human.

What I learned

I really enjoyed my chats with Tessa and Henri over on my Twitch channel. They taught me ways to expand my checklist for site-building to include considerations for the limited experiences I previously hadn't thought to test. The biggest lesson I got from these conversations was that accessibility and user experience require a lot of thought and care, even more than I had realized. Unfortunately, that makes it hard to also focus on your site's performance and underlying architecture, which is where TakeShape comes in. TakeShape's API Mesh enables front-end developers to harness the power of the Jamstack to reduce site complexity and ship faster, so your time is freed up to hone what matters the most: your user experience.

I actually learn a lot about a wide variety of subjects from these interviews, like the lessons Mark Lane discovered as he built several successful SaSS tools or that time I found that data and content modeling is actually a fascinating subject when Jeff Eaton is talking about it. If you're interested in catching the interviews live, keep an eye on my Twitter (@jadenguitarman) and Twitch (jadenbaptista).

Recordings of the interviews can be found on YouTube:

Henri Helvetica: https://www.youtube.com/watch?v=4Kpz6vHvuao&list=PLAF51ew9HblEE8dQepEEQKSw_03gBdU1L&index=6

Tessa Mero: https://www.youtube.com/watch?v=x3leuusTeSQ&list=PLAF51ew9HblEE8dQepEEQKSw_03gBdU1L&index=3

Our 8 favorite tools for monetizing your Jamstack website

Jaden Baptista — Sat, 12 Jun 2021 01:41:30 +0000

The Jamstack and ecommerce are a lot like chocolate and avocado. At first, they don't sound like they'll go together, but they actually work really well; once you try it and realize the potential, you'll find that there's a whole community of people ready to share their amazing recipes on how to make them taste great together. In the same way, the Jamstack can sometimes appear incompatible with ecommerce, but it doesn't have to be! Here are our top ten favorite tools to help you start selling on your Jamstack site:

TakeShape

TakeShape's API Mesh enables front-end developers to harness the power of the Jamstack by stitching together multiple external APIs with an intuitive internal CMS. I've actually been working on a series of livestreams about hydrating a product page with content from the TakeShape CMS and pricing data from Stripe, and while that might seem complex, TakeShape handles it smoothly. I just have to make one GraphQL request, and exactly the data I need arrives at the client, regardless of where that data originally came from. I wrote a summary article about those streams so you can see the process; you can check it out here.

I'm a little biased towards TakeShape, so I'll skip the ratings for this one, but I honestly love it; I'm including it in almost every project nowadays and think it's awesome.

Stripe

The whole point of ecommerce is to make money, so you need a tool to collect payment information and actually charge your customers. Stripe is the gold standard here. It's super simple to use, especially with the kits and libraries they provide, like Checkout and Elements. Their documentation is best-in-class, and their developer support team is the most helpful I've ever had to deal with.

Some more complicated setups can start getting difficult to manage, as Stripe locks you to using their system of products, subscriptions, prices, and customers, but that system is more than adequate for the vast majority of use cases. You do have to use something on the server-side for this, since Stripe requires that you keep one of your API keys secret for obvious reasons. On the Jamstack, that means running it on a host that supports serverless functions or funneling the requests to Stripe through an API Mesh like TakeShape.

All in all, I give Stripe a 9.5/10 based on its incredible developer experience.

Snipcart

Snipcart's tagline is Add a shopping cart to any website. It sure is bold, but they live up to that claim: devs from big names like Fiverr to small ecom sites are turning to Snipcart to make selling on the Internet easier. Using just HTML and JavaScript, you can inject a cart onto your site, define some attributes to describe whatever you're selling, and hook up your "Add To Cart" button. It's really that simple. DX is definitely important, but if the product manager still needs a little more convincing, you can tell them that it's portable (it's not stuck to any specific stack) and will speed up your development by working with your existing site. A lot of the tools in this market require you to build the site to work with the tool, but Snipcart has no such requirements.

Snipcart is flexible enough to handle almost any use case well, but there are some situations where you might be better off reaching for a more low-level tool. For example, I was looking into building a marketplace, and the guys from Snipcart told me that having money moving from a buyer to a seller would be difficult to implement without the money first going through a single account, which opens you up to higher transaction fees and getting taxed on those transactions differently depending on your jurisdiction.

Snipcart isn't the magic solution to every ecommerce need, but it absolutely nails its intended functionality, so I can confidently give this a 10/10.

Memberful

Ecommerce is more than just paying for a product online; one of the core concepts in ecom is the membership subscription. Memberful aims to simplify and abstract away the difficulty of this often tricky payment model, and man, does it succeed. Take a look at this guide for an example of its simplicity. It's definitely designed with non-developers in mind, so this will be a perfect fit for you if you're trying to paywall content on a larger site with dedicated content managers, if you're working on a site without a backend (like a Jamstack site), or with a Wordpress site (they've got an excellent and well-maintained plugin).

One thing I like about Memberful is that they're honest about their tool not being for everyone. In their own words, "we'd rather recommend a competitor that’s a better fit for your business than try to hard sell you on Memberful." They go on to list some situations where Memberful might be a little tougher to use and then they offer some better alternatives. For example, Memberful works best on digital content, so if you're selling physical products via an online experience (like Butcher Box or Dollar Shave Club), you might be better off with an all-in-one solution like Square.

It's less flexible than other solutions, but Memberful takes the master-of-one over the jack-of-all-trades approach, so they make up for it by perfecting their core feature set. They've definitely earned my approval: 9/10.

Auth0

Authentication is really hard to get right, and no matter how many times I try to roll it myself, I always fail. But then I heard about Auth0, and I believe I physically sighed in relief. They just give you a login system with best practices built right in, something I was really bad at building previously. Their security experts have already worked out solutions to fraud and other problems that modern ecommerce platforms are bound to face at some point or another.

That said, Auth0 can be difficult to get started with. It takes a bit of knowledge about those best practices to use Auth0's platform correctly without introducing more bugs and vulnerabilities. Thankfully, they've taken care of this by creating an excellent store of educational content on this topic to make integrating with them far easier. If you're interested in learning about how to work with Auth0, the best place to start is their blog.

With that said, it's the most powerful solution to one of the most common problems on the Internet: authentication. Auth0 earns a 8/10 from me.

Foxy.io (FoxyCart)

If Snipcart is the easy-to-use, build-into-your-existing-website shopping cart solution, Foxy.io is the super-powerful, only-for-devs, uber-customizable shopping cart solution. It's not better, just different from Snipcart, and so we use it in different scenarios. Perhaps when our small-town Mama's Pizza wants to start selling their pizzas online, Snipcart would be best, but Foxy.io might be the powerhouse needed to turn the gears behind BestBuy's website (large, but still with a single seller). Foxy.io doesn't manage inventory, while Snipcart does. Large sites like BestBuy likely are already handling that with a custom inventory solution, while something small like Mama's Pizza might make use of the inventory features of Snipcart to store their limited slate of pizza options. Foxy.io also can handle more payment gateways, which is unnecessary for smaller sites but could be critical for something as large as BestBuy.

I really like how they put it on this page: "FoxyCart is not a turnkey solution. This generally makes FoxyCart perfect for some and just plain wrong for others." I couldn't have said it better; Foxy.io (what they call it now) does the cart and checkout really well, but if that's not the largest part and central focus of your website, then you might be better off with a simple solution like Snipcart.

It's perfect for a small set of ecommerce sites, but go with Snipcart for everything else. I give it a solid 6/10 though.

SendGrid

Ah, SendGrid. Where were you all my life? Emailing is super difficult. The World Wide Web has evolved for the last 25 years, but the whole emailing system is stuck in 1996. SendGrid is kind of like a translator between that nonsense we had to deal with ages ago and the modern way we work with APIs. With customer outreach, support, and marketing being such a big part of the ecommerce world, tools that can make emailing easy like SendGrid have become absolutely indispensable. There's not that much to say about SendGrid other than the fact that they're trusted with handling crucial parts of the architecture of big websites like eBay, Nextdoor, Uber, AirBNB, and Yelp.

It does lean more towards being developer-friendly over content-creator-friendly, so you might find the interface a bit clunky if you're using SendGrid for blast emailing at a bigger company with dedicated marketers. It also looks like they funnel a lot of resources into development, which leaves customer support to focus on the biggest customers, so some smaller users have reported long stretches of time going by before hearing back from them.

Overall, I love SendGrid, and despite its minor flaws, it's always worked well for me. I give this one a 9.5/10.

Shopify

You were expecting this one, weren't you? I'll admit, I used to rail against Shopify, and I still have my qualms, but I've come to see just how powerful it can be. It's probably the least technical tool on this list, so that immediately opens up all sorts of possibilities to non-developers. That's quite important to a lot of web development agencies as their developers then don't have to be bogged down with minor updates and can focus on future development, depending on how much you've customized the templates they give you. There's a massive community (as one would expect the largest ecommerce solution to garner), and they've created all sorts of plugins and templates to make the developer's job even easier.

There is a caveat in that last pro, though. The plugin system can put the stability of your website in the hands of others, and we've seen that go well — and occasionally very, very badly — for Wordpress. Using plugins like this can open you up to vulnerabilities exposed by the plugin authors (who can be sometimes slow to fix them), so make sure to only use plugins created by companies you trust. Shopify also tends to be more of a platform than an add-on tool, so while you get the convenience of using prebuilt templates, it's much harder to customize and add non-ecommerce content. Many ecommerce companies run blogs or other informational pages, which aren't so easy to implement (it's definitely possible though!). Lastly, there's the fees. On top of the fee to use Shopify (which can be anywhere from $9 - $2000 depending on your needs), you'll likely be paying a fee on every transaction (plus your payment processor's fee).

I've grown to enjoy Shopify recently, but for many it's an acquired taste. Given just how powerful it can be, I'll give it a 7/10.

There you have it! That's my favorite 8 tools for turning a profit from your Jamstack site. It might've been historically difficult to combine ecommerce and the simplicity of the Jamstack, but thanks to tools like these 8, I'm hopeful that we'll be seeing more amazing ecommerce Jamstack experiences on the web in the future.

If you've got any questions about TakeShape or about the list in general, feel free to contact us on Twitter (@TakeShapeIO, @jadenguitarman) or at takeshape.io.

Using API Mesh to Streamline Ecommerce Development - A Stream Summary

Jaden Baptista — Mon, 24 May 2021 16:28:39 +0000

A recap of a two-part stream held over on twitch.tv/jadenbaptista

Launching an ecommerce experience involves many different stakeholders. Developers, designers, product manager, content producers, marketers and merchandisers, each bring their own niche tools and workflows to the challenge to help them do their jobs better. For example, a marketer will usually prefer to use SendGrid over a custom internal emailing tool because it's more developed and easier to use. It's the same reason why product managers like using Github Issues, content producers like using a CMS, and merchandisers like using Shopify. It's up to developers to make all the different pieces fit into a single cohesive customer experience. This can be a real obstacle! Usually it requires backend development work and managing your own infrastructure, or at least it forces you to cobble some plugins together in WordPress or Shopify.

However, in the age of the Jamstack, there is a new way for front-end developers to solve this challenge. It's called an API Mesh.

Term definition: an API Mesh is kind of like a switchboard for APIs. You can set it up so that all the data and functionality you'd normally ping an API for (for example, from a CMS, or from Stripe, or from another other REST or GraphQL API) and pipe it into TakeShape (the original API Mesh). Then with one GraphQL request to TakeShape, you can access whatever data or functionality you ask it for, regardless of its original source.

The Plan

In a recent two-part stream over on my Twitch, I demonstrated the process of collecting data from multiple sources and using it to fill out a product page right on the client-side with TakeShape's API Mesh. The first part of the stream was mostly about planning, so here's what I came up with:

I decided that the majority of the data about the product itself should be stored in TakeShape's CMS (it's helpfully bundled in the same suite of tools as the API Mesh and a static site generator), while any data about pricing should be stored in Stripe. That last part might seem a bit strange to anyone who's used to working with traditional databases like MySQL: you'd think it would be better to have all the information about the product available from a single source, right?

Actually, it turns out that keeping all that product data in one place isn't necessary. Stripe makes for a good example here, since your pricing data is going to have to be stored there anyways if you're going to charge people using Stripe. If you have the price stored in your database (or CMS) along with all the other product data, then there will be some period of time — like when you're changing how much something costs — when it doesn't match exactly with the price you've got in Stripe. Then suddenly you've found yourself in a situation where you're advertising one price but charging the customer another.

To avoid scary situations like this, we need to keep Stripe as the single source of truth for any piece of data it reasonably should control. All of our prices and money-related data ought to be kept there and only there, while any other product attributes (like title, description, image, etc) could stay in the CMS.

The Steps

Fill our data sources with data.

This was actually the easy part, since I just borrowed one of TakeShape's awesome starter kits on Github (I used this one). It came with everything I needed to get started, so I didn't have to do much setup. I actually ended up deleting 6 of the 9 products that came with the starter project, just for simplicity. After creating a new Stripe account, I created a product and a price in Stripe for each of the remaining sellable items, and called it done.
Tell the API Mesh about all of our sources.

The API Mesh needs to know where to collect data from if it's going to deliver it to us in one neat little packet, so we've got to give it our Stripe credentials and instructions on how to use their API. Now this might sound a bit complex, but it's really not; I went through this process live on the stream, and even with my impulsive rambling, it barely took 10 minutes.

All we really have to do is define these data sources as services in TakeShape. They're listed under the Schema tab. Just click the "Connect Service" button to add a new one.

To add a new service, click the Schema tab, and then the Connect Service button.

It'll walk you through a simple form just asking for the name of the service, the root endpoint (that's [api.stripe.com](http://api.stripe.com) in my case), and your auth details. Make sure to read the docs of the API you're using (here in my case) and the little note on the TakeShape form to make sure you're putting the right credentials in the right fields. In my initial stream, I made a tiny mistake here and used the wrong auth type. It wasn't a big deal; I just had to spend 5 minutes correcting it in the second stream.
Tell the API Mesh to stitch data from those sources into one request.

For this, we're going to jump into a little bit of JSON. Click the Export button on the Schema page to download the JSON that represents your entire project.

Click the Export button on the Schema page to download JSON that represents your entire project.

The JSON it downloads might seem a bit unwieldy, but luckily most of it isn't relevant at the moment, so I use my code editor to fold a lot of it up so I can focus on what's important right now:

My folded-up, simple view of the JSON schema that represents my whole project

See the Stripe service we added earlier? The TakeShape GUI just edited this JSON file for us. For the queries, shapes, and forms, we're going to do essentially the same thing, except we're just going to edit the JSON file ourselves.

The first step for me was to go into the Product form and remove any property that mentions price data, since we're going to keep that in Stripe. If you're following along, make sure to check the order list too. Do the same thing in the Product shape, making sure to check the required list as well (that was another thing I briefly forgot about in the livestream, which I had to spend a minute or two correcting).

Next, we've got to add a property to the Product shape called productId, which would look something like this:
```
"productId": {
    "type": "string",
    "title": "Product ID",
    "minLength": 1
}
```
That goes in the properties array under the Product shape.

The whole point of using this API Mesh in the first place was to help us developers stitch together all the tools our coworkers are using, so we've got to give whoever is in charge of maintaining the product entries the ability to enter the Stripe product ID into the CMS. TakeShape's CMS just displays forms to the user, which they can fill out to edit the product (or whatever other thing they're editing). So earlier, when we removed the price data from the Product form, we were removing the ability for our coworkers to add the price directly into TakeShape's CMS. Now that we want to let them add the Stripe product ID, we're going to add a new property to the Product form:
```
"productId": {
    "widget": "singleLineText"
}
```
Now here comes the toughest part, though it's still fairly straightforward. We want TakeShape to automatically pull in price data from Stripe whenever we ask it about a product. In other words, we're asking TakeShape to resolve the product to its appropriate price data from Stripe. In line with that, let's give TakeShape a resolver so it knows what data to give us.

Go back to that Product shape and add this property:
```
"priceData": {
    "type": "object",
    "properties": {
        "inCents": {
            "type": "number"
        }
    },
    "title": "Price Data",
    "@resolver": {
        "name": "rest:get",
        "service": "stripe",
        "options": {
            "fieldName": "priceData",
            "path": "v1/prices"
        },
        "argsMapping": {
            "searchParams.product": [
                [
                    "jsonPath",
                    {
                        "path": "$.source.productId"
                    }
                ]
            ]
        },
        "resultsMapping": {
            "inCents": [
                [
                    "jsonPath",
                    {
                        "path": "steps[0].data[0].unit_amount"
                    }
                ]
            ]
        }
    }
}
```
Here's a little breakdown for the curious:
1. First, we define that this is going to be an object, and that it'll have one property of its own called inCents, which will be a number.
2. Then, we tell it to get information from a GET request to the stripe service we defined earlier, at the /v1/prices endpoint.
3. Then, the API mesh is instructed to send the productID of this particular product into Stripe as a search parameter.
4. Lastly, we're asking that the unit_amount buried in Stripe's response be piped into that inCents property we defined earlier, so that our end result ends up nice and tidy.
We're done with this file, so just reimport that JSON file back into TakeShape and let the API Mesh do its thing.

Fill our product page with data from the API Mesh.

If we're going to hydrate our product page on the client, then we need to first request the data from our API Mesh. The GraphQL query we're sending to TakeShape would look something like this:

const query = `{
    getProductList {
        items {
            description
                image {
                    sourceUrl
                }
                name
                priceData {
                    inCents
                }
                category {
                    searchSummary
                }
                soldOut
            }
        }
    }`;

Here's the function I wrote to actually send that request:

const getMeMyData = async index => {
    let req = await fetch(
        `https://api.takeshape.io/project/${TS_PRODUCT_ID}/v3/graphql`, 
        {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Authorization': `Bearer ${TS_API_KEY}`
            },
            body: JSON.stringify({ query })
        }
    );

    let result = await req.json();
    return result.data.getProductList.items[index];
};

And then here's the function that uses that data to hydrate my HTML:

const hydrateMePage = async productIndex => {
    const product_data = await getMeMyData(productIndex);

    document.getElementById("product-title").innerText = product_data.name;
    document.getElementById("product-description").innerText = product_data.description;

    let productImage = document.getElementById("product-image");
    productImage.src = product_data.image.sourceUrl;
    productImage.alt = product_data.name;

    document.querySelector(".product-price > span").innerText = "$" + (product_data.priceData.inCents / 100).toFixed(2);
    document.getElementById("product-category").innerText = product_data.category.searchSummary;
    if (product_data.soldOut) document.querySelector("main.container").classList.add("sold-out");
};

Those two small functions set us up to fill out our whole page with data from multiple sources without practically any technical debt. Just run a hydrateMePage(0) and it'll fill the page with data like magic; except that it's not magic, it's an API Mesh stitching together our CMS and Stripe data so we don't have to do the legwork of stitching it ourselves.

The Results

And with those four steps, we've suddenly created an entire data pipeline for our ecommerce website. To create a search results page, or a homepage, or anything else, we don't even have to replicate all the steps; depending on whether you need to add more sources or not, you'd just start from step 2 or 4.

If you're interested in seeing more builds like this, I stream over on my Twitch every Monday afternoon. We also talk with leaders in the web development community about their experiences with interactive interviews there on Thursday afternoons. Make sure to follow @takeshapeio and @jadenguitarman on Twitter to get the latest updates.

How to set up VSCode to work with TakeShape's Metaschema

Jaden Baptista — Wed, 12 May 2021 21:10:35 +0000

How to set up VSCode to work with TakeShape's Metaschema

Nobody likes typos in JSON. Let's make VSCode catch them for us when writing a TakeShape schema.

When writing JSON it's easy to fudge the syntax a bit, usually by missing a quote or a colon. Thankfully, coding tools like VSCode are good at catching these errors. However, a far sneakier problem to identify is when the format of the keys and values in a JSON file don't abide by the internal rules of a program that relies on the JSON you are writing. This can be easily solved by using a JSON metaschema to automatically validate JSON, which will give VSCode the power to warn you when your JSON doesn't match what TakeShape is expecting to be in a schema.json.

Term definition: TakeShape's metaschema is a JSON schema that VSCode can use to regulate TakeShape's schema.json files. It's a schema for a schema; hence, a "metaschema". TakeShape's metaschema can be found at https://schema.takeshape.io/project-schema

Setting up VSCode to use TakeShape's metaschema

In VSCode, go to your Preferences and find the settings.json file.

It's under the Settings button in the bottom left corner, under the Settings tab. You can also get there with the Cmd + , shortcut (Ctrl + , on Windows).

Search for json and click on the link that says Edit in settings.json.
Tell VSCode to use the TakeShape metaschema.

Add the following to the json.schemas array:
```
{
    "fileMatch": [
        "schema*json"
    ],
    "url": "https://schema.takeshape.io/project-schema"
}
```
In short, this tells VSCode to use the TakeShape metaschema on every file that matches schema*json, including — but not limited to — schema.json, schema.v2.jneiubciub.json, and schema.v4.json.
Test to make sure it works.

If you have a schema.json file handy, feel free to use that; otherwise, you can download one from any of the repos listed at https://github.com/takeshape/patterns.

You should see something like this, where you'll get a yellow squiggly warning line if you try to add a property to the schema that TakeShape won't know what to do with.

Now VSCode will optimize your workflow by reminding you of any typos in your schema.json right as you type them, instead of when you import the whole schema back into TakeShape later. If you have any trouble with this process, feel free to reach out to the TakeShape team by clicking the chat bubble in the bottom right corner of your screen.

Demystifying GraphQL Queries

Jaden Baptista — Tue, 27 Apr 2021 22:44:40 +0000

It's hard to learn new things, isn't it? When I first started to learn Python, it looked like an indiscriminately shuffled string of stray symbols. But eventually I learned; I connected it with concepts I knew from other languages. Later on, I learned JavaScript and went through the same thing; I didn't understand the syntax, so it just looked like a bunch of meaningless characters to me. But once I saw the similarities with languages I already understood, it started to click. I originally had the same reaction to GraphQL queries. It seemed difficult at first, but I came around after I realized the key to learning it was just like the technologies I'd learned before, and now I use it almost every day.

I'm just like every other developer: I want to learn new things but sometimes struggle with remembering the details and grasping the why of it all, so I figured I'd write this post to explain where I started with GraphQL and how I got to where I am now.

Step 1: Conceptualize the thing

I can't get anything done until I can work out what's happening in my head.

Me figuring out something new

I'm grateful though that someone explained GraphQL to me as REST adopting the baby of JSON and SQL. GraphQL is declarative, meaning that you get back what you ask for. No more, no less. When writing a GraphQL query, we're using a syntax that is similar to JSON or a TypeScript interface to define what information we want to get back in our response. Just like how we'd use SQL to define what data to retrieve from a database. Except instead of directly accessing a database with SQL, with GraphQL we're telling an API what information we're looking for.

My lack of understanding was the result of seeing GraphQL in action before knowing why someone would use it in the first place. At the time, I had been working on my own attempt at standardizing API responses in JavaScript, so GraphQL was really right up my alley; I just didn't know it. Once I understood that GraphQL could tackle the problems I was having, I realized it that I had to start learning the syntax. That takes me to step 2...

Step 2: Learn the thing

Once I wrapped my mind around the why of GraphQL, I had to grasp the how of GraphQL. There's a fantastic quickstart tutorial on the official GraphQL website, but I'll just show the basics:

Types. Say you want to get some user account information, but you want it to conform to a certain spec. Let's imagine that you want get their first and last name (both strings), their age (an integer, in years), their username (a string), and whether they're subscribed to your newsletter (a boolean). In plain JavaScript, this would be tough (or at least lengthy) to check manually:
```
// assume we've got everything in an object called "data"
if (
    (typeof data.first_name != "string" && data.first_name != null)
    || (typeof data.last_name != "string" && data.last_name != null)
    || (typeof data.age != "number" && data.age != null)
    || (typeof data.username != "string" && data.username != null)
    || (typeof data.subbed != "boolean" && data.subbed != null
) return "invalid";
```
Let's be honest, that's a bit excessive, isn't it? It's technically best practice, and in theory, it allows each field to be either its assigned datatype or null. It just doesn't scale though. Having this after every API request gets old fast.

GraphQL forces the API to define those datatypes, so you're guaranteed to get back what you're expecting. If the API says that first_name will be a String, it will come to me as a string or null. I can count on that in my application. They can even rule out null too, by making the datatype String! with the exclamation point. On their side, they're defining a type like this:
```
type User {
    first_name: String
    last_name: String
    age: Int
    username: String
    subbed: Bool
}
```
Again, the API does all of this, so we don't have to. We can just count on what's coming in and out.

When you start working with more advanced GraphQL queries, you might end up implementing types on the client-side too! Check out the types docs here on the GraphQL website for more information.
Queries. We talked about guaranteeing what types of data we'll get with GraphQL, but now we actually have to get that data, and we do it with queries. This is the part I was talking about when I said it looks like JSON and SQL. You just kind of give it the keys of the JSON object you're looking for, and it'll fill in the values, similar to how SQL fills in the data once you give it the columns you're selecting.

Say you're trying to retrieve user data from an API mesh like TakeShape, and it's set up so you can trust that the data you get back conforms to the type up above. A query for that would look something like this:
```
{
    getUser (id: f8a5123b9705c8c618043dc206b09c6a) {
        first_name
        last_name
        age
        username
        subbed
    }
}
```
You just give the GraphQL API the keys to the JSON object, and the API will just fill in the values. You can nest this too; say we had the user's first and last name in a nested object. The query might look something like this:
```
{
    getUser (id: f8a5123b9705c8c618043dc206b09c6a) {
        name {
            first
            last
        }
        age
        username
        subbed
    }
}
```
GraphQL is powerful enough to reach down into these nested objects and make sure that everything conforms to the type defined by the API. This way we don't have to worry about getting the wrong information or trying to do all that manual validation in JavaScript anymore.

This isn't my any means all the things you can do with GraphQL, but it's enough to get by on, especially if you're just consuming a GraphQL API like the one TakeShape's API mesh provides. If you're fascinated by the possibilities here, I'll point you back to the detailed guide on the official GraphQL website here.

Step 3: Use the thing

This is the part I struggle with the most. Finding the time and the right opportunity to use a new technology can be a challenge.

After conceptualizing something new, and learning the syntax, I want to jump head first and start using my newly earned knowledge on a big new project! But, alas, I know that wouldn't be wise. It's best to start tinkering on a low stakes project. I decided to start simple with a starter blog using TakeShape's GraphQL API. Playing in this sandbox was like learning Python again. Just pressing buttons, trying new things, and experimenting with different ideas. It wasn't planned or scripted, and there wasn't any particular thing I wanted to make; I was satisfied just exploring what I didn't know before.

That's the crux of my advice to anyone who is still having trouble demystifying GraphQL queries: just tinker. Experiment. Build something. Anything. You don't have to work it into some polished portfolio-worthy project; you just have to go beyond understanding the why and the how and get to actually using GraphQL.

I hope this guide helped you to go through the same journey with GraphQL queries that I did: conceptualizing it, then learning the syntax, and then using it in a project. I wouldn't call myself an expert, but I think I'm a better developer for having gone through the process I outlined here, and I hope you'll feel the same. If you're looking for a place to dive into GraphQL more, I've littered this article with links and references to the official GraphQL guide and TakeShape, an easy-to-use example of a GraphQL API.

If you have any questions, feel free to reach out to me at jaden@baptista.dev.