Deriving A Data Model From A Design With GraphQL

Data modelling is one of those skills that’s needed at nearly all levels of the software development stack. It covers the full spectrum from information architecture to UI, to APIs, all the way to the underlying database tables. When it’s done well, everyone benefits. Customers can easily form accurate mental models, designers and engineers can work together effectively, and analysts can extract and interpret data in a meaningful way. All of this makes it a useful skill to develop. In this…

Read on
  1. Demystifying GraphQL Connections

    If you’ve used GraphQL for a while, it’s likely come across its (formally Relay’s) Connection Specification whether you’ve used it or not. It’s a pattern for implementing cursor-based pagination in GraphQL. Relay itself comes with first-class support for working with connections, but the pattern is often used in the wider GraphQL ecosystem — such as with Apollo. Over the years I’ve been working with GraphQL, I’ve seen a number of misconceptions pop up time and again. I’ll quickly address each…

    Read on
  2. Automatic Social Cards With Gatsby

    Note: Since writing this, the practice of automatic social cards has gained a bit of traction, and a number of people have written about alternative methods which are arguably better: Your Site's Calling Card by Shawn Wang Building an OpenGraph image generation API with Cloudinary, Netlify Functions, and React by Chris Biscardi Automatically Generate Social Images for Blog Posts by Jason Lengstorf On with the original content... When I decided to revamp my personal website and move my content…

    Read on
  3. The Passionless Developer

    For the longest time, a vocal opinion I would hear frequently was that good developers need to be passionate about programming. I’d be exposed to this opinion from my peers, from those senior to me, from people interviewing me, and from the development community as a whole. It reflects badly on me that, for a while, I believed it. We judge developers based on their Github contributions, on their Stack Overflow questions and answers, on whether they are active on Twitter. What these all have in…

    Read on
  4. For those Attending a Coding Bootcamp

    First, bit of background. I’m someone who taught himself how to build websites in the mid-90s. I did a Computer Science degree at one of the top universities in the UK, and I’ve been working professionally as a web developer for over 10 years. I’m not a big name developer, but I have a reasonably good reputation in the eyes of some people you may come across on social media. I’ve worked with a few people who’ve entered the industry after attending one of the 3 month coding bootcamps, and I was…

    Read on
  5. Optimising Your GraphQL Request Waterfalls

    As a technology, GraphQL is starting to gain traction. There are server implementations in a good selection of languages, and client support isn’t far behind. If you want to build your own GraphQL server, there’s plenty of information out there, but if you want to build an efficient one, there’s less guidance. I’ve been using GraphQL since it was a technical candidate, and have made plenty of mistakes along the way, but have been successful in making my GraphQL servers perform roughly as well as…

    Read on
  6. My Thoughts on Inline Styles

    React’s favoured approach to defining component markup (i.e. JSX) isn’t as controversial as it was 3 years ago when people caught their first glimpse of it. There are still many who dislike it out of (what I consider to be misplaced) principle, but most who try it tend to understand the benefits. The road to getting styles to be defined in the same manner — included directly in the component JavaScript file itself — has taken a more indirect route. I think there are two main reasons for this:…

    Read on
  7. You Might Need Server-Side Rendering

    There’s a popular idea within the React community that SSR (server-side rendering) isn’t necessary, and it’s a popular idea for some very attractive reasons. Firstly, it’s not trivial to get SSR working well. It involves a lot of bootstrap code on both client and server, and it often needs to be highly bespoke to your particular project. Additionally, React is very slow at rendering a component tree to a string on the server (there are tricks to speeding this up, but the most effective ones are…

    Read on
  8. Why I'm Not Using Your Datepicker

    Your poison of choice for building web UIs may vary, but one thing you can always depend on there being, is an ecosystem of feature-rich select boxes, popovers, modals, burger menus, and yes, date-pickers. I’ve been responsible for at least one of them . Aside from the dark times when I had no idea what I was doing with the DOM and ended up using jQuery UI, along with some flirting with chosen , select2 and selectize , I’ve usually tended towards committing the cardinal sin of programming…

    Read on
  9. Facebook’s Relay Isn’t For Me Yet

    Having worked with Relay more-or-less since it was released on a medium-sized in-house tool, i’ve concluded that despite solving a challenging problem in an elegant way, it’s not quite what I was looking for. To explain, I want to describe the path I took to the point where it appeared like Relay was exactly the solution I was looking for. I began by using jQuery to add small enhancements to pages. This grew into using jQuery for common functionality like carousels, modals, datepickers and…

    Read on
  10. Recipe-Oriented Documentation

    If i’m looking for a library to use in a project, I typically have some use cases in mind. Typically, a library would have been authored to solve a particular set of use cases. So it tends to follow that a library is a good fit if: The use cases align to a strong enough degree The library solves the problem well. Documentation in software projects tends to follow one or more of the following patterns: API-oriented . Typically generated automatically from the codebase and docstrings. This is…

    Read on