• 17 Commits
  • 17 Pushes
  • 7 Deploys
Launch Site


By Openly

Quick Intro

Superfast, real-time page caching with push control. noDelay puts your application in control of its content. The cache reload is defined by the application not by the TTL.


It is a caching server, similar to varnish.

Using the noDelay API your application pushes content up to the cache ensuring your content is always available from cache to your end-users, no more waiting for TTLs to expire or slow page loads for the first user. Reach more people with less resources, noDelay reduces the server requests to the absolute minimum.

  • Note Unfortuntely due to our over optomistic expectations and a touch of missing domain knowledge we bit of more that we could chew and the application currently only caches GET requests.
What they Used

expressjs, async, underscore



Your Vote

Voting is now closed.

Other Votes

  • (9)
  • judge

    Filter Squad

    It's definitely a useful idea - making caching easier for developers is a problem definitely worthy of being solved. Unfortunately, the obvious issue with that is that it's actually very hard to define ahead of time all the resources to expire.

    It's hard to judge as there doesn't appear to be any docs on the api to revoke stuff - which is the hardest part. Likewise, it's hard to judge the caching is actually working - but the pages did update as you'd commented. My score is primarily based on that, but It's hard to judge without more details on what it's doing how it works, sorry!

    Also, you mention it only caches GET requests - Ideally, that's all it should cache anyway - as almost everything else shouldn't be cacheable full stop from a HTTP perspective (e.g. POST, PUT, etc).

  • contestant
  • contestant


    Interesting idea. The site's design is very simple.

  • contestant


    This works if we own the caching server, but that's usually not the case. Still, I love things that go fast. Great idea!

  • contestant

    Great concept app, and an interesting use of node.js.

    As it is a very technical submission it's hard to judge how successful it is in practice and it feels a little incomplete. Maybe the technical judges will have a view once they've checked out the code?

    Nice idea though!

  • judge


    Not very innovative. Doesn't say how a developer can integrate with openly. Is it a library or a service? Both?

  • judge

    I think the concept could be explained better. It was not clear from the demo how and what exactly this project does.

  • contestant


    Curious as to the benefit of this over existing proven solutions like Varnish. Also, curious as to how you are calling out to the server from WP - does it make another HTTP request to itself or something? The demo seemed cool enough - kind of hard to determine the "effect" without some sort of a side-by-side comparison, but I get that the real point of this is giving programmatic cache control to the application sitting behind the cache.

    Also, have you thought how this is going to work when you're in a cluster of distributed servers sitting in front of the backend? Interesting project :)

    • abhihebbar


      We have tried to provide a proof of concept here. There are a lot of compromises here in this build.

      Whenever there is a change in content in WP, like adding a post, modifying a post, adding a comment etc, the Plugin in the wordpress calls the noDelay API, and asks noDelay to refresh the particular resources. In the current wordpress plugin, it just does so when you add/edit a post. Also the wordpress plugin just asks noDelay to reload the post page and the categories page.

      The cached items in noDelay will not have a lifetime. Once cache it will be there for ever, unless the application asks it to reload. This can be related to something like a static web server. However the static content can be replaced by any backend application through the API.

      I am not very sure, how this could work with cluster of distributed servers. I think the major advantage a caching server like Varnish gets by multiple backends is redundancy. But in this case, the cache does not contact the application server at all unless the application asks it to do so. So I am not sure of the need for redundancy.

      Also, we wanted to work on optimizing the cached resources similar to google pagespeed. However we were not able to do that in 48 hours.

      Thanks for your vote and comment.

  • contestant

    Industrial Web Apps

    Was able to add a new post, but it didn't show up anywhere in the site. Was able to navigate to it by putting the ID in the URL. Not really sure I understand exactly what this does.


SEP 15
NOV 9-15
NOV 16