It has been a few since I sat down and hammered out a blog post, largely due to breaks, and to be quite honest needing to take a minute and refocus into getting into a groove on a personal level. That said learning, and exploring is certainly a big piece of that. Getting a cleaner understanding of different aspects of things while also delving into new topics can make things more complicated.
Now that that excuse has officially been fired off lets take a look at the real topic of todays post. GraphQL. As I personally learn more about the backend, and web development as a whole I certainly have gained a huge amount of respect for both GraphQL & Apollo. The ease of use, and huge return that you get from it is fairly dramatic. The ability to tap multiple endpoints at the same time, or to hit multiple APIs to draw information in is a great structure to build out a front end from.
But that is not the only piece of the puzzle for me. As I have started to fall in love with the server side of the equation I have learned that security, and minimizing data on the front end is beyond important, and while you could simply delete that information off of the return object prior to sending it to the endpoint I think it is far more clean to simply not access that information from the get go. It makes far more sense as a pattern to just not even touch it as it lends itself to ensuring that you are only returning the information that is critical to the needs of the client side of the application.
Additionally, I think that GraphiQL is next level. The ability to fire off requests from inside of a browser without any sort of additional software is awesome, and is something that needs to be addressed, quickly by the folks that are building out all of the other frameworks and libraries.
Now as someone that has experience with WordPress and dealing with a CMS full time I can honestly say that the options that are immediately building out a GraphQL API during initialization are really the leading edge. The idea that we need to move from WordPress & PHP into something that is drastically more flexible is certainly a thing. Ignoring the fact that you can stage a WordPress site the same way that you can any other, I can honestly say that the number of times that I have had to hammer out fixes on the fly because a plugin or script fried the site is honestly more than I want to talk about.
Ecosystems like Strapi, Keystone & sanity have really bridged that gap and creating the next level of CMS while still maintaining the usability that WordPress offered, it is a substantially more advanced setup (obviously) but once it is built out I have found with my experimentation that it tends to be more versatile and stable than WordPress. A big piece of that is going to be derived almost immediately from the use of GraphQL.
Here is a pro and cons list that the Strapi Team put together, and I think that while it is not all encompassing, it gives a decent overview of the issues with both REST APIs and GraphQL.
Now, a big piece of this for me is as I start really diving into using SQL instead of simply leaning on mongo I have found that instilling relational correlations between tables has been both frustrating, and mind boggling at times, and is not really straight forward. With GraphQL all of this frustration is really removed, and instead I can drop clean, concise code which is what I prefer. I add a couple of lines to the schema and when it taps my api, or my endpoint is will pull the data, and provide a correlation without any real headache.
You will notice first that the image above is not using Apollo server, and that is because I am still learning aspects, and wanted to really dive into just using a GraphQL server without splitting my code (which is a big piece of what Apollo does). The next thing that you will notice is that I am building out a type object for a company, but I am also accessing an endpoint for users inside of the object. This is really the key that I have found for creating a circular relation between different types in GraphQL, and it again is only a few lines of code within each type that are you are creating relations between.
That ultimately means that I can forgo worrying as much about getting the DB relations figured out and focus more on just getting the data that I need to present to the front pushed to the endpoints and essentially filtered through GraphQL. Meaning I can save a bit of time, and lines of code and focus more on ensuring that things are built out to be scalable, and sustainable.
Now, if we are being honest the best way to do this long term is to build out the relations between tables, and to provide both REST endpoints, as well as GraphQL. By doing this it would be more accessible to more people using more varied types of applications, and more languages without trying to hack together a middleware essentially. Thus removing a piece to the puzzle, and creating a clean and concise endpoint for everyone to interact with.
I really feel as though GraphQL will be expanding in usage as time progresses. It works well with REST, and will long term be a solution to many of the issues that developers face. Both on the front end and the back end. While I strongly doubt that it will outright replace REST, I think that there is a good possibility that is becomes a huge component of using REST.
Now in closing, I will say this: Learn. Simply Learn. I think that one hole that people (generally) fall into is that we get into a groove and stop expanding our knowledge, and as I have been pushing into the development sphere I think that the encouragement of learning more topics, and new topics is exciting as it truly is a crucial component to being a good developer.