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?
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.