Forem: Stephanie Smith

GraphQL Intro

Stephanie Smith — Mon, 13 Jul 2020 23:27:13 +0000

Grabbing data from an API endpoint can be simple if you only need a couple of bits of data from it. Like with JSONPlaceholder, an API where you can fetch fake data. From their /users endpoint, you could simply grab the name of that user and their email. What about when you find a more complex API, and need more than just a couple of values? There would be a lot more data, a lot more endpoints, and therefore a lot more requests to make!

An example of this is if we were to fetch data from an API that has information on books. If you were to pass in the name of the book in an endpoint example.com/api/book/:title, you would receive data about that book, such as the bookId, authorId, genre, and blurb.
If you wanted to get information about the author, you would have to make another request that inputs the author's id in the endpoint example.com/api/author/:id. You would get the information you need, but this takes two requests to achieve, which is tedious and, given a lot more requests than this, can be hard to follow or understand. This is where GraphQL shines!

What is GraphQL?

GraphQL is a query language for API's developed by Facebook, and it allows developers to create more understandable API's as well as fetching data from them more easily. It's also a server-side runtime for executing queries. For those that would like to describe the type of data they should get back, GraphQL uses typing to do so as well!
Using the book API example, this is how it would look:

{
  book(bookTitle: "Hello World!") {
    author(id: 50273) {
      name
      age
    }
    id
    genre
    blurb
  }
}

What are the benefits of using GraphQL?

Did you notice in the code snippet above, we are passing in the author's id? That's because with GraphQL, we can request as much data as we need in one query! Given the author id that we get back from that book, we can pass it in our query and also get the data from it. If the author had yet another set of id's, we could get the data from those as well! The beauty of GraphQL is that it's easy to send a query all in one go, which can be easier to read and understand.

You can also be selective with the data you get back! If you didn't need the blurb property nor the age property from the API, we can simply omit it. The new query would look something like this:

{
  book(bookTitle: "Hello World!") {
    author(id: 50273) {
      name
    }
    id
    genre
  }
}

This allows a developer to be more flexible with their requests, and also saves space for data that they actually need.

If you are using GraphQL for your own database, it can serve as a way to worry less about endpoints. Often times you'll be dealing with different requests, such as GET, POST, PUT, and DELETE. These all mean multiple requests to do different things, but with GraphQL, your query is sent to one endpoint. In that endpoint are helper functions that can act on whatever it is you need to do with the data in your query.
Planning out database endpoints can be a chore, especially if your app scales largely. Using GraphQL can make it a lot easier to get the data you need without worrying about path collisions or making your endpoints longer than they need to be.

GraphQL is a helpful tool for making requests for data a lot easier, and a lot more understandable. The fact that it can be used across many languages means that you can use it for a lot of projects that have different tech stacks! Take more control with the data you request, and give GraphQL a try!

What Is Server-Side Rendering?

Stephanie Smith — Fri, 10 Jul 2020 02:18:04 +0000

Over the years, rendering content on a page has developed to have a lot more possibility than just rendering from a server, which used to always be the case. Nowadays there is also client-side rendering, and both client and server sides have their pros and cons. Here are some questions I will be going through in this post:

What is server-side rendering?
What is server-side rendering good for and why?
How does it differ from client-side rendering?

Let's get started!

So...what is server-side rendering?

It's one way to send data to a user's browser in order to display content. The content itself is converted to HTML in the server, rendered, and then sent to the browser. This is why with server-side rendering, you'll see that the content of the page loads a lot faster.

For every page the user wants to go to, a new HTML file is rendered and sent to the client. These files are often static because you're sending multiple files; for every change made, the server will send a new page with new information that is based on the change made by the user. To the user, they'll see that every page is being reloaded entirely no matter what changes they make, which won't flow as well in terms of user experience.

In a nutshell, server-side rendering takes converted static files, HTML and CSS, and sends it over to the browser, where it will load the content for the user to see. If the user requests a change, the server will send a new file to reflect that change.

What are the benefits of server-side rendering?

When you render files from the server, as mentioned above, the content on the browser will load a lot faster as the client-side doesn't need to do as much work to get the contents displayed. This makes for painting the page on the initial load a breeze, and will keep potential users on your app!

