Hey all. I built Webhook with 2 other friends over the last 6 months. I'm mostly a designer, so understand that when asking me technical questions but here are a couple notes.
1. The name. I bought the domain over a year ago. The term wasn't as popular then. Originally the plan was to have the system auto-build after certain external hooks triggered. We still plan to do this and thought it was worthwhile using the name. It's a v1.
2. Funded through Kickstarter. We raised $40k through Kickstarter and are bootstrapped entirely. I plan on writing a blog post on the pros and cons of raising money this way.
3. We have plans to open source everything under MIT. It's three of us, so we wanted to get the product out first. We're now moving to documenting / refining the code to a level we're happy with so we can release it. It doesn't just run on a single server, so we're trying to figure out elegant ways to make it easier to install.
It works mostly as a simple Grunt JS (node) project. We use firebase as a data store and talk to everything through a single page cms.html ember app. That means the actual CMS is realtime, which makes it fun when multiple people are in the CMS as the same time. It also means that we can update the entire CMS by deploying JS files, which makes maintenance on our end pretty easy. "Bug is fixed, just refresh".
We use websockets locally for installing / generating files on the fly through browser actions. Once deployed, we watch for saves and rebuild the sites through remote servers. Search is handled through a hosted Elastic search instance. The goal was to remove as much of the local setup as possible and offload it to us. That means that it only works when you're connected to the Internet. Image resizes can be called at the template layer at will.
We made it after loving working with things like Jekyll and Cactus but hated that we couldn't use it for sites where there needed to be non-coding editors. Even with all the moving parts, it deploys dumb static sites, because we wanted reliability and speed. Also, having worked on complicated Django projects for the last decade I just wanted something that was a relatively one line install.
If you have any questions or suggestions please let me know.
That's great you're going to open source it. I think the plan is a bit expensive right now ($300 yearly). Maybe you could add a $10-15 a month plan? But if you want to keep up your service you might release an app (like Cactus has) as a GUI to the command line — but that only will interface with your servers.
So it's all rendered in the client-side, what about indexing and SEO?
The term 'webhook' has been in used for a few years already for http-based push notification systems, for example https://developer.github.com/webhooks/.
It's just a static site. Only the CMS is "dynamic" (though it itself is just a 10 line HTML page with a bunch of client side JS that talks to firebase).
Saves to that CMS, which is hosted statically, then send a build notification to our node based build servers, which then regenerate new static html files (from template you deployed to us) and send them to the proper place. Indexing and SEO are then just as they are for any other static site.
In local development, this is done through simple watch commands in Grunt, similar to what you'd see in something like Jekyll.
Yes, we think there's probably a separate product there as well. I'd always wanted to do something like the formbuilder but was usually trapped in more traditional dbs. Always got hung up on how you'd handle data migrations and the like. Moving to Firebase and working with essentially a string database in JSON really opened that side up. The only bummer is that we basically have to do lots of clean-up anytime there is relational data (which we allow through the system).
The CMS designer is the interesting part to your design, the static site part is easily handled through something like Varnish. Do you have further plans for extending the CMS designer?
I was one of the Kickstarter backers for Webhook. I remember when I first heard of the project, I frothed at the mouth in anticipation. Most static site builders out there lack the nice features you get in something like Wordpress which is the void Webhook aims to build.
Even though I sadly haven't had much time to play around with it as I would like, what I have seen and used is fantastic. The feature-set and ease-of-use is great. I'll put this on my list of priorities to check out even further this week, I'm still using Wordpress for a lot of sites, so time to give myself a kick in the bum and use it.
Love it, Dave! I've been using webhook for about a week now and it's amazing how well you can integrate it with front-end tools. I've been doing some experiments building rich-media apps with content manageable through the webhook CMS. I know a ton of people who should be using this, especially since you can have a developer build a site and then hand it off to end users. Just what I would expect from the Giant Bomb guys!
I'm a big fan of Webhook, though I must admit that as a Kickstarter backer, I never got the time to seriously play with it during my first month, so I need to circle back eventually. This is a great concept nonetheless and a real sign of innovation in the CMS space.
Wow, this is awesome! I agree the CMS form builder would be an great product just in its own.
Is there any way (currently) to populate fields in a CMS form based on live data (like entering multiple choice answers and then picking the correct answer)?
Hmm, if you mean forms on the front-facing website, currently no. You can inject data into your firebase following our json formatting guide though. If you go that route, the possibilities are pretty endless.
Extremely nice UX design! I started building something like this (static pages with cms) recently, it yours looks like a good enough realisation of the concept that I'll go with it instead of continuing my project.
As mentioned in my notes below we plan on open-sourcing everything and working towards that goal. For now, you can always simply deploy your build directory if you're working alone, but if you need something that automatically regenerates the site based upon other users edited the CMS, than right now our hosted platform is the only way to go (for now).
1. The name. I bought the domain over a year ago. The term wasn't as popular then. Originally the plan was to have the system auto-build after certain external hooks triggered. We still plan to do this and thought it was worthwhile using the name. It's a v1.
2. Funded through Kickstarter. We raised $40k through Kickstarter and are bootstrapped entirely. I plan on writing a blog post on the pros and cons of raising money this way.
3. We have plans to open source everything under MIT. It's three of us, so we wanted to get the product out first. We're now moving to documenting / refining the code to a level we're happy with so we can release it. It doesn't just run on a single server, so we're trying to figure out elegant ways to make it easier to install.
It works mostly as a simple Grunt JS (node) project. We use firebase as a data store and talk to everything through a single page cms.html ember app. That means the actual CMS is realtime, which makes it fun when multiple people are in the CMS as the same time. It also means that we can update the entire CMS by deploying JS files, which makes maintenance on our end pretty easy. "Bug is fixed, just refresh".
We use websockets locally for installing / generating files on the fly through browser actions. Once deployed, we watch for saves and rebuild the sites through remote servers. Search is handled through a hosted Elastic search instance. The goal was to remove as much of the local setup as possible and offload it to us. That means that it only works when you're connected to the Internet. Image resizes can be called at the template layer at will.
We made it after loving working with things like Jekyll and Cactus but hated that we couldn't use it for sites where there needed to be non-coding editors. Even with all the moving parts, it deploys dumb static sites, because we wanted reliability and speed. Also, having worked on complicated Django projects for the last decade I just wanted something that was a relatively one line install.
If you have any questions or suggestions please let me know.