⚠ Please note that this pro­ject is go­ing to be pri­vate mov­ing for­ward, as well as is un­der­go­ing a huge in­ter­nal refac­tor based on many of my re­cent learn­ings around Express.js.




🐢 Ongoing



Stargazers on GitHub ⭐

Tools Used/Explored

  • Express.js
  • TypeScript
  • Jest
  • Docker
  • Svelte
  • Redis
  • Verdaccio

A foray into back-end web de­vel­op­ment.

Since mod­ern front-end web de­vel­op­ment — ReactJS, Angular, & other frame­works, server­less ar­chi­tec­ture, and JAMStack — have ush­ered in a whole ar­ray of back­end con­cepts to the fron­tend, I fi­nally scratched my itch to get started on gain­ing some fa­mil­iar­ity with the back­end it­self — po­ten­tially to open up an av­enue to be­come a full-stack de­vel­oper.

I en­vi­sioned the back­end to be a very com­plex mono­lith, and de­cided to have strongly typed code with TypeScript. Why? So this could help me and my IDE make sense of every­thing in the long run. Even though I had lit­tle idea of TypeScript at the on-set, this has given me a well-rounded overview of its ba­sic us­age al­ready.

Becoming fa­mil­iar with ad­vanced JavaScript con­cepts.

Once a post is pub­lished, Celestial knows where the post will even­tu­ally show up. Static sites like mine, how­ever, take time to build; this could range from a few sec­onds to a few min­utes. This caused me un­nec­es­sary headache as I kept re­fresh­ing the post link to check if the post has been pub­lished and if every­thing looks OK.

I de­cided to im­ple­ment some sort of an au­to­mated check in the user's broswer. My pro­ject men­tor then hopped on to a cod­ing ses­sion with me and we fig­ured out to­gether how to im­ple­ment this.

Ultimately, I im­ple­mented a re­peati­tive check in the browser it­self us­ing Svelte, which ex­posed me to clo­sures and the fac­tory de­sign pat­tern. Every few sec­onds, we make a call to the post link to see if it has been pub­lished yet. When the post is pub­lished and ver­i­fied through our checks, we au­to­mat­i­cally play an au­dio sound us­ing the Web Audio API.

Problem solved! 🥳

Understanding and im­ple­ment­ing stan­dards/​spec­i­fi­ca­tions.

This pro­ject im­ple­ments two spec­i­fi­ca­tions so far: Micropub and IndieAuth.

I im­ple­mented IndieAuth in about a week, en­sur­ing a high de­gree of com­pli­ance with the orig­i­nal spec­i­fi­ca­tion. My work still con­tin­ues as far as Micropub com­pli­ance is con­cerned.

Still, this gives me yet an­other in­sight into work­ing with doc­u­men­ta­tion writ­ten by some­one else, and hope­fully some idea on how to write one of my own!

What's IndieAuth?

Imagine you dis­cover a new site that does some­thing cool, but you need to sign up to ac­cess their ser­vices. Pretty nor­mal stuff on the mod­ern web, right? You are also su­per likely to see op­tions like, Sign in with Facebook, Sign in with Google, and so on - be­cause they re­ally want you to sign in ef­fort­lessly and per­haps even lever­age more ac­cu­rate data from your Facebook and Google pro­files.

Now imag­ine if there was an­other method to let you sign up and in: Sign in with your web­site. Sounds strange? It did to me too!

My web­site is hosted on, so I type it in and hit sign in. My iden­tity is then ver­i­fied per­haps by an email code, or my GitHub pro­file in this case, and the web­site now has some ba­sic de­tails about me based on my h-card, as can be seen be­low:

IndieAuth is a pro­to­col built on top of OAuth 2.0. The spec­i­fi­ca­tion is a Living Standard and can be viewed on IndieWeb's web­site. This pro­ject im­ple­ments IndieAuth with changes up to .

Planning front to back.