Because all the file rendering is done in the server, there will be a huge boost in performance for the client, since every page that's being sent simply needs to be loaded; the client doesn't have to do any conversions or rendering. That means that for the user, they'll likely have to wait less for any initial loads to load on their screen. This is definitely something to keep in mind if your app is serving lots of users.

Search engine optimization (SEO) will also work in your favor here. Because server-side rendering means rendering the files before they're sent, the page information will already be available to the browser before a user gets to see it, so the page information will be caught a lot quicker by the search engine's algorithm. That means your page could be one of the many apps that users see first!

Overall, server-side rendering is good for speed and performance, but this is generally helpful if you have a lot of static files as opposed to files that are more dynamic, which is what client-side rendering covers. We'll cover it briefly here, but a good rule of thumb is if your app has a lot of static files or runs statically, you'll benefit from server-side rendering.

What about client-side rendering?

The biggest difference between server-side rendering and client-side rendering is where the page content is rendered (you can tell from their names alone!). In this case, the content is rendered on the client-side, or the browser, which has its pros and cons.

For client-side rendering, your pages might look a lot more dynamic, especially if you're using JavaScript frameworks like React, Vue, Angular, etc. That means that the majority, if not all of the content, will be in JavaScript as opposed to HTML. The browser will render the HTML fairly quickly, but that's all the user would get until the JavaScript is rendered, and only then will the content be displayed. If your user's internet is slow, that's going to be a very slow initial load!

Unlike server-side rendering, where you'll have to send multiple pages and fully reload entire pages, client-side rendering allows for single-page applications (SPA). This can make the user's experience flow a lot more smoothly, as they won't have to load a brand new page every time they did something new. All changes made by a user will be reflected on the same page, which can look quite fast if implemented correctly.

Conclusion

Whichever one you choose, keep in mind that they work better depending on the app you're making, and there are quite a few factors to keep in mind when choosing how to render your app, especially when it comes to a user's interaction with it and the kind of data you're working with. Getting a chance to build with both will allow for some deeper internalization!

Accessibility is Key

Stephanie Smith — Mon, 06 Jul 2020 18:17:59 +0000

Most - if not all - modern websites have accessibility, which is an important thing to implement because it makes your website accessible to users that have disabilities, and reach a wider audience of users that use assistive technologies.

In implementing accessibility, you are giving everyone access to information that they need, or interactions with others using the internet, no matter what their conditions or disabilities are. Web accessibility is even required by law in some cases, so it’s always a good idea to keep accessibility in mind when you’re making a web app. In this post I’ll be talking about the following:

What are some of the guidelines for accessibility?
What tools are out there to check how accessible my app is?
How do we implement them in our own web apps?

Guidelines for Accessibility

First and foremost, make sure that all the content on your page is clear and concise, so a user doesn’t get confused with what your content is about. This also ensures that you’re not leaving a user out if they can’t understand what perhaps another user would, like metaphors or figures of speech. Another thing that would greatly be of use is using Semantic HTML, which already provides a lot more accessibility than HTML that is not semantic.

Overall, a general guideline for accessibility is to always keep in mind how the user will be using your web app. Provide descriptions of elements and images on the page, make sure that the user is able to control what they want on the page (media, zooming in or out, etc), allow users to focus on an element with their keyboard (known as keyboard focusing), and provide clear validations as well as explanations of what is happening with your web app (successfully doing something, the user requiring another input, any errors, etc). This will allow the user to understand your web app as they explore

What Tools Can I Use To Check Accessibility in My Web App?

There are plenty of tools to get you on your way to making your web app accessible, but the easiest to use is Google Lighthouse, which is in your DevTools if you’re using Google Chrome. Simply click the ‘Generate Report’ button, and let Lighthouse do its thing. You’ll get back scores of how your web app performs, and one of the categories is accessibility. Looking into why you get a certain score and seeing what needs to be improved on is sure to aid you in making sure that your accessibility score is as high as can be.

For more specific aspects of accessibility, there are lots of Chrome extensions and websites that aid with how accessible your app is. Here are a few that are worth checking out:

