Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>
Idioma: En

How Debating GraphQL got our Front and Back Developers Talking

How you define GraphQL depends on who you are.  For young front-end developers, its Facebook’s progressive query language that makes everyone’s life easier. For “oldie but goodie” back-end devs, it’s a hyped-up marketing gimmick that isn’t yet worth its salt.

Related Articles

What Davy realized when these two opinions butted heads over drinks was that our team learned a heck of a lot just by hashing out the pros and cons of a new tech.

This post – a rehash of the Paris API event – is a practical feedback session “from the trenches” about how flirting with new tech helped open up lines of communication in our dev team.

Development at CALLR


A few quick words to set the stage:

CALLR is a telecom company. In terms of development, we deal with exotic protocols and standards — HTTP rings a bell, but what about PBX, H.323, SIP, ISDN, QSIG…?  Like many tech companies, we generate, store, or move around loads of sensitive data. That means our staff needs to really know their stuff.

We try to ensure this by taking a slightly different approach than many of our peers – instead of favoring well-rounded full stack developers, we prefer a niche approach. We wanted to split our team into back-end, front-end and dev ops, and hire people truly specialized in each of these areas.  The Renaissance man just doesn’t work for our business model.

What we opted for was a team of: 3 back-end devs, 3 dev ops, 3 front-end devs on Angular

Of course, specialization spells silo-effect, and communications barriers became inevitable between dev units. We try and limit friction by investing in well-rounded managers: the CTO and the tech lead are obviously full stack people, so they have a solid overview of the missions and the stack. We also decided to shift to a full user stories-based process, i.e. defining cross-specialities components, especially using user stories involving both ends of the dev spectrum at the same time.

Finally, we’re using JSON-RPC, though we have a REST version of our API available for the benefit of our clients. This also means that our (CALLR front-end) devs are the first consumers of our JSON-RPC API.

Throwing down the gauntlet – GraphQL over beers

So, let’s get into the heart of it – the debate over whether Graphql could have any potential positive impact at CALLR. The subject was brought up by front-end guys because GraphQL belongs to the Facebook ecosystem of hype techs, aka the React / Relay / GraphQL triumvirate:

  • React is JS library for building UIs
  • Relay is a framework providing data-fetching functionalities for React apps, acting like some sort of accelerating admixture between them,
  • and…GraphQL

The big question was: Is GraphQL really some new flavor of JSON-RPC in disguise? Weren’t we already doing something very similar? As the saying goes, don’t fix what ain’t broke.

It’s true, GraphQL and JSON-RPC have a few things in common…

….like a single POST endpoint which is obviously very reminiscent of RPC APIs

…and they both provide, in some way or another, the ability to fetch data from several sources in one call (one could use a batch request in JSON-RPC).

But the pro-GraphQLers had some good points to make as well, namely that GraphQL could:

Make API changes a less painful experience for clients

  • If method is not new and changes, bump API version
  • If method is new, add it (bump API version maybe?)
  • Changes w/o API version bump -> breaking changes
  • Many API versions -> technical debt grows
  • Update docs, update SDKs (…ahem)
  • Impedes continuous delivery

APIs, in a perfect world, change as little as possible, if not NEVER. Sure, your design will never be perfect, your specs will change over time, but if GraphQL can help us take a step forward towards this dreamland, hail to that.”

Allow sweeter delivery of data to the front-end

  • Declarative style
    Tell the server what you need. Not how you want to get it.
  • Compositionality
    Achieve better flexibility in your code composing/combining fragments and queries
  • Strong typing
    Already hooked on TypeScript (strongly typed)

Facilitate team building…

  • Yay! Brand new toy!
  • Slowly building up a new, shared expertise
  • It does add a line on our resume…

…and heighten brand awareness / visibility

  • Expertise turned into content marketing, blog posts…
  • Makes our “exotic” stack shine a little more in job fairs
  • Allow us to come talk to you!

So, Let’s Round Up:

For the sake of full disclosure, we haven’t yet set up GraphQL on our stack. But it’s now something we may consider (after assessing hidden costs, risks, etc…)

It’s fun to see how we’ve been coming full circle from the early days of database-driven rendered web pages, i.e. :

  • render loop to render a page from the results of SQL queries results (the past — I’m talking PHP/HTML mish mash)
  • render loop to render a DOM from an AST born of raw data (the present)

It’s even funnier that, depending on whom you ask, the data access part is either near perfect and does not need to be reinvented, or is in a state of flux since day one despite great ORMs and optimizations, and that its problem domain should be re-framed to consider the needs of modern applications.

What I got from this experience is that out of an informal discussion over beers, we ended up with an interesting case study of how to expand our efficiency, and how to better work as a group and as a team, despite our differences.  The kernel of wisdom I’d pass on is to not shy away from getting into these discussions, and really get into the nitty gritty of any tech-related choice the company makes. It’s only by going at it that you can get a well-rounded picture of the pros, cons, and future implications of changing your tech stack, fiddling with a process or anything else. So go get talking!

For more details, you can check out the presentation slides here as well as our Twitter moment.

The post How Debating GraphQL got our Front and Back Developers Talking appeared first on CALLR Blog.



This post first appeared on CALLR's, please read the originial post: here

Share the post

How Debating GraphQL got our Front and Back Developers Talking

×

Subscribe to Callr's

Get updates delivered right to your inbox!

Thank you for your subscription

×