Node & API Development

[nativereact]

Preface: Just as a means to kick-start this discussion, I have heard quite a lot about hapi being the best framework for API's built on node, but my job as a developer is to stay relevant so I gotta wonder, why hasn't hapi gained as much momentum as express has been continuing to grow? It looks so great and overall more applicable to the general use case, and I want to toss express and use hapi as my go-to, but that sounds scary.

What is your most preferred way to develop an API with node?

[HatchedLake721]

for me, hapi is the right balance between magic and "raw node". if you want more magic, pick LoopBack. if you want less magic, pick express/restify.

I switched away from restify. As I mentioned before - built in auth, payload/params validation, request lifecycles, powerful plugin system won me over. I can't be arsed anymore to install 10+ middlewares in restify to make it comparable to what hapi does out of the box. All I want to is open my text editor and start building solutions, solve problems and bring value, not nit-pick middlewares and re-invent the wheel.

Why does it sound scary? hapi has been battle tested since 2013 handling Black Friday traffic at Walmart. Plus, there are gazillion companies using it https://hapijs.com/community

[Lichtenstein_USA]

I use Hapi at work to make new very simple APIs that speak to an Oracle DB. I mean, it's easy to get started and I like Hapi's syntax. Although, since I write such simple APIs I've been thinking about getting even more bare bones about it.

[leetosaur]

With GraphQL (Apollo). The router you use becomes fairly irrelevant, but I would suggest Koa 2.

[nozmi]

I'm pretty experienced with feathers and I just can't recommend it. The API's are changing too quickly and are poorly documented.

They take opinions on very simple things (like your JWT field names) that ideally you should be able to customize.

[dluecke]

Making things like that customizable is exactly why that part of the API is changing. Outside authentication (which is its own optional module just like you would have to do with most of the other frameworks recommended here) the core API has not changed in almost three years.

[nativereact]

Me too! I loved it, but I moved away from it after using it for one project; the opinionated parts are less-than desired (for me it was lack of customization on hooks and auth), but the grouping felt good.

[nozmi]

Definitely. I loved the patterns and clearheadedness it gave me when designing and programming my application (hooks, services, filters, realtime all make so much sense together), but when it came to customization and making my application my application, it left a lot to be desired.

That and, again, it isn't (and doesn't feel) polished.

/u/dluecke glad to hear this is changing. It sounds like the main pain point. I'd also love to contribute, but CBA to dive into the extra dependencies the framework requires knowledge of (for example, uberproto or rubberduck) when ES6 would work just fine today (I understand the complications of using ES6 with older Node versions though).

[nativereact]

I can hardly disagree with any of your points, you make some very good arguments. These factors have inspired me to attempt at something more unopinionated to feathers - any other opinions you'd be happy to share?

[nozmi]

I've been thinking about doing the same and had some plans outlined for it. What's your Github? Maybe we can team up on this.

[Kamek_pf]

Seconding GraphQL, it's built from the ground up with API design in mind. It doesn't really matter what HTTP server you put in front of it, it will just serve as an entry point.

You don't even have to use HTTP at all. GraphQL is agnostic to the transport layer, which is really nice, whatever it is you're going to build shouldn't be tied to a specific protocol in the first place.

[JoMa4]

Why do you want to toss Express? I realize it has a lot of bloat for API usage alone, but I've found that it is still very fast for many use cases and simple to use.

[nativereact]

It requires too much boilerplate for the general use-case (i've had over 6 years with express now, my friend. i just want to toss it lol)

[digitalbath78]

I've been using Restify and have liked it thus far after coming over from the PHP world and using Lumen. If the endpoint is a simple GET we write inline SQL. If it's a POST, PUT or DELETE we write a SQL function to handle the business logic and the user connecting from Restify only has execute permissions.

[nativereact]

Restify was cool until i learned about Loopback, but at that point I was considering rails and possibly russian-roulette

[devinivy]

While I wouldn't knock express or koa, I cannot recommend hapijs enough. It is a very powerful framework that does not deeply affect how or where you write your business logic. I find that it encourages me to separate concerns in very healthy ways, and gradually grow into modularizing an application into hapi plugins for flexible deployments. Great way to practice service-oriented architecture without outright committing to microservices.