&yet

When writing your APIs for a microservice, special care should be taken to properly plan out auth and permissions since parts of your user system will be handled by other services. Previously, we introduced Yeti Threads as a case study for writing microservices in Node.js. This time, we’ll be diving into the Auth strategy in this case study.

“Auth” is really short for two things, authentication and authorization. Microservices don’t provide their own authentication, but they’re in charge of at least enforcing their own authorization, if not tracking the permissions as well. In this case, OpenID Connect gives us a JWT token encoded with a user identity and scopes of authorization (perhaps from Auth0, or one that we at &yet helped you customize and deploy). The microservice can trust these values because they’re signed by a private key that only the services themselves know, and can validate the signature. The scopes are a list of tags, typically indicating which sets of actions and endpoints are allowed.

In Yeti Threads, you might notice that we don’t have a users table in the database. Since we trust the identity and scopes in the signed JWT, we can simply treat the user id as an opaque string; it doesn’t matter what it is, as long as it uniquely identifies a user. I also decided that I didn’t need a scope for most actions, except for modifying permissions, in which case we need them to have 'forum_admin' in their scopes. Look at the access.js controller and you’ll see that the handlers specify an auth.scope (which is a handy hapi handler feature).

Node.js APIs shouldn’t have to involve any guesswork, so I set out to create a case study Node.js microservice API that had all of the rough edges smoothed off. It was also a good chance to play with some new Postgres JSON features. Thus, the Yeti Threads API was born. The Yeti Threads API is a conversation threading forum API. It’s MIT licensed, so feel free to use it to add conversation threading to your applications.

Writing APIs in Node.js should be really, really straightforward, even if you’re doing live eventing. You’re probably exposing a REST API that has basic Create Read Update Delete handlers that roughly translate to some database calls. You’re probably sending basic updates over a websocket based on the changes to the database. These things are so well established, that several products out there attempt to commoditize these sorts of APIs.

Let’s talk about tool choice first.

We humans are a funny bunch. By our nature, we’re both creators and consumers. You might even say those are the most basic instincts we act on for our survival. But, even though we’re both, when we’re in one role, we tend to do a pretty bad job of considering the other role. To wit, in the capitalist society that most of us live in, many businesses have been built around exploiting our own penchant for consuming for the sake of profit and not necessarily the betterment of the consumer or our society (broadly, “survival”).

Generally, those businesses are built on the idea that the business can most successfully extract maximum value from a customer by minimizing their costs, and by doing this they’ve met their requirement for existing.

This can create some success, but what creates long-term sustained success, for both the company and society? We strongly agree with the many people who are much smarter than we are, who say that it’s making a connection with your customer/client/consumer/user.

At &yet, we fundamentally believe that goods and services can be created in such a way that first and foremost creates a human connection between the person that uses or buys a product or service and the business that created it.

Conferences are an art form.

I didn’t always believe this, but I certainly have since I started going to exceptionally and intentionally designed events.

In an information dense world, connection and meaning are things we hunger for—and those are what the majority of people are really looking for in a conference.

It’s not the content. It’s the people. It's the connections between them and inspiration and personal reflection that the content makes possible. It’s the new direction in their life that attendees choose because of one long conversation in a corner. It’s the idea they are exposed to alongside meeting the person it originated from that sets their future trajectory.

It is with many yeti tears that we bid a fond farewell to one of our deepest friends, Henrik Joreteg.

Henrik has made the difficult choice to leave our team to pursue the many exciting and challenging experiences awaiting him. Although we look forward to working together with Henrik in the future, we will definitely miss hearing his puntastic dadcore jokes in the hallway and hearing the pitter patter of those weird toe shoes he wears.

All joking aside, while we are saddened to lose such an amazing teammate, we are 1000% behind Henrik pursuing his dreams. Henrik heavily contributed to making us one of the best Node consultancies around, and helped us push our capabilities within the bleeding edge of realtime technologies. He will be greatly missed in the many adventures ahead of our team.

To Henrik, Heinrich, and even, Roosterick — we wouldn’t be where we are today without you, and we are deeply grateful for the impact you’ve had on our work, our team, our ideas, and each of us individually. We wish you nothing but the very best in your next chapter. <&

Every once in a while something new comes along that just feels right.

When this happens, I get a tingly feeling in my left pinky toe. That’s how I know it’s not just a fad. It’s how I know it’s legit.

My pinky toe has a pretty decent track record:

• It first tingled when I moved an element on the page with jQuery.
• It tingled when Backbone.js came out. I blogged about it in 2010
• It tingled when I pushed my first message from server to client with Socket.io and Node.js
• It tingled with React after I got over “JSX shock”
• It’s been tingling for a few weeks straight now about a thing called Redux.

Today &yet’s favorite Node.js web framework, hapi, turns four years old. We’ve had some great experiences with hapi and are both excited and proud to continue to be a part of the community surrounding it.

Eran Hammer started working on what would eventually become hapi in November of 2010 while working for Yahoo on a project named Sled. Sled was shut down almost a year later in August of 2011 and opensourced as Postmile which has been one of the primary examples of building a complex application in hapi since day one.

Later that same month, Eran created the hapi module as a collection of components extracted from Postmile that were used to build on top of Express. The name hapi was chosen as an acronym for HTTP API, but once it was spoken out loud, the connection to Ren and Stimpy was made. Eran later presented hapi to Walmart, where the effort was referred to as Blammo. After years of continued development, hapi has grown into its own unique and powerful framework with an outstanding and helpful community.

&yet started using hapi over two years ago and quickly became enamored with it. After nearly a year of contributing bug fixes, writing plugins, and being a part of developing the new site, I was made a core contributor in March of 2014. Since then I’ve been super proud to continue helping out the community any way that I’m able.

It’s been a while since I last wrote about testing WebRTC applications. And guess what? There has been some progress. We’re now using Travis-CI for integration tests in combination with Selenium for UI testing.

The usage of Travis-CI has been described quite a while ago by our rtc.io friends. It is now being used by adapter.js which has recently become a dependency of our core modules like getUserMedia and RTCPeerConnection since it shims the differences between browsers and is maintained by people from Google and Mozilla.

What Travis does is run a series of tests on every pull request. Thanks to travis-multirunner this is running the testsuite (located here for adapter.js) in different versions of Chrome and Firefox. If the tests pass and jshint and jscs don’t find any style nits, there is a nice green badge:

With the amount of content available for us to consume it's very hard to pick what to dive into. People read at different paces, often times not in their native language. At &yet, we are quite keen on reading too. There are many books that have made us laugh or taught us about design or technology; but only a few truly challenged the way we think and act—some of them to the point of knowing excerpts by heart.

Today I want to share five publications that shed a light on collaboration, as well as a range of social issues. Each of these books have helped make us better partners, friends and teammates—and above all, better humans.

Whether you read one or all of them, hopefully they will have the same profound effect on you as well.

"Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration"

Yup. You can describe animations in JavaScript and generates CSS strings of @keyframe animations and insert them at runtime using <style> tags.

Sounds a bit wacky right? Why would you do this!?!

Well... because it’s fun, of course!

Here’s what I built with these techniques: SEE THE DEMO