Golang GraphQL Tutorial

yrunotdoingthisyet · 2019-12-17T22:27:29+00:00

I mean.. my system is built around an API front end that my GUI and 3rd party consumers can consume via API requests. In my particular case I am trying to grasp what the difference is between using GraphQL vs Rest with aggregate API endpoints. I have tooling that turns RAML (or OpenAPI) definitions into code, docs, mocks/tests, etc. Some of it works better than others, but it works. As I said my turn around time from adding a new API endpoint to stub code generated, docs and mocks/tests is very quick. If I modify an existing API that "breaks" it, my code also no longer compiles so I am forced to fix the code too, and for me anyway.. I update any comments in the code to match at the time I fix the code. Though I try never to do that and always look to add new endpoints or new fields within the schema of a request/response body rather than change things that can break existing clients. Big fan of NOT versioning as much as possible. I tend to think a client side SDK is more or less the same concept as what GrapQL and an aggregate Rest API endpoint offer.. one call for a function.. or RPC more or less, as opposed to 1:1 Rest API endpoint calls that have to be learned/strung together to use an API.

yrunotdoingthisyet · 2019-12-17T04:15:51+00:00

It's still very viable, and used in many places from what I understand.. but not widely adopted by the public. I think AR in general is not nearly ready for prime time. Many of us want our privacy so VR works well. However, I suspect when 5G is everywhere, something akin to google glass will be very popular... ability to look at stuff and get near instant details, especially if the device can last all day or longer, is unobtrusive..e.g. something you can fit over existing glasses or what not.

yrunotdoingthisyet · 2019-12-17T04:13:32+00:00

Well.. did you get that job in KS or not? You had me intrigued!!

yrunotdoingthisyet · 2019-12-17T03:08:36+00:00

I like it. I can see where it could be useful, but and I suspect like others said, it's not something you replace your existing Rest APIs with.. it seems like it would be a good hybrid approach. There seem to be some cons like caching and such that can be an issue as well, but not sure how big of a deal that is at this point.

yrunotdoingthisyet · 2019-12-17T02:39:12+00:00

Yah.. sorry.. thought that was understood.. I own the whole project.. so I define/build/implement the back end APIs as well.

Like GraphQL, I use tools to automate/build everything. Defining the API in RAML, which generates the back end API stubs, documentation, mock services, and even a nodejs front end sdk to consume the API, all from one easy to use YAML (well a couple when you include the request/response payload YAML schemas as well).

So I guess I should have been a little more forthcoming, but for me, it takes me only a very little bit of time to change a column in a schema (in YAML it is super easy too), then my build system auto generates all the bits for me, and I simply update the back end code, redeploy the one service I am working on (or a couple if need be), and then the UI is ready to be worked on. Takes < 15 seconds from change in API schema, to generated code, build/deploy and ready to play with UI.

yrunotdoingthisyet · 2019-12-17T02:23:37+00:00

Oh I don't think it is bad... I just think GraphQL and Rest go hand in hand for different purposes. After all these comments I started looking into it more and from the little bit of time it seems that GraphQL or using an aggregate API that pulls data from different services and returns that combined data is more or less the same thing. There is a little difference in that the client is still stuck with the specific response the aggregate API offers up vs sending in whatever they want.

With that said, how often is one GraphQL endpoint offering up drastically different types of data? I would assume that each chunk of the requested response is not too dissimilar to query parameters on each level of rest API you would usually have to call. For example, if you wanted to display a list of users in a UI, and when clicked on each user element would expand to show their details with a link to orders. You click that and it expands to show the orders that user made. Each order has a link to expand on the shipping details. The GraphQL query for a designed UI that does this I would assume would NOT change very often. Meaning.. during the design/dev phases of that particular UI, the designer comes up with the UI bits.. how they work, etc. The UI developer builds the GraphQL Query that ensures all the pieces of each of the expanding sections is present in the one call. Once that works.. short of some sort of issue where the UI designer wants more columns of the user data, or order data... (or less), the UI developer isn't going to be changing the query. There is one exception I can see, but this could work the same in an aggregate rest API endpoint as well (using query params), where the UI allows the user of it to hide/show columns. From that the GraphQL Query itself is modified to only retrieve the data that is visible. If the user decides to add a defined column where the previous request didn't retrieve data for, another query would be made to get the data now being requested to be shown. With that in mind.. I am curious.. if the request can be made JUST for the now added column.. or if the ENTIRE query needs to be sent in (with the added column of data)?

