Some thoughts on API frameworks for side projects
As any developer and wantrepreneur out there, I have a decent list of ideas. I do follow Product Hunt and Indiehackers, started a few side projects and still can’t get anything done that I can consider as “ready for production”.
There are many reasons why most side projects and startups fail, could be a business model, marketing, execution, money problems or just a bad idea. In my case, projects fail even before they get half way done, because I get frustrated with the technology I am using. Next thing I do is switch to a new framework and then newer one and then another one. Even though the whole idea of a side project is using a new technology to build something that you’re passioned about, the end goal should be to release it.
Now, I realize what the problem is and am actively trying to solve it. The problem is that there is not one framework that has everything out of the box. Some may call it the “ideal” framework. It used to be Meteor.js for me, but then MDG switched their efforts to Apollo and Meteor is not the same anymore. Services like firebase are nice but they have lots of limitations how to structure and map the data, and you don’t have full control.
My ideal “framework” would be something like this (assume all projects have authentication, unless it’s another to-do list with localStorage 👻):
- Front end
- Services and API
- Integration with a databases (SQL and NoSQL)
- Deployment (CI/CD)
I got the front-end part figured out. My stack of choice is React/Redux. Although it’s still painful to set up a boilerplate code (connect react-router, configure redux, I know… yes I will need redux, add authentication state and permission validation).
Services and API is where I’m struggling. I’ve written my own APIs before with Rails, Meteor, Express and GraphQL. Rails handled most of the boilerplate and made the process the least painful. But I won’t be using Rail for a number of reasons. I’m looking at Node.js solutions, and every blog and book just screams Express.js as the best choice for API. But it’s not an API framework, it’s unopinionated, minimalist web framework with few middlewares and a server. If you want to build an API with Express — write everything yourself. I could, but that’s not the point. The point is: I want an API framework that handles a lot of the boilerplate for me and I can focus on designing my services and business logic.
GraphQL is the future of API development, I truly believe it. And it’s very easy to build GraphQL server, connect to DB and bam you have a basic API service. That’s where it stops. If you want to add authentication and authorization — roll up your sleeves and build your own authentication. Want to use Auth0? Good luck finding a consistent documentation how to do it server side (creating user, authentication, password reset and permissions). But it’s one of the best auth services and probably the only choice.
Graph.cool is cool 😎, they do everything I need: auth, GraphQL, generating queries and mutations, even nice UI. My only concern is that it will change before I finish my project.
I love the idea of serverless, especially for small projects. Run on demand, practically for free. But authentication, permissions, manual DB operations are way too much work for small project, especially if you’re planning to scale at least a little bit. Here is my attempt to make it work.
At this point, I’ve committed to build at least one project with FeathersJS, which is so close to my ideal API framework. No GraphQL support though, but that’s ok for now. It looks like a full, production ready framework.
I am trying to use few frameworks now and hopefully start contributing to the one or two that are the closest to my ideal. Or build my own boilerplate that takes care of all common scenarios. If you’re interested, hit me up on Twitter. If you found your ideal framework, please share in the comments, I would appreciated that very much.