![]() ![]() The need to search within my codebase to check if a Fragment for a given batch of fields already existed.The need to open the file the Fragment was to confer its fields (slowing me down).Different Fragments for the same fields.To give you some easy-to-digest examples, these are a few things that happened to me: At first, I felt the productivity at my fingertips and thought how I survived all this time without it, however it didn't take long to show up some bleedings. Frustration because my imagination was completely wrong relief because I could achieve GraphQL without Fragments.īringing the climax to the table, in this serious project of mine, I experimented Fragments a little bit. Turns out that when I realised that, frustration and relief occurred to me at the same time. And please, don't get me wrong-that's not bad at all. It's literally just a DRY developer sugar. In other words, I fantasised that Fragments was a kind of cache.īut then, after the reading I mentioned earlier, the quote of myself above became my new axiom. Hence I imagined it was a way to reuse the values of those fields that were returned from the data of a real query. I remember it was an Apollo page ( maybe this one).Ĭool, you can easily reuse pieces of your Queries out and aboutīefore reading that page and diving deep into it, what I imagined about Fragments is that its function would go beyond merely serving as variables to hold fields one want to use in different Queries. ![]() Sat down in my computer and spent hours on some serious (lol), deep reading. C'mon, who never?Īnyways, time to get even more serious about GraphQL and expand my knowledge further. ![]() I mean, pursuing the codebase that would make Facebook envy. Picture this: a developer in front of his computer running yarn add non-stop, setting up all the foundation for his next big venture. ![]() Now with some experience in GraphQL, I decided to create a "serious" pet project, and those who, like me, fantasise serious pet projects, they go wild when it comes to programming seriousness. Back to my first reading on GraphQL, I skipped Fragments because "oh, alright, I'll check it out later", but this "later" ended up meaning years. There is one fundamental piece on my naiveness: I started working with GraphQL in a daily basis and meanwhile skipping and ignoring Fragments the entire time. The truth is that was naive from me doing so because, nowadays, it's clear it is a core mechanism the technology has to offer. However, one thing I skipped completely was Fragments. These two-specially Queries-were easy to tame. Mostly, what we had there-and still have-were Queries and Mutations. So I started learning GraphQL in the front-end. When I felt I was too confused, just gave up with the formal education and picked Relay's "Quick" Start guide to see the thing in practice. Queries, mutations, fragments, resolvers, etc. It was not only a new MVC framework-it was a whole different and modern mentality.īack then, before getting my hands dirty, I spent hours reading and skimming articles. New concepts, several different new keywords, good practices peeking around the corner. Thing is, as someone who worked in a daily basis with REST, doing the migration was not seamless. I bluntly fell in love at the first stare it gave me. The most iconic thing I remember is that we had requests returning huge amounts of fields and the major part of those were oftentimes needless. I remember we had standards I remember we had routes I remember there was a distinction between REST and RESTful. I dare to say that 70% of my career I spent living together with REST, but barely can remember of it and its good practices. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |