Courier Blog

> I like include asciidoctor[1] and mdbook [2]. Though I find that even those are overkill for my hobby projects at least ...

That's one thing: Docusaurus is not necessary just for hobby projects where the doc only exists for yourself and a few users. It can be used for hobby project but it can also scale for much larger projects where the doc is a critical part of the success of the project, and where the company behind is willing to invest thousands of dollars to have a really great doc. For example, the doc of React-Native is critical for React-Native success: https://reactnative.dev

> I prefer to use them anyway because of support/updates and to leave something others can manage themselves later.

If you have a small project, you can also use Docusaurus in a very simple way, and stick to our stock template (which looks like this: https://tutorial.docusaurus.io/)

The only thing you'll need is to leave a folder of Markdown files to your colleagues, that's all.

I have planned to add a very simple CLI on top of Docusaurus to make it even easier: just run "npx yolodoc ./my-md-docs-folder" and it will build your simple Docusaurus site => No need to install anything, know that it's using React/MDX/TS or whatever: the only thing you'd need is to have Node.js installed (which is not more complicated to install than Python or Ruby btw)

> This comment seems to show we come from very different worlds. Why do you believe you need JS to create documentation??

I don't believe…

Great article. All of this complexity is the reason I started Courier (YC S19) [0], which we just launched on HN [1] a few days ago. :-)

We take the approach of essentially offering an abstraction layer that lets you route to one or more channels based on data related to the notification event instead of having to hardcode the integration at the callsite. This has the added benefit of also letting you pull the template abstraction into the same space (so you don't go crazy manually maintaining HTML templates for email, plain text for SMS, BlockKit for Slack, etc. etc.)

FYI we support integrations for nearly all of the channels mentioned here: email (via SMTP, SendGrid, SES, and others), Discord, SMS (via Twilio and others), web push, WhatsApp (via Twilio WhatsApp), Slack, & PagerDuty. And many others...

[0]: https://www.courier.com/

[1]: https://news.ycombinator.com/item?id=30527757

Full disclosure: I work at Courier.

Courier Inbox comes with web and mobile SDKs that are highly customizable, and we wanted to push the limits and see what we could build using them. We landed on the idea of Puppygram, an Instagram clone that displays nothing but pictures of cute puppies. We built the server using Next.js, Random.dog and Inngest.

We wrote-up a technical tear-down blog post [1] and have posted all source code [2] [3] on Github.

Happy hacking!

[1] https://www.courier.com/blog/introducing-puppygram-powered-by-courier-inbox-next-js-and-inngest/

[2] https://github.com/trycourier/courier-nextjs-puppygram

[3] https://github.com/trycourier/puppygram-ios

https://www.courier.com/docs/guides/tutorials/how-to-configure-multi-channel-routing/

Leonardo DiCaprio sitting up in chair pointing at the tv screen

I kid you not two days ago I said to my Jr. SRE "We need a way to bifurcate an alert to multiple channels via webhook" due to our unique observability needs and slaps knee here it is. We were about to launch off and try building something this quarter, and then here you come down off the mountain.

Congrats on launching, looking forward to kicking some tires tomorrow morning.