Skip to content

GraphQL is NOT Dead & $30m from VCs Proves It with Max Stroiber, Founder & CEO at Stellate

In the latest episode of the "Just Ship It" series, Tracy Lee welcomed Max Stoiber, co-founder of Stellate, for a conversation about Max's journey in open source and his experience as a co-founder.

Max's journey into open source began around 2016 when he created Styled Components, a popular open-source library. Tracy and Max reminisced about their initial meeting during Max's early days in open source, emphasizing the timeline of Max's contributions and conference appearances.

Max shed light on the founding of Stellate, a company specializing in GraphQL caching. He explained that Stellate was born out of the scaling challenges faced at his previous company, Spectrum. Their heavy use of GraphQL combined with the limitations of the RethinkDB database led to frequent crashes. To address this, Max came up with the idea of putting a cache in front of their GraphQL API, which ultimately led to the creation of Stellate.

Tracy touched on Stellate's current focus, and Max provided insights into their role in GraphQL caching, helping companies optimize their GraphQL APIs. Max acknowledged that while GraphQL adoption may have slowed down in some areas, it has gained substantial traction in large enterprises, solving organizational challenges at scale.

Max shared his approach of defaulting to open source, explaining how he maximizes "shots on goal" by creating numerous open-source projects. He also discussed his journey, from leaving university to becoming an open-source contributor and co-founder of Spectrum, highlighting the role of genuine interest in people and how it led to his involvement with Spectrum.

The episode offered valuable insights into Max's career, the challenges of being a founder, and the importance of company culture.

This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you’ll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey.

You might also like

How to Cultivate a Culture of Innovation, Intent, and Mission-Focus with Shanthala Rao, Chief Digital Development Officer at Primerica cover image

How to Cultivate a Culture of Innovation, Intent, and Mission-Focus with Shanthala Rao, Chief Digital Development Officer at Primerica

In the latest episode of Engineering Leadership, Rob Ocel talks with Shanthala Rao, the Chief Digital Development Officer at Primerica. The episode delves into Primerica's culture of innovation and intentionality, where they consistently strive to enhance their services while mitigating risks. It also touches on Primerica’s commitment to supporting the relationships between agents and their clients, and how the technology Shanthala’s team develops actually enhances human connection rather than replacing it. Shanthala emphasizes the significance of technical leadership in the financial services industry. She walks through her over 17 year career at Primerica and how her skills at building up teams and the culture of continuous learning and improvement at Primerica have helped her achieve success. Throughout the interview, Shanthala stresses the importance of understanding the core mission of your company in all of your technical decision making and development. For Primerica, that’s supporting the relationship between agents and their clients. For example, Primerica added ways for customers to be reminded of their agent and to connect directly to them. Even features such as adding self-service features for end-users support the mission by freeing up agents from having to do mundane tasks so they can focus more on meaningful relationship building. Shanthala explains how to overcome risk aversion as an organization and responsibly pursue technical innovation. At Primerica, they do this by keeping track of their architectural themes, creating room for developers to suggest new ideas and technologies, and to use proof-of-concepts to vet ideas before wider deployments. Finally, Shanthala discussed the challenges and opportunities in training the next generation of technical leaders at Primerica from the pool of current technologists. She explains how they intentionally provide technologists looking to enter leadership with additional mentoring and training to support their move into leadership. Even for those who return to development, they are enriched by the experience, carrying a broader perspective of the significance of their work....

Agile vs. Waterfall: Finding the Right Mix in Software Engineering with Dustin Goodman, Engineering Manager at This Dot Labs cover image

Agile vs. Waterfall: Finding the Right Mix in Software Engineering with Dustin Goodman, Engineering Manager at This Dot Labs

In this episode of the Engineering Leadership series, Tracy Lee and Dustin Goodman shed light on the advantages of combining different project management processes to create a more efficient and effective workflow. Dustin, an engineering manager who works at the development consultancy This Dot Labs, shared his insights on how he recently helps companies optimize their engineering processes. To illustrate, Dustin shared an example of a project he worked on. The company was aiming to deliver a feature set in three to four weeks. By implementing a combination of waterfall and agile methodologies, they were able to break down the project into smaller, manageable tasks and deliver results incrementally. This not only improved efficiency but also allowed for quicker feedback and iteration. One of the key takeaways from the discussion was the importance of understanding the highest value proposition and how it aligns with the organization's key performance indicators (KPIs) or objectives and key results (OKRs). By identifying the most valuable aspects of a project, teams can prioritize their efforts and ensure that they are delivering the most impactful results. Planning and flexibility were also highlighted as crucial elements in creating an effective workflow. While upfront planning is necessary to set clear goals and expectations, it is equally important to remain flexible and adapt to changing circumstances. This balance between planning and flexibility allows teams to respond to new information and make necessary adjustments without derailing the entire project. Tracy and Dustin also mentioned the example of 37 Signals, a company that follows a six-week timeline for each project from inception to delivery. This approach emphasizes the importance of setting realistic deadlines and maintaining a sense of urgency without sacrificing quality. Combining different project management processes, such as waterfall and agile, can create a more efficient and effective workflow. It is important to understand the highest value proposition and how it relates to the organization's KPIs or OKRs. Planning and flexibility are key, and it is important to be able to plan for the long-term, but also be able to pivot quickly when needed....

Testing a Fastify app with the NodeJS test runner cover image

Testing a Fastify app with the NodeJS test runner

Introduction Node.js has shipped a built-in test runner for a couple of major versions. Since its release I haven’t heard much about it so I decided to try it out on a simple Fastify API server application that I was working on. It turns out, it’s pretty good! It’s also really nice to start testing a node application without dealing with the hassle of installing some additional dependencies and managing more configurations. Since it’s got my stamp of approval, why not write a post about it? In this post, we will hit the highlights of the testing API and write some basic but real-life tests for an API server. This server will be built with Fastify, a plugin-centric API framework. They have some good documentation on testing that should make this pretty easy. We’ll also add a SQL driver for the plugin we will test. Setup Let's set up our simple API server by creating a new project, adding our dependencies, and creating some files. Ensure you’re running node v20 or greater (Test runner is a stable API as of the 20 major releases) Overview `index.js` - node entry that initializes our Fastify app and listens for incoming http requests on port 3001 `app.js` - this file exports a function that creates and returns our Fastify application instance `sql-plugin.js` - a Fastify plugin that sets up and connects to a SQL driver and makes it available on our app instance Application Code A simple first test For our first test we will just test our servers index route. If you recall from the app.js` code above, our index route returns a 501 response for “not implemented”. In this test, we're using the createApp` function to create a new instance of our Fastify app, and then using the `inject` method from the Fastify API to make a request to the `/` route. We import our test utilities directly from the node. Notice we can pass async functions to our test to use async/await. Node’s assert API has been around for a long time, this is what we are using to make our test assertions. To run this test, we can use the following command: By default the Node.js test runner uses the TAP reporter. You can configure it using other reporters or even create your own custom reporters for it to use. Testing our SQL plugin Next, let's take a look at how to test our Fastify Postgres plugin. This one is a bit more involved and gives us an opportunity to use more of the test runner features. In this example, we are using a feature called Subtests. This simply means when nested tests inside of a top-level test. In our top-level test call, we get a test parameter t` that we call methods on in our nested test structure. In this example, we use `t.beforeEach` to create a new Fastify app instance for each test, and call the `test` method to register our nested tests. Along with `beforeEach` the other methods you might expect are also available: `afterEach`, `before`, `after`. Since we don’t want to connect to our Postgres database in our tests, we are using the available Mocking API to mock out the client. This was the API that I was most excited to see included in the Node Test Runner. After the basics, you almost always need to mock some functions, methods, or libraries in your tests. After trying this feature, it works easily and as expected, I was confident that I could get pretty far testing with the new Node.js core API’s. Since my plugin only uses the end method of the Postgres driver, it’s the only method I provide a mock function for. Our second test confirms that it gets called when our Fastify server is shutting down. Additional features A lot of other features that are common in other popular testing frameworks are also available. Test styles and methods Along with our basic test` based tests we used for our Fastify plugins - `test` also includes `skip`, `todo`, and `only` methods. They are for what you would expect based on the names, skipping or only running certain tests, and work-in-progress tests. If you prefer, you also have the option of using the describe` → `it` test syntax. They both come with the same methods as `test` and I think it really comes down to a matter of personal preference. Test coverage This might be the deal breaker for some since this feature is still experimental. As popular as test coverage reporting is, I expect this API to be finalized and become stable in an upcoming version. Since this isn’t something that’s being shipped for the end user though, I say go for it. What’s the worst that could happen really? Other CLI flags —watch` - https://nodejs.org/dist/latest-v20.x/docs/api/cli.html#--watch —test-name-pattern` - https://nodejs.org/dist/latest-v20.x/docs/api/cli.html#--test-name-pattern TypeScript support You can use a loader like you would for a regular node application to execute TypeScript files. Some popular examples are tsx` and `ts-node`. In practice, I found that this currently doesn’t work well since the test runner only looks for JS file types. After digging in I found that they added support to locate your test files via a glob string but it won’t be available until the next major version release. Conclusion The built-in test runner is a lot more comprehensive than I expected it to be. I was able to easily write some real-world tests for my application. If you don’t mind some of the features like coverage reporting being experimental, you can get pretty far without installing any additional dependencies. The biggest deal breaker on many projects at this point, in my opinion, is the lack of straightforward TypeScript support. This is the test command that I ended up with in my application: I’ll be honest, I stole this from a GitHub issue thread and I don’t know exactly how it works (but it does). If TypeScript is a requirement, maybe stick with Jest or Vitest for now 🙂...