we've recently bootstrapped and launched codehooks.io, an easy serverless backend service for Node.js developers (JavaScript/Typescript). It provides a simple way to create custom microservices and integrations without the need for complicated server setup.
The main pitch is:
Build APIs and microservices in no time with a database powered serverless Node.js backend with zero config
Some ideas we've had so far include:
Writing articles and tutorials about using codehooks.io
Participating in relevant online communities and forums
Reaching out to potential partners and collaborators
Posting on LinkedIn and Twitter
We know this space is really competitive and there's a ton of well funded startups there. Today, we are partly funded by our mother-company restdb.io and lots of non-paid voluntary work.
Do you have any ideas or suggestions on how we can get more attention from developers for codehooks.io?
Or even better: some real feedback about the pitch and the positioning of the service.
How is this different and better from using something like lambda or serverless functions that the major clouds already provide? (which support many languages too)
Maybe open sourcing would help, but as you say, the space is crowded. Why would I want to add an extra external dependency to my vendor list just for serverless JS?
Iterating on your docs to make this clear in the first 15-30s will help.
Open sourcing and providing self hosting options for developers also helps
The main difference is that codehooks.io embeds a document database, a key-value store, a job scheduler and a worker queue without any config/setup. We want it to be easy to create a complete backend using codehooks.io in the shortest possible time.
Another difference is the speed and simplicity of deployment. Deployment typically takes 1 second or less. This increases developer productivity.
Our goal is that the developer can focus 100% on the application logic and 0% on the setup.
We have considered open sourcing it and we might do that at a later stage.
If I were evaluating this, my top four concerns would be:
1. "NoSQL document database with MongoDB-like queries ... powered by the open source database engine RocksDB" doesn't give me enough confidence that my application will work. Some limitations are unstated. For example:
(easy question) MongoDB documents are limited to 16 MB. Facebook's RocksDB Overview says "There is no limit to the size of a key or a value." Your insertOne documentation doesn't state a limit. Is it 16 MB?
(harder question) Your getMany documentation doesn't describe its interaction with the RocksDB "snapshot" concept (one of the big advantages of RocksDB over other NoSQL products). Facebook's Iterator documentation says "If ReadOptions.snapshot is given, the iterator will return data as of the snapshot. If it is nullptr, the iterator will read from an implicit snapshot as of the time the iterator is created. ... be aware that in case an iterator getting stale, it can block resource from being released. So make sure you destroy or refresh them if they are not used after some time, e.g. one second." Does this imply that each call to getMany operates on a unique snapshot? If so, do you plan to add an API in which the user can specify that multiple getMany calls must operate on the same snapshot?
2. The name of a space (e.g., "dev") is part of the URL used by clients. Is this avoidable? It can interfere with migration of applications to codehooks from other platforms.
3. Your story about unanticipated use (or abuse) seems to be 'We've got you covered by creating a price "ceiling", which reduces the price with 90%.' That's good but I would probably also need billing alerts. I would probably also want request rate limits similar to AWS WAF (e.g., 100 requests per IP address in a 5-minute period) without writing my own auth hooks.
4. I didn't find a discussion of runtime secrets (e.g., something like "flyctl secrets").
4 comments
[ 2.6 ms ] story [ 18.0 ms ] threadwe've recently bootstrapped and launched codehooks.io, an easy serverless backend service for Node.js developers (JavaScript/Typescript). It provides a simple way to create custom microservices and integrations without the need for complicated server setup.
The main pitch is:
Build APIs and microservices in no time with a database powered serverless Node.js backend with zero config
Some ideas we've had so far include:
We know this space is really competitive and there's a ton of well funded startups there. Today, we are partly funded by our mother-company restdb.io and lots of non-paid voluntary work.Do you have any ideas or suggestions on how we can get more attention from developers for codehooks.io?
Or even better: some real feedback about the pitch and the positioning of the service.
Thanks in advance for any help!
Martin Tornes / co-founder and maker
Maybe open sourcing would help, but as you say, the space is crowded. Why would I want to add an extra external dependency to my vendor list just for serverless JS?
Iterating on your docs to make this clear in the first 15-30s will help.
Open sourcing and providing self hosting options for developers also helps
The main difference is that codehooks.io embeds a document database, a key-value store, a job scheduler and a worker queue without any config/setup. We want it to be easy to create a complete backend using codehooks.io in the shortest possible time.
Another difference is the speed and simplicity of deployment. Deployment typically takes 1 second or less. This increases developer productivity.
Our goal is that the developer can focus 100% on the application logic and 0% on the setup.
We have considered open sourcing it and we might do that at a later stage.
1. "NoSQL document database with MongoDB-like queries ... powered by the open source database engine RocksDB" doesn't give me enough confidence that my application will work. Some limitations are unstated. For example:
(easy question) MongoDB documents are limited to 16 MB. Facebook's RocksDB Overview says "There is no limit to the size of a key or a value." Your insertOne documentation doesn't state a limit. Is it 16 MB?
(harder question) Your getMany documentation doesn't describe its interaction with the RocksDB "snapshot" concept (one of the big advantages of RocksDB over other NoSQL products). Facebook's Iterator documentation says "If ReadOptions.snapshot is given, the iterator will return data as of the snapshot. If it is nullptr, the iterator will read from an implicit snapshot as of the time the iterator is created. ... be aware that in case an iterator getting stale, it can block resource from being released. So make sure you destroy or refresh them if they are not used after some time, e.g. one second." Does this imply that each call to getMany operates on a unique snapshot? If so, do you plan to add an API in which the user can specify that multiple getMany calls must operate on the same snapshot?
2. The name of a space (e.g., "dev") is part of the URL used by clients. Is this avoidable? It can interfere with migration of applications to codehooks from other platforms.
3. Your story about unanticipated use (or abuse) seems to be 'We've got you covered by creating a price "ceiling", which reduces the price with 90%.' That's good but I would probably also need billing alerts. I would probably also want request rate limits similar to AWS WAF (e.g., 100 requests per IP address in a 5-minute period) without writing my own auth hooks.
4. I didn't find a discussion of runtime secrets (e.g., something like "flyctl secrets").