While the pro­ject started with just a plan in my head and a rough roadmap to v1 in the README file, I kept grow­ing it to in­clude v2 and v3 fea­tures as well as re­fin­ing the v1 roadmap.

Ultimately, I now have a whole bunch of is­sues, pro­jects, and mile­stones ready to guide me. Given that I have con­sciously slowed down the de­vel­op­ment, this is im­mensely help­ful to guide me in pick­ing up new fea­tures. Another ben­e­fit is it gives folks an idea of where the pro­ject is and how things are go­ing at any given point.

For ex­am­ple, here's a look at the v1 mile­stone page:

And, here's a look at just one of the pro­jects, UI & UX:

Building re­li­able soft­ware with unit-test­ing.

Unit test­ing had eluded me for so long it wasn't cool any­more. I have al­ways looked at pro­jects with tests as well-done” pro­jects. It only made sense that at this stage in my ca­reer, I bet­ter get down to busi­ness on this front. Jest was my choice of unit-test­ing suite as it ad­ver­tised out-of-the-box sup­port for TypeScript.

I al­ready have gath­ered a bit of idea around what not to test, how to mock an API call, and how to take snap­shots. Armed with this knowl­edge, I ex­pect us­ing Jest to test ReactJS code might not be so dif­fer­ent.

Building and us­ing pri­vate, in­de­pen­dent & reusable mod­ules.

When Celestial's de­vel­op­ment went pri­vate, one of the first is­sue I faced was the in­abil­ity to dis­trib­ute my newly-crafted IndieAuth mod­ule to the core ap­pli­ca­tion. Well, not with­out spend­ing USD 7/month on to gain the abil­ity to pub­lish and fetch a pri­vate pack­age.

Between git sub­mod­ules and lerna-based monorepo, I fi­nally set­tled on self-host­ing an in­stance of Verdaccio, which would give me the same pub­lish­ing and in­stal­la­tion flow as npm, but with­out the hefty monthly fees.

Verdaccio also acts as a proxy to for pack­ages not avail­able on our self-hosted reg­istry. It has ex­per­i­men­tal sup­port for npm to­kens, which had to be en­abled for pro­gram­matic node mod­ules in­stal­la­tion. Docker re­quired ad­di­tional con­fig­u­ra­tion to play well, but it was worth the ef­fort.

Collaboration with the FOSS Community.

Even though the pro­ject is in its in­fancy, I've al­ready worked with sev­eral peo­ple and it has been a very in­ter­est­ing and val­i­dat­ing ex­pe­ri­ence.


When start­ing out with the pro­ject, one of the first things I did was toot for a pro­ject men­tor. I was go­ing to go in un­known wa­ters and if there’s one thing I’ve learned, it helps to have some­one to bounce ideas from and ask ques­tions about things they un­der­stand bet­ter. Tyler Childs vol­un­teered and has been a great help not just from a tech­ni­cal point of view, but also from a more philo­soph­i­cal per­spec­tive. Most re­cently, he had asked me, “Do you think the rea­son you don’t feel like re­turn­ing to the pro­ject is that you’re fa­tigued by TypeScript?” That was a light-bulb mo­ment. In fact, we have found our­selves talk­ing about com­pa­nies we’d like to work for or even the state of the world; we even found out we have the ex­act same lap­top!


I also sent out a re­quest for a logo and if some­one would be will­ing to vol­un­teer with full at­tri­bu­tion to their work on the GitHub pro­ject as well as the ac­tual site. Andy stepped up and through the course of over a month, we fi­nally set­tled on the cur­rent logo. It’s so cre­ative and I love it - couldn’t have asked for a bet­ter one!


That’s not it, ei­ther. When I reached out for help on an ac­ces­si­bil­ity is­sue around a smart in­put field for cat­e­gories, Mehdi M. vol­un­teered and we had a con­ver­sa­tion around the is­sue on a GitHub gist. I am im­pressed with how he went above and be­yond in help­ing me with my is­sue.

While all the sug­ges­tions have not yet made it into Celestial, it's on the roadmap for v1.0.