I wrote up some thoughts on my current approach to problem-solving in software. The more I create and grow projects, the more I recognize the importance of thoughtful methodology and valuing solutions over implementations.

A feature I encounter pretty frequently at some point in a project is user file uploads and management. Tackling that again this week. Each time there's a few nuances particular to the project, but some consistent themes are emerging - perhaps I can extract them into an open library.

Would love to learn of a project like that which already exists!

I don't remember why I signed up for Polywork but their onboarding was certainly intriguing. Still getting a handle on what this actually is...

With Labs is doing some really interesting things in the remote work and collaboration space - I'm excited to join as an early team member and help them build a great product! 🎉

Making list apps is just a pasttime for developers. My version is grocery lists.

My ideal grocery app would just let me grab recipes from anywhere on the internet and be smart enough to boil all the ingredients down to a single list for shopping day.

It started with an open-source ingredient merging library I harvested out of an old side project: ingredient-merge. From there, the rest should be simple - just create an interface for it! And for the most part, it was.

But then I started thinking - what if I start on my laptop and move to my phone? Do I really want to host a database for this?

I love a good challenge, so I started digging into peer-to-peer and distributed solutions. After trying a few I found a lightweight little library called bugout which is easy to use and super clever. It uses bittorrent as a signalling service for WebRTC!

This was a fun project, and best of all it was well-scoped. Unlike a lot of my ideas, I finally got to a point of satisfaction at which I got to say, "yeah, it's what I wanted it to be."

Of course these days I'm using Paprika or just winging it at the grocery store. But you know, what matters is learning! Perhaps someone else will find a use for ingredient-merge, too.

GraphQL is cool. Graph Databases are cool. But surprisingly, they aren't so cool to work with together.

While working on a startup idea I wanted to do just that- and ended up learning a lot about the internals of the GraphQL query resolution process.

The goal of graphql-arangodb is to translate whole GraphQL queries from the client into ArangoDB's AQL query language, so a single query from a client is translated into as few database queries as possible.

Another more subtle goal is to avoid coupling an external service API with database implementation details. I don't think generating GraphQL APIs for databases is really scalable. Our job as service designers is to bridge the gap from the structural needs of the data persistence layer with the business abstractions of the API. I wanted my library to respect and enable that.

It works pretty well! By annotating your GraphQL schema, you can assist the library in effectively translating between your API's models and the underlying database structure. It ships with some convenience decorators but you can also break out the big guns and write raw queries, interpolating in data from the GraphQL context.

I'm not actively maintaining it anymore, but it does do the job. If this seems up your alley, maybe you could take it over (or fork it)!