Accessibility.dev - This site was created by Level Access, a company that is focused on providing accessibility to products and services. The site provides tools such as color contrast checking, accessibility testing, and even a tool to help developers write clean and readable code!
Accessible Color Palettes - This tool can help you choose a color palette that will allow for users to read the text in your app, especially if you’re using lots of colors or have a theme to go along with your app.
Colorblind Checker - This site can be useful for testing if your web app is accessible to users that are colorblind, and will show you how your web page will look depending on the condition.
Accessibility Evaluation Tool - This tool allows you to paste a web page URL, and it will evaluate how accessible your app is. It can even give you an explanation for the things that they’re looking for, and why they’re important. Overall, a handy tool if you’re looking to see what your web app has and what it can improve on.

How Do We Implement Accessibility In Our Apps?

Other than Semantic HTML and overall clarity, you’ll likely come across Accessible Rich Internet Applications (ARIA), a standard for accessibility in web apps. HTML tags have attributes that start with aria, and have a bunch of accessibility features, such as aria-label, which labels an element for screen-readers to see. Here's an example of what that might look like:

<button role="button" aria-label="Greeting">Hello!
</button>

There’s also a role attribute that describes the element’s purpose, such as a checkbox or a button. You can use ARIA for non-semantic elements, as HTML5 has incorporated accessibility in Semantic HTML for most elements.

If you’re using React, they support accessibility by using HTML standards, like ARIA or Semantic HTML. They use Ref’s to keep accessibility running smoothly, since having a virtual DOM that updates the actual DOM can lead to some problems, especially with keyboard focusing. React also has a Fragment component, which allows a component to return multiple elements without having to encompass them in a <div> tag or something similar, which can disrupt the overall semantic flow of your web app. There are plenty of npm packages to aid in accessibility for React, and even with applications that don’t use React as well, so it’s worth checking some out!

Web apps should be accessible to everyone, so keeping accessibility in mind should be one of the priorities you have when building a web app of your own. There are lots of resources out there to help make your app as accessible as possible, and looking into guidelines like the one provided at The A11y Project’s website would be a good place to learn what to keep an eye out for! Happy building!

All About That SASS

Stephanie Smith — Wed, 18 Dec 2019 17:30:53 +0000

Let’s say a friend or co-worker mentions SASS to you out of the blue one day. You find it interesting, and you can see yourself utilizing it to your advantage and making it easier to write out your CSS. Then you wonder, what exactly is SASS? How would you be able to use it, and what are the basic functions of it? Why is it so important that people are sharing it? This article will explain all you need to know and get you started with the basics!

What is SASS?

SASS, short for Syntactically Awesome Style Sheets (awesome name!), is a CSS preprocessor. In other words, it’s a CSS extension that allows a programmer to use some nifty tricks to make writing out CSS a lot less of a chore and helps keep code organized. Then, when the code is complete, it is translated back into CSS code during the compiling stage. SASS allows you to use variables, nesting rules, operators, and more, so it’s useful if you have to write a lot of code!

How do you use SASS?

In order to start using SASS, you will first need to get npm, which is the Node.js package manager. This is a command-line tool that allows us to easily download cool packages like SASS and their dependencies. In this tutorial, I’ll be using Linux, so if you’re using Windows or Mac, make sure to look at the documentation for those command lines instead!

First, you want to install nvm, or Node Version Manager. This also gets you Node.js and npm when you install it, so you have more terminal options! To get it, go into your terminal. Make sure you’re in the directory you want to install nvm into, then run the code below:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.1/install.sh | bash

Once it finishes running, you’re almost set! Now to get SASS, you just have to input the command in the terminal! (If you want to check if you have SASS, just type sass in the terminal. You should be shown a list of inputs/outputs, source maps, and other commands!)

npm install -g sass

Now you’re set to use SASS on your computer! Whatever text editor that you use on your computer should now be able to use SASS as well. If you’re using text editors such as Atom, Sublime, etc, there are methods to getting SASS installed on those as well, but for this tutorial, it applies for local text editors that come with your computer, such as vim!

SASS Basics

So you have SASS...now what? To start using it, you first have to learn some of the basic functions. We will be covering variables, how nesting rules work, mixins, extensions, and operations, as these are some of the key functions in SASS!

