DEV Community: Jake Chapman

The case for learning programming languages, frameworks and tools sequentially

Jake Chapman — Sun, 13 Sep 2020 17:10:50 +0000

Shiny things are fun. But more often than not, that new shiny thing is the result of a single person or group of people that thought an existing product, concept, or pattern could be improved upon. This doesn’t just happen in the software development industry, it happens in every other industry.

Steve jobs looked at tiny mp3 players and thought, this could be better. Eventually leading him to look at the brick cellphones we had at the time and think, this could be better.

The goal of each iteration of an idea is to solve specific problems with the previous version. To create either an easier product to use or a better environment for the person in it to complete tasks faster. When we start to look at the history of programming languages, this same concept starts to shine through.

From the original implementation of Fortran in the mid 1950s, to Lisp and Cobol in the late 1950s. Move on to Basic in 1964, Pascal, Smalltalk, C in the 1970s. Then Objective-C, C++, Erlang, Perl, Bash, and Python in the 1980s. Closer to today we had Haskell, Visual Basic, AppleScript, Lua, Java, LiveScript (which eventually was renamed to JavaScript), PHP, Ruby, OCaml in the 1990s. Finally in the last 20 years C#, VB .net, Scala, Clojure, Swift, Go, CoffeeScript, Rust, Dart, Kotlin, Elixir, Elm, TypeScript, and Reason.

The following list is in no way shape or form exhaustive. There have been hundreds of languages created since the 1950s. If you’re interested in that sort of thing, I’d definitely recommend checking some of the languages out https://en.wikipedia.org/wiki/Timeline_of_programming_languages

About 98% of the languages on that list all have a predecessor it was trying to build on top of. Each new language included abstractions for common patterns. This wasn’t by chance. It was a technical decision by the creator(s) to make programmers lives easier to complete the same tasks. To write less code, or maybe write more imperative or declarative code. Maybe they created it to be compiled faster, sometimes they didn’t even want it to be compiled at all and instead wanted it to be ran just in time when a specific piece of code was needed to executed. Sometimes it’s for performance, other times they know it’ll be slightly slower but the readability and developer experience is 50x better.

Every decision we make in our lives is about dealing in trade-offs. The programming languages we use for a technical problem and the reasons why we’d use a specific language, framework or tool is no different.

From here on out I’ll be making my case using JavaScript and it’s ecosystem due the fact it’s what I use it for 99% of my daily work. I’m sure someone who has 35 years of programming experience could make the same case speaking only about backend languages as well. I’m sorry if this excludes some from the conversation but I feel most if not all should be able to make the connections.

I’ve seen a trend the past 5–6 years as the web development industry has seen a drastic increase in the amount of people wanting to learn to create software. They attend a 3–6 month bootcamp for full-stack development. Basically throw you into the deep end with either Python, Objective-C/Swift, or JavaScript full-stack development. They learn about APIs and how servers work. What and how a deployment pipeline looks like. How to host applications on cloud services like Heroku or Netlify/Vercel etc.

Eventually they find themselves creating tools for either themselves or for the company they’re working for, or maybe they even want to create and maintain an open source library. They start planning out requirements, tinkering with some early proof of concepts, looking at the ways other similar libraries or frameworks are handling things. They’ve got this awesome new shiny thing that is almost done, only to come across the latest tweet “Proud to be launching ‘such and such’ today after 9 months of hard work”. Holy shit, that looks amazing. Click on the link and read through the getting started. Woah I can’t believe how much easier this looks and how much simpler this would make this thing I’m building be. I had no idea you could do it in this way compared to the way I’m doing it now.

rm -rf ./project
Start from scratch with this new found glorious knowledge you’ve obtained. Rinse, repeat.

Let’s go back a few years. Actually 8 years to be precise. I was a full time front-end engineer and always wanted to build native applications for iOS. There was phone gap and a few others at the time, but I wanted write “real” native. So I purchased a few Objective-C books and some redbulls. It went relatively good. Built a few tiny little play applications using the camera and photo storage, messed around with some of the device APIs the iPhone offered. But kind of fizzled out because I was nowhere near where I felt like I needed to be to transition to an iOS developer.
Fast forward 2 years later, Swift was announced and it was the hot new jazz. It got me interested again in native iOS application development again. Maybe it’ll be easier to pick up this time around. Swift was a completely new programming language compared to Objective-C, but it ended up being easier to pick up faster. Because I had already learned a decent amount of Objective-C, I could pick up on the reason I would want to use it over Objective-C. The abstractions, the less verbose syntax etc. It made sense because I had knowledge of what it was building on top of. I eventually fizzled out again because my passion for front-end development was to strong.

