Avoiding Accidental Complexity When Structuring Your App State
Flux implementations like Redux encourage us to think explicitly about our app state and spend time modeling it. It turns out that this isn’t a trivial task. It’s a classic example of chaos theory, where a seemingly harmless flutter of wings in the wrong direction can cause a hurricane of accidental complexity later on.
Today I have sad news to share. After more than seven years of development, the company behind RethinkDB is shutting down. We worked very hard to make RethinkDB successful, but in spite of all our efforts we were ultimately unable to build a sustainable business. There is a lot of information to unpack – over the next few months, I’ll write about lessons learned so the startup community can benefit from our mistakes.
This is a bummer. I really liked RethinkDB a lot.
A fuzzy search / highlight that specialize for programmer text editor. It tries to provide intuitive result by recognizing patterns that people use while searching.
Looks like a very useful library with some well thought out rules for scoring matches based on match run length, character scoring, and preventing accidental acronym detection.
Choosing GraphQL to build Drift’s messaging platform
Like most internet companies today, we built our platform starting from a RESTful JSON API. But even with a clean slate, we still ran into familiar challenges that all API developers face: schema definition and introspection, versioning, paging, data aggregation and response shaping.
GraphQL allows you to create a schema that exposes your entire organization’s data model via read and write operations. This creates a single point of entry into your API and enables clients to ask in a single call what most REST JSON APIs take many calls to fulfill.
GraphQL is the post-REST API.
I did some work putting together GraphQL servers in Node and Elixir and really enjoyed the ease that clients had in getting the exact data they needed in a single call. It has a learning curve (but so did REST), but it really made for a better API experience.
Relay (and Apollo) are the client side companions for GraphQL. The learning curve for Realy was steep – it is very specific about its expectations for schema which is sometimes not so clear – but getting past the steep learning curve (it is very early) I was amazed that I had written no network/data code for my client app. That’s about 30% of the code for a comparable app that just isn’t there.
Why I believe GraphQL will come to replace REST
With REST, there is a continuous tension between efficiently satisfying the data needs of specific clients, and keeping the number of endpoints manageable. The reason for this tension is that a server defines what data an endpoint returns, and the client merely requests it. Especially in mobile apps, the overhead of performing separate requests or of requesting extraneous data is often unacceptable, so we’re forced to add ad-hoc endpoints with custom response structures.
This is something I’ve been thinking for a while now. I have spent many years building and advocating for RESTful APIs, but I’m ready to give them up. (although that’s not likely to happen yet)