Variables

Yes, you have the ability to create variables in SASS! To make a variable, you simply add a $ sign in front of a variable name, then put in a value that you want that variable to have. It helps if you want to reuse this particular value in many other places in your CSS, such as a color or a font size. Here is an example:

$font-stack: Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}

$font-stack and $primary-color both have a value stored in them and are placed in the body. It’ll work just as though you put in the font family and color yourself! Keep in mind that you will still have to write out the value first inside the variable before you can use it!

Nesting

First of all, what is nesting? In HTML, you see nesting all the time - putting headers inside sections, paragraphs inside articles, figure captions inside a figure, etc. Unfortunately, CSS doesn’t have this option. If you want to write CSS for different parts of a section, you’ll have to type out the whole thing over again. No one wants to see something like this:

nav ul {
  margin: 0;
  padding: 0;
  list-style: none;
}
nav li {
  display: inline-block;
}
nav a {
  display: block;
  padding: 6px 12px;
  text-decoration: none;
}

It can be messy, and a chore to read. However, thanks to SASS, there can also be nesting in CSS! Much like HTML, you can apply these parts of a section in a nest. It won’t look like the code above, and it’ll be much clearer to read! Take a look:

nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

Every part is inside nav, without having to mention it more than once. And this is good because we want to keep things DRY - in other words, don’t repeat yourself!

Mixins

Writing lots of the same properties and code over and over can be tedious, and that time can be better spent on other things you need to get done. With SASS, you can create a mixin! This allows you to group your CSS properties into one so that you can change all of them in one go. It takes a variable, and whatever value you give that variable, it will apply for all of the properties that are inside the mixin. For example:

@mixin transform($property) {
  -webkit-transform: $property;
  -ms-transform: $property;
  transform: $property;
}
.box { @include transform(rotate(30deg)); }

The value for $property becomes 30deg, so that value applies to all of the properties inside transform. It saves a lot of time and is still readable!

Extend

This is one of the most useful features in SASS, as it not only keeps your code DRY, it also saves a lot of time! Extending your code out to other selectors makes it so that you don’t have to write the same code for every selector that needs it - imagine having 30 selectors that need the same 3 properties! SASS allows you to extend these properties so that they apply to any selectors you wish. For example:

%message-shared {
  border: 1px solid #ccc;
  padding: 10px;
  color: #333;
}

%equal-heights {
  display: flex;
  flex-wrap: wrap;
}

.message {
  @extend %message-shared;
}

.success {
  @extend %message-shared;
  border-color: green;
}

.error {
  @extend %message-shared;
  border-color: red;
}

.warning {
  @extend %message-shared;
  border-color: yellow;
}

%message-shared has a set of three properties and is being extended to a bunch of classes. What this does is it gives each of these classes the same three properties, so the only thing you’d have to add in is something different for that specific class! It keeps things neat and easy to read.

Operators

The fun part of SASS is that, finally, you can do math! Design isn’t always math-free, so it helps to be able to use operators to create better designs and have more flexible options. A good example is getting the height and width a certain percentage so that it remains responsive and also looks precise as you design. Take a look at how it’s done:

.container {
  width: 100%;
}

article[role="main"] {
  float: left;
  width: 600px / 960px * 100%;
}

aside[role="complementary"] {
  float: right;
  width: 300px / 960px * 100%;
}

The width has a value of a certain amount of pixels multiplied by a percent, which is much more precise than simply writing out a percentage or pixel amount. It also takes into account that there’s a set pixel amount of 960, so it helps the width become more responsive should something in the design change. There are plenty of more uses for operators, and they’re something you can play around with!

Why SASS?

Just from taking a look at the basics of SASS, it’s safe to say that it’s certainly a good extension. Using SASS means using a better version of CSS, with more flexibility in how you code, making the task of styling less tedious and messy, and also allows your code to be readable! It can even shorten the amount of code you write in the file, which makes for easier reading and less scrolling! Overall, SASS is worth learning, and it will definitely be of use the next time you want to style anything you are creating. So what are you waiting for? Start using SASS and see for yourself how powerful it is!