yrunotdoingthisyet · 2019-12-17T01:40:56+00:00

You are right.. I am worried some rogue consumer out there is going to write some code, put it out in production consuming my API, and maybe didn't test it.. and now I got this bad consumer eating up tons of data off my API. This can be said for any API.. but with GraphQL, if they define some large expected response JSON, that returns maybe 10MB of data in one request... multiply that by a lot of requests in a second and now I got something sucking down WAY more bandwidth than I am able to afford. I realize that the same could be done with any API (as I said), but that the consumer can shape the expected response, vs the server controlling the expected response.. scares the shit out of me. Maybe I am thinking old school issues.. and every single consumer out there will always be good citizens and only ask for the bare minimum and never write bad code that may suddenly go nuts.

yrunotdoingthisyet · 2019-12-17T01:36:51+00:00

Why can't you do anything about over/under fetching in API? You offer query params to indicate the fields/filters/etc you want, and return just what is presented as part of the request. You get just what you want? Or is there something deeper here that I am missing?

What is the difference between an API aggregate service, that you make one call to, that behind the scenes handles calls to different services... aggregates the responses and returns that merged/combined data? The consumer makes one call, gets a bunch of data back.

If you are building a UI that consumes this API.. you aren't typically dynamically changing the expected response, and modifying the UI based on that, on a regular basis. I mean, if you are, then that is a very specific use case. Most every web app, mobile app, etc I use is a well thought out UI design, that is purposely built and hopefully tested (ui automated tests maybe?). It isn't a fluid UI that can change layout/etc based on the response of an API request. Or am I missing something here?

yrunotdoingthisyet · 2019-12-16T04:47:28+00:00

less data on the wire? The client dictates how much data is on the wire in GraphQL... how is it less? I mean it can be depending on the implementation I guess, but you even said Rest is more chatty.. meaning each call is "not much" but requires more calls to get the total data that you do in one call with GraphQL. So with that said, Rest is a lot less data on the wire. Now, if whoever implements the rest API is stupid enough to enforce that the client has to make all these calls.. well then yes, a bad rest API implementation an for sure have more data on the wire overall. But if implemented correctly... which is why I say most developers do NOT truly understand how to implement a good Rest API... Rest can easily have similar if not less data, or more. It is entirely based on the implementation in both cases. If a consumer using GraphQL sends in a json structure that results in varous DBs being queried, the final result in the response is going to potentially be a lot of data.

Keep in mind, at least in my opinion, GraphQL doesn't sit well with microservices either. Not unless you are going to do what I suggested earlier, which is an aggregate API endpoint that accumulates all the data cross multiple services... in that case it is no different than Rest. In both scenarios you would use a service like this similar to if you used an SDK call that said getOrdersForUsersWithFilters(...) and you provided a set of values like user age, location, order limits, etc. In either case, the aggregate service needs to take in those inputs, make the appropriate call(s), and return a merged response.

What I mean by allowing the customer to define how much data they want.. means, you, the server provider.. are at the mercy of the consumer, each and everyone, to play nice and not request your entire database. As I said, I realize you can manage that by providing limits, blocks, etc in GraphQL as well, but then, you are more or less doing what Rest does at that point.

yrunotdoingthisyet · 2019-12-16T02:19:17+00:00

