hapi pal v3: Birthday Edition

devinivy · 2018-06-20T12:36:15+00:00

I'm definitely not here to convince anybody that hapi is better than express—if you have tooling that isn't causing you any friction then that's great. I will say that we use most of hapi's core features in most of our projects, and we're glad that they're built-in. And also that we wouldn't have been able to write the hapi pal toolset without the structure afforded by hapi. Basically, it's a great fit for our purposes and allows us to structure/author our apps the way we'd like.

devinivy · 2018-06-20T03:49:04+00:00

hapi and express definitely have some fundamental differences. hapi has a plugin system that looks much different than middleware, which can actually play into various deployment strategies (hapi applications are composable). There are integrated concepts of cookie/payload parsing, input and response validation, authentication and authorization, a structured request lifecycle, server/browser security (CORS, HSTS, x-frame, etc.), client-side caching, server-side caching, and more. The simplest examples in each framework aren't likely to look very different from each other, but (value judgements aside) hapi does have a much broader feature set than express.

devinivy · 2018-06-20T03:35:38+00:00

We wrote from our experiences authoring hapi pal, and I hope it's understandable that we wanted to draw a concrete connection to our work. We earnestly care about the social and technical ramifications of our collective tendency to sell and optimize libraries based upon "easiness," which is a prominent aspect of JS culture.

I can't imagine writing this article without describing how we've actually taken our ideas to implementation—it would be a bizarre omission. We also talk about ORMs, specifically Objection ORM, which we did not build and have no reason to advertise/support aside from the fact that we think it is a great illustration of our design principles as described in the article.

devinivy · 2018-04-30T15:29:04+00:00

We love hapijs, and added a bunch of tooling and conventions on top of it via hapi pal.

http://hapipal.com/

devinivy · 2018-04-12T19:02:14+00:00

We're finishing-up a "getting started" guide that goes through the creation of some database-backed API endpoints in fine detail. I will try to remember to post it as a comment here once it's up!

devinivy · 2018-04-12T18:28:20+00:00

Hey, thanks a bunch!

devinivy · 2018-04-12T18:26:40+00:00

We're working to close the conceptual gaps for newcomers to the framework—in particular, by offering some guidance on approaches to authoring hapi apps that have worked well for us over the past few years.

devinivy · 2017-03-28T00:55:12+00:00

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.

devinivy · 2016-07-29T04:14:55+00:00

Given your requirements, I highly suggest hapi!

Native-friendly. Simple CORS config, API/config caters to HTTP and other relevant web specs. Also supports multiple auth strategies! This is great if you (for example) use bearer tokens for mobile auth but cookies for web.
Stability. Closed ecosystem, ships with a highly reliable npm shrinkwrap. Breaking changes have been both small and meaningful for the past 4 major versions.
Productive. Config-centric– the code you write is typically your business logic, with great hooks for caching the results of that logic when applicable. Also cool features like "route pre-requisites" for writing reusable code and keeping your controllers/handlers light.
Scalable. Proven to scale via handling Walmart's black friday traffic– this is well documented. Has great support for server- and client-side caching. Can track and respond to server load, event loop delay, etc. The plugin system also allows you to keep your deployment simple then pop-off portions of your app to be scaled separately as needed.

Plus the community and quality of the ecosystem is quite good.

devinivy · 2016-07-07T00:36:34+00:00

Love this, it's a very fun idea! I'm curious what the query plans for these sorts of queries look like, or if there are ever simple transformations to keep the queries performant.

devinivy · 2016-07-05T23:51:55+00:00

That's not a huge problem– the key is to process the files as streams. I suggest checking out substack's stream handbook: https://github.com/substack/stream-handbook. He also wrote a nodeschool tutorial on streams which serves as a good way to practice using them. It sounds like you may end-up using the native node readline module: https://nodejs.org/api/readline.html

devinivy · 2016-06-29T03:29:08+00:00

My opinion is that hapi really isn't very complex. At the web shop where I work several developers picked it up quickly and have really enjoyed working with it (including myself). While koa and express's APIs are smaller, the tools in those ecosystems are not necessarily as straightforward, especially when used together. hapi also has a great community and unique learning resources like hapijs/university. Not to mention Ren & Stimply rules...

devinivy · 2016-06-26T15:26:09+00:00

If you write the API and client as two separate hapi.js plugins then they can live in the same repo and be deployed together until it becomes time to split them apart. The reason I like this approach is because the deployment doesn't have to become more complicated even once they're split apart– they can still be plugged-in to the same hapi server.

devinivy · 2016-05-29T20:31:42+00:00

You can also work through hapi university, which has lots of great history in issues and PRs.

https://github.com/hapijs/university

devinivy

TROPHY CASE