Back to today and the JavaScript ecosystem. TypeScript. I know just by typing that there are a few people who just got chills and want to close the window. Who the fuck wants to write strongly typed JavaScript? Vomit. This can easily be the case with newer developers who have limited JavaScript experience or knowledge. There obviously is a reason it’s so widely used now, but you just understand why.

Deno.js was just released recently. Which was created Ryan Dahl, who also happens to be the original creator of Node.js. But why this new shiny thing? Should you use it? Why should you? This brings me back to my original point of learning things sequentially. If you watch his talk on his regrets of Node.js (https://www.youtube.com/watch?v=M3BM9TB-8yA) you’ll start to get an understanding of this new shiny toy.

It’s completely fine to have never written a line of JavaScript and jump straight into TypeScript. Yes I said it. Permissible but not beneficial. Learning programming languages and frameworks sequentially even if there’s a slight overlap helps you understand why something is the way it is. You’ll understand concepts faster and at least for myself I retain the information better because I know what it’s built upon.

jQuery, Backbone, Spine, Ampersand, Angular, React, Vue, Svelte… The list goes on and on with front-end libraries and frameworks. Grunt, Gulp, Browserify, Webpack, Rollup, Snowpack… The list goes on and on with front-end build tools.

I’m not making the case you need to learn everything in it’s entirety. But learning older languages, frameworks and tools even if it’s a broad overview of them will help you understand why things are the way they are. It’ll help you make decisions on why you’d use one thing over another. It’ll help with understanding the trade-offs in the software you develop on a technical level.

It’s perfectly ok if you have to use the most brand new thing at work and you fully don’t understand why you’re even using it. If you’re hungry for more knowledge, spend some time outside of work and go back to the roots of where our technology came from. Build a jQuery plugin. Build a Gulp.js clone. Build a sample VDOM library. You don’t need to publish them. You don’t need github stars. But I’m almost certain it’ll help you down your path of growing as an engineer.

Thanks for reading my random Sunday morning thoughts. I also hope it empowers you in conversations when talking about shiny new things to take a step back and know the reasoning behind deciding on something new.

Wrangling GraphQL Structure

Jake Chapman — Wed, 12 Aug 2020 00:11:34 +0000

I spent a good amount of time through articles and peaking into open source projects. I could never really find any be all tips and tricks for GraphQL structure of directories and files and separating schemas apart. Most tutorials were written with everything in one primary file.

In this article I go over how I've started to structure my GraphQL server applications.

Before I begin, please note that I'll be writing this with the hope you have at least a basic understanding of GraphQL, as well as Apollo-Server when it comes to setting up an Apollo Server, creating schema type definitions as well as resolver functions and data sources.

So let's chat about all these Apollo-Server tutorials out there. They're awesome! We're still very early on in GraphQL's adoption in our everyday stacks even though it appears to be the opposite from the amount of content that has been put out regarding it's positive impacts on data fetching. As I started to learn about GraphQL these tutorials were a great resource. I watched stuff on Frontend Masters, courses on Egghead, and read plenty of articles on Medium.

The one thing I couldn't really wrap my head around was how everyone was really organizing their files for types and resolvers regarding the different parts of a more complex application because of how simple the content was. Most of the time it was all kept in one big file and was used directly inline to create the apollo-server instance from only showing 4–5 type definitions and 2–3 resolvers.

I started putting the pieces together from reading multiple places into what I feel like is a good place to start thinking about how to organize your type definitions and your resolvers in a way that makes sense to the resources your consuming from wrapping a REST API or exposing content to a client.

The repository I'll be using is for a small side project I've been working on that wraps the LastFM API endpoints (all of the un-authenticated endpoints) to grab information on my music listening from Spotify for a React application (well technically, anywhere I want it). But this article is focused on the server side organization

We'll start off the with the base Node index.ts file (yes, typescript, if you're not worried about types then just disregard any of that weird looking stuff)

Pretty basic so far, we're simply importing Apollo-Server, dotenv to read the LastFM API Key, the schema which is kept at ./schema and creating the Apollo Server and kicking off the GraphQL server. Next up is taking a look at the ./schema directory.

We have the main index.ts for the entire schema definition along with a directory for resolvers and a directory for types which are broken down into sub directories. One directory for all the shared types/resources. Then a directory for each type of top level resource that we'll be exposing, in this case the LastFM API.

Let's take a deeper look into the ./schema/index.ts to see what it's importing and exporting which is being passed tonew ApolloServer({ schema }).

This is where we start to separate things out. If you notice we have a RootDefs declaration that creates a graphql document node which has 1 single type Query and what's different about this type definition is it's completely empty. We're going to be extending this root Query type in other files but as of right now the version I have is 14.5.4 of graphql package doesn't allow you to create a type with no fields. So we create a placeholder that does absolutely nothing. We name it _empty and set it's type to String and make sure it's optional (pst, cause it'll never be used)

Then at the bottom of the file we create an array of Document Nodes which is the type created from using the gql tag when writing your type definitions. We then use the spread operator to spread the rest of the imported type definitions which in this case is LastFMSchemaDefsand SharedSchemaDefs onto that array and export from the file.

The hard part is done, let's look at LastFMSchemaDefs and SharedSchemaDefs to see how we extend the root Query type with the rest of our graphql servers types.

So looking at these two files we can see SharedDefs is very straight forward and creates a basic type that can be used anywhere, we aren't extending the root Query object just yet, and we export is as an array of 1 DocumentNode.

Looking at the second lastfm index.ts file we have a few changes. First thing you'll notice is we're importing a bunch more type defs at the top, we are importing these into 1 place and exporting as the whole type definition of lastfm/index.ts to keep things tidy with our imports. From the type definition as the main type def for our LastFM resource we extend type Query with a field of lastfm which has a type of LastFM which we define below which is defined exactly like our Query type was defined at the root def. The imports above all extend this LastFM type in their own specific file which exports a single named export representing the resource name, below is an example (I won't post them all for the sake of time and space).

Each of the lastfm resources have their own directory with a single named export which extends the LastFM type and imported as type definitions in the index file for lastfm/index.ts file.

Next up is, Resolvers. Resolvers live in a directory under schema named ./schema/resolvers with a single index.ts that serves as the base for all imports of resource resolvers, similar to type definitions. Let's take a look at what that looks like.

So similar to the type definitions, at the top of the file we're importing the base import for the LastFMResolvers which internally imports all resolvers for the rest of our type definitions, as well as SharedResolvers which we know currently only has a resolver for the type Image

If we look at the root Query resolver, we're setting lastfm as anon function that returns an empty object, but why? Well you can think of this top level lastfm type as a kind of namespace for all of our nested types that we can query for data depending on the type of resource we're wanting to grab data from lastfm api. *For my typescript peeps, all resolvers which is an object of type IResolvers which can be imported from graphql-tools package from npm.

At the bottom of the file we're using lodash.merge to merge all of the imported resolver objects which are imported above and exporting as 1 single resolvers object that is passed into our apollo-server config object.

Let's look at LastFMResolvers to see the final bits of how this is all tied together.

Once again, similar to our type defs for the lastfm resources, we import all of our resolvers for each individual resource from their respective directories, create the LastFM type resolver which has the nested resources which is where we pass our arguments to and do some basic checks upfront and throw UserInputErrors which is because of the dynamically required arguments needed. If you know of a better way of handling dynamically changing required arguments, please let me know. In each nested resource we return an options object which will be passed to the resource resolvers and used in our LastFM API calls. Again for brevity, I'll only show the UserResolvers.

At this point, it's basic graphql resolvers. Setting our type resolvers, grabbing the params from the correct (root, parent, _, or whatever you call the first param of a resolver) and from args and using our defined dataSource to make the call and returning the correct data from the response.

Lastly, is the datasource you see us calling. If you're unfamiliar with Apollo-Server datasources, check out the docs for a pretty quick and easy read. Awesome class that handles most of your needs out of the box for dealing with REST API calls. Apollo Datasources Documentation

Like everything else we've seen today, I keep this at a top level datasources directory next to schema and it has subdirectories for each top level resource type, so for this project a single lastfm directory with a single index.ts file. Let's take a gander.

Not really much to say about this file, pretty straight forward. Extending the RESTDataSource that does some checks for a lastfm api key and sets each requests param to json format and throws an AuthenticationError if now api_key is provided and a single call method that setups the query params based on the query arguments and fetches the data.

I really hope this helps anyone that is struggling to find ways of organizing graphql projects. Like most other things out there, most of this is architectural decisions that just make sense to myself and how I think of resources in an apollo-server application. You can easily keep resolvers and types in a single top level directory under ./schema and have a lastfm directory where you keep resolvers and types together in the same file and exported separately and follow the same conventions above of importing and spreading type defs and merging resolver objects from that file.

To finish this off here's an image of the projects folder structure that I went through.

There will definitely be those that don't like the default named index.ts files in each directory. Which is totally understandable. For much larger projects where I'm working on it with multiple devs I would definitely be naming those appropriately, but when I'm working alone I like to keep my import lines shorter :)

If this helps at all, please comment and let me know - I'm going to start trying to write more technical articles as I continue to work on side projects. One coming down the pipe shortly will be a ReactNative application where I'll discuss everything from concept, to design to development and deployment using expo-cli and expo-kit for native components.

Feel free to catch me on twitter @imjakechapman