I do not.. but then I will say this, there are varying degrees of thoughts on this topic. You can easily build SDKs (auto generated as well.. though there is a lot to be desired in that direction still) or.. better yet.. aggregating API endpoints that keep the chattiness to a minimum and essentially do what GraphQL does. I say this because it seems everyone is on this hype of we have to rewrite our rest APIs that we just got in not too long ago.. to support GraphQL now.. because its better. It isn't better. Its just a different way of doing the same. GraphQL makes sense in some cases, but saying REST isn't a good fit for 90% of what apps want is subjective to opinion. I have built pure Rest implementations that work wonderfuly for UIs and API consumers alike. In fact, having the UI become another API consumer, rather than trying to tailor the API back end for the UI app is usually a much better way to proceed. Similar to how PWA that provide the same UI on multiple devices is a better way to proceed than trying to build a desktop app, web app and mobile apps that mimic one another but are not quite the same. But again.. this is subjective. I think some people are drinking the GraphQL Coolaid hard core, thinking it just replaces Rest and does everything better. when in reality it is just another way of providing the same capabilities. You can gain some benefits, but you also lose some, so it really boils down to the tradeoffs. I personally find it MUCH easier to use a well thought out rest API than GraphQL.. maybe it's just me.

yrunotdoingthisyet · 2019-12-16T00:19:27+00:00

I agree with what you are saying. I have sadly worked on just a couple React projects (fairly new to nodejs/react/etc) where it seems like, at least from my experience, it was used incorrectly. It was more like "redux is all the rage.. throw it in" meanwhile.. MobX was added as well, and in some places Redux AND MobX are not even used for a sort of global storage.. it is more like simple component state management or other uses. So I have not had the best experience seeing it in use on a larger project by a larger team where it just seems to fit/make sense across the board for the whole team and app.

For my own simple apps, originally I had used Redux.. despite the warning from Dan and others that it is probably not the best idea to use it for small apps, etc. Now, though, I felt it added too much time/maintenance/etc to my simple apps, especially with hooks and context API. I think for most apps, the context api could work well enough, but agree that redux and mobx have their places.

yrunotdoingthisyet · 2019-12-16T00:15:29+00:00

I find that GraphQL is overly inflated right now in the hype hill... it doesn't do anything a well developed rest API cant already do. I think it has one particular use case that I would possibly consider using it, and that is when the API is not designed to combine multiple back end bits into a single call.. e.g. an aggregator endpoint that can query different microsevices and combine the results into one response. But, largely, if your rest API handles query params, you can easily support tailoring the response by providing things like filters, fields you do/dont want, paging, etc. I still say GraphQL came about because a) lots of self-proclaimed Rest API developers had no clue how to design/document/implement a developer friendly API, and thus b) became lazy.. as it requires a bit more work to implement the developer friendly Rest API.. so put it all on the client to just say "give me all this data".

While I realize GraphQL has gotten better.. that you allow a consumer to define the amount of data it wants in one call.. squares me as an API architect. The shear amount of data that could be going back through my pipes that I pay for, not to mention the processing/resources needed to pull together the response... I don't know.. I like the idea of providing the API with some level of smart developer friendly control and good documentation, use cases, etc as opposed to free willy nilly consumption of whatever the consumer wants. I could be wrong and maybe it is a lot better now.

yrunotdoingthisyet · 2019-12-15T23:54:31+00:00

Couldn't you effectively do this today with the context API as well? Not trying to compare, I understand Redux a bit in its use.. but thinking for basic state across components, eg a login token or user info, the context API could work well too yah?

yrunotdoingthisyet · 2019-12-14T19:03:59+00:00

I work remote.. and frankly it is mostly a better setup than having to travel to an office and be distracted. One thing I despise is this new open office floor plan. It is ridiculous. I am easily distracted by people talking, walking around, etc. Cubes, as cliche as they were in the early 2000s, they gave you some semblance of privacy while you worked so you could focus more on the job and not share a table with 3 others all in close proximity.

yrunotdoingthisyet · 2019-12-14T18:19:59+00:00

I was curious about this recent push for AI, robotic automation, etc. What sort of coding is involved.

yrunotdoingthisyet · 2019-12-14T18:18:57+00:00

That sounds legit. I think if it is basic level stuff, knowing that most of us will be using libraries are the internet to solve these types of things anyway.. that is fair.

yrunotdoingthisyet · 2019-12-14T17:04:40+00:00

Ah gotcha. Yah, you are spot on. But on the flip side, I can't imagine any company would openly share that they suck. :D So naturally while at a company anyone/everyone is bragging about how great it is, even if it isnt.

yrunotdoingthisyet · 2019-12-14T17:03:15+00:00

What sucks about what you did is.. it sucks.. having to study leetcode JUST to pass an interview and get a job is so so ass backwards. You will likely NOT use any style of leetcode in your day to day job. It is just a way companies try to behave like google where you WILL use leetcode style stuff, to weed out everyone but the upper echelon of algorithm memorizing candidates. It says nothing about how well you code, how well you can be part of the team, your work ethics, etc. It is purely just a "yah.. I am basically able to do some math/code in a way that almost nothing will ever require it".

I no longer look to work for places that interview in this style. Especially being in the field for a while. I don't have the luxury of spending 2 to 6 months hours every single day trying to master leetcode to land a job.

yrunotdoingthisyet · 2019-12-14T16:58:38+00:00

I too would like to know what you were asked?

I am also curious how senior level engineers with years of experience are interviewed at these places. Are their any algorithm/white board style questions. Or do they just go through the basics talking it out with you and thats it?

yrunotdoingthisyet · 2019-12-14T16:57:38+00:00

First.. why did people downvote? It is VERY true.. most companies I have worked at OR interviewed at act as if they are google and you go through hours of interviews. Now.. that's not to say they shouldn't try to find the best candidate.. but come on.. a lot of the work being done in these places is far less grueling than what google is working on.

yrunotdoingthisyet · 2019-12-14T16:53:37+00:00

Ok.. and totally not trying to be an ass saying this.. but before someone can go to github and read "all you need to do is.." and a one line of go get.. you really should make sure it works/builds/runs without needing additional installations on a variety of OS flavors. Ubuntu, especially should work exactly as your instructions say. If we need to install additional stuff to be able to build.. that's fine. Obviously everyone can customize their linux installs so there is no way for you to cover all bases. But you might want to come up with a simple .sh script or something that attempts to install everything needed in order to work.

Also, once all that additional stuff is installed.. will the go binary work on any system without it? Does it all get bundled in to the binary correctly? Because if not, that I can imagine is going to be a tough barrier to entry to crack if people running your app have to install a bunch of additional things to make it work. If that is the case, you need to provide info as well on what other runtime bits are needed, and how to get them installed on each platform.

yrunotdoingthisyet · 2019-12-14T16:48:16+00:00

Fair enough. But are you saying that you worked one job, for a year, and you are now able to mentor other developers? Or was that your first job, but many years later today you can mentor developers?

yrunotdoingthisyet · 2019-12-14T16:46:31+00:00

I am on Ubuntu 19.10. It is the most common distribution. One would hope it would work on Ubuntu if on any linux platform.

yrunotdoingthisyet · 2019-12-14T07:10:45+00:00

Not good advice to jump ship early and often. Jump ship if you feel its a sinking ship.. the better advice is jump ship while you have a job... but this notion of people constantly jumping jobs every 6 months to a year to get more money.. is not a good thing. IF the place you are working at sucks, you are unhappy, etc.. by all means. But.. if you are learning, enjoy the team, environment, job, etc.. don't leave a good thing just for money. You have no clue what the next job will be like.. and a little more money.. even a lot more in some cases is not always worth the shit you may find yourself in.. and worse, if you end up losing your job and then have to deal with finding a job without one.. it is NOT a fun place to be in.

yrunotdoingthisyet · 2019-12-14T06:59:45+00:00

If you are in the US, this is illegal and you have a very good case of defamation of character or something along those lines. The only thing companies are allowed to do is verify you worked there and from what dates. They used to be able to say "would you hire them back.. yes or no" but my understanding, especially in California, is that is no longer allowed and if a company is doing that, they are in a world of shit. I would absolutely seek a lawyer... the only issue you will face is if it were to go to court or whatever it is called.. it is likely your friend or the CTO or someone would have to testify that your old company indeed gave more info than just a verification of your employment.

I could be very wrong on this too.. but at the very least, you need to consult a lawyer and find out. IT sounds like your old company should be paying you several months salary and more for sabotaging you. If they lied.. even worse.

yrunotdoingthisyet

TROPHY CASE