Author: vishnugopal

The Why

There are several reasons to pick a full-stack JavaScript dev environment in 2019. First off, JavaScript is ubiquitous, it’s got pretty much all the big names in web software aligned behind it: Facebook, Google & Microsoft all have investments in both server and client-side JavaScript frameworks. Who would have thought that we would live in a world where we’ll write code in an editor built by Microsoft, in a framework developed by Facebook, and using design systems inspired by Google. Frankly, it truly is the golden age of client-side web development.

The story on the server-side for JavaScript doesn’t look that rosy, but NodeJS has come a long, long way from its initial demo, and for most web applications that serve an API backend, it’s a solid choice, especially combined with web frameworks such as Express.

And on both ends, JavaScript in general has evolved a lot as a language with first-class support for classes, async/await, spread operators, and string literals. In fact, even coming from a developer-friendly language like Ruby, JavaScript feels nice now, not like five years ago. And some features (like type hinting and automatic formatting) enabled by projects like Babel and Prettier make editing JavaScript code feel like living in the future. In fact, if you haven’t edited JavaScript in VSCode before, do try it out.

The Choices

Well, you’re convinced and ready to jump into full-stack JavaScript. How do you do it? If you come from the Ruby/Rails world like I do, you’re in for a rude shock. Rails picks a lot of default choices for you: there is an emphasis on convention over configuration, and all its moving parts are designed (& tested) to work well together. JavaScript is… not like that. It has a ton of developers actively working on several libraries every day, leading to good examples of what not to do when including dependencies.

So in fact the first step in building full-stack JavaScript is deciding what goes into the stack. At Lucideus, for a new product called Safe Assure, here’s how we made those technology decisions. Each product and technology chosen ideally has to be:

• mature technology (developed for at least 2 years), as part of the principle to use boring technology.
• actively maintained, and have updates within the last month, and a history of frequent updates without the developers taking off on long vacations.
• ideally sponsored by a large organisation that won’t die tomorrow (Google & the like preferred, but Airbnb, Palantir et. al. are acceptable), and,
• have developer mindshare, as measured by a healthy number of stars on Github.

Based on these criteria, here’s what we chose for the frontend:

• Web Framework: React
• CSS Library for Layout & from-scratch styling: Tailwind
• CSS Component Library: Blueprint
• Styling components with a theme: styled-components
• CSS Optimisation: PostCSS, PurgeCSS, and cssnano.
• Integration Testing: testcafe.

& for the backend web framework, we chose to build a simple Express API endpoint. There are of course a lot of default choices (in so much as the community as accepted them as the de-facto default) that come with choosing to build a JavaScript SPA that require configuration as well, amongst them:

• Webpack (which is used to bundle & minify JavaScript, CSS, and images)
• & how to deploy this application, for which we chose to build a Docker image that combines the server & client parts of the app, for eventual deployment to a managed Docker cluster.

Note: in future versions, we might explore building an auto-generated and configured GraphQL backend instead of the Express app, probably using Hasura’s excellent frontend for Postgres, but that’s a post for another day.

The Application Structure

Let’s start with a sane application structure. We’re essentially building two apps: a frontend SPA client app, and a backend API that the client consumes to display data from a database. So let’s make:

• src/
  • client/
  • server/

We also need tests, so a folder for that. Note: we prefer integration tests, so these are independent of the client and server, and indeed will only work if both components are present and running:

• src/
  • client/
  • server/
• test/

Eventually when we deploy the app for distribution, we also need a dist/ folder, so let’s create that too:

• src/
  • client/
  • server/
• test/
• dist/

Inside the client/ folder, we start with a simple SPA application:

• client/
  • images/
  • components/
    • All React components of our SPA
    • App.js
      • The main App/ component.
  • index.html
    • The HTML entry-point of the client-side app, this is what webpack injects assets into & loads in the browser.
  • index.js
    • The JavaScript entry-point of the client-side app.
  • styles.css
    • Generic styles and imports that remain outside of components. This is usually used only for @imports & special things like @tailwind directives.

Note: as our app expands, we might logically create more folders, for e.g. sub-components inside the components/ folder by business theme or any other organisational unit we might choose.

The server folder uses the folder structure generated by the excellent express-generator. Note: we choose to configure it with the EJS view template (i.e. express -v ejs) . It looks like this:

• server/
  • bin/www
    • The JavaScript entry point of the server application. Makes sure the ports configured are available and loads the app.
  • public/
    • fonts/
    • images/
    • Both these folders will be empty when developing, but we’ll use this in the deployment step to link the client and server applications correctly.
  • routes/
    • api/
      • <endpoint>.js
      • This is the /api/* endpoints that you would configure. Each file would be a separate route.
    • index.js
      • This is the default route that will just serve views/index.ejs. We’ll use this during the deployment step.
  • views/
    • error.ejs
      • Used when there is a 40*, 50* error in the application.
    • index.ejs
      • Copied in by the deployment process to load the client-side SPA.
  • app.js
    • This is called by boot/www during the startup process and sets up the main Express app. You also configure the API routes here.

That’s it for now! In Part 2 of this article, we’ll look at configuring Webpack correctly to minify & remove un-used CSS, and process images and fonts.

14 years ago, I had simple ambitions to make a website for amateur writing. Then life got in the way until it didn’t, and Koal was reborn. Why I’m making Koal is intensely personal: reading is a big part of my life and a lot of what I’ve read—and some of the best bits—have been from amateur authors who are either nameless or forgotten.

Every year I notice sites that host these stories either disappearing, turning uglier, harder to access, or hiding these gems behind a paywall. It’s important to me that this trend be reversed, that there exists a free site, unencumbered with ads, where these authors can be read in peace. A place that is distraction-free, and hopefully even beautiful.

This is entirely a one-person effort, and this is a log of my work to date:

• Because I’ve turned a bit rusty with server-side programming in Rails, I decided to use the latest Rails as a backend and then plugged away at it until I got comfortable enough to use Rails as a server-side HTML framework, and StimulusJS (when needed) to sprinkle JavaScript interactivity.
• I’ve been using Product Hunt Makers as a build log, and it’s been working great. Getting high-fives and comments from other makers is great!
• After I got the basic scaffold working, I decided to write importers for the most common story sites. Right now I have SOL & Fel converters working. Next importer to be built is a Fanfiction/Fictionpress importer.
• Once I got the site live by using a bare basic design layout, I decided to spend some time improving the UI design of the site. It’s taking quite a bit of time to relearn some UI design fundamentals, get up to basic with modern CSS & Tailwind, and then get familiar with Sketch so that I can translate what I see inside my head to a page.

This is where I’ve reached as of now: having sketch design files that need to be converted to HTML.

First up, the home page:

Now, the story page:

This is much simpler, and I’d like to do more work to make the typography shine here.

I’m reasonably happy with what I have now. So immediate next steps:

• Convert this to HTML.
• Play around with the Pexel API to get great live covers.
• Get this design live!

& after that:

• Write an importer for Ficsave’s Fanfiction/Fictionpress EPUB export, and import some more great stories into Koal.
• And write an EPUB export tool to get clean EPUB versions of all these stories.

 

I’ve been to a few music festivals in India & out, and Ziro definitely takes the crown as the most memorable. Just reaching Ziro itself is an adventure: flight to Guwahati, overnight train to Naharlagun (about 15km from Itanagar), and then a six hour taxi ride to Ziro through abysmal & at times non-existent roads. Because of these roads, taxis have a tendency to break down often, increasing travel times further.

We had booked a camp around a kilometre and half away from the main stage, and the camp was managed excellently: it had clean running water all the time, bathrooms weren’t full of shit even at the end of day 4 (a rarity in the world of porta-potty installations), and the food was great, even if the camp organisers were a bit stingy in doling out portions.

 

The short walk to the venue was never too tiring, even on the way back after a long day of standing around, and there were several restaurants on the way with excellent local food.

The venue itself had two stages, a “sun stage”, that played from noon to dusk, for slower music genres like blues and jazz, classical instrumentals and vocals. The “moon stage”, from dusk until 11PM was for the harder music to dance to: alternative, rock, rap, and electronic. Just the breadth of the program was something that I didn’t expect going in to the festival (most bands in the lineup I had never heard of before). It was great to listen to all kinds of genres for somebody like me who is not particularly into music.

The quality of the sound-stage was excellent. Even though it was an open air concert, I loved the sound quality. Except for one day when the main speakers on the sun stage gave out, everything was perfect.

And the bands were great. There were a bunch from the North East, but a lot more from all across India, and even a few foreign bands from Japan, the US and Europe. Not a bad showing at all. Here are a few I liked enough to jot down. The ones starred are the ones I really loved:

• Oorka
• 👏 Nubiah Garcia
• Mono
• 👏 Ditty
• Small Talk
• 👏 Sukanya Ramagopal
• Search & Found
• 👏 Ambushed
• Cryptography 3.0
• Malok
• 👏 Colored Keys
• Mathias Durano
• Adi Mandal
• Sam Paa

As might be obvious, my music tastes lean heavily to the slower kind of music, but I did enjoy the rap and some electronic sessions.

This is the second trip in a row that I haven’t taken my Leica on (this time because of fear of rains), and this one really suffered for it. I would’ve loved to photograph the great yellow rolling fields with a better lens, and there were certain shots that were just begging for a good RAW edit. Next time!

The North East definitely deserves a deeper look. This was my first trip to the region, and hopefully will not be the last!

Last month, I took off on a short trip to Mahe with some friends. Here is one sweet video I took from the trip:

& my favourite photo:

Even though I took the Leica on the trip, I took most photos with my iPhone X and a borrowed DJI Osmo (a fancy gimbal), and the photos didn’t turn out to be too bad at all.

There’s a great trifecta that make Mahe an appealing drinking destination in Kerala: great & unspoilt beaches (North Kerala has lots of em), cheap alcohol (Mahe, even though completely surrounded by Kerala is a union territory and part of Pondichery), and great non-vegetarian food (because of the Muslim population). Unfortunately, I was on a detox regimen when I visited, so couldn’t enjoy this part of the tour much.

I also went and visited parts of North Kerala that were near, including Thalassery which again has excellent food, and Muzhipilangad, which is the only drive-in beach in Kerala. It’s a fantastic beach even if you don’t bring in a vehicle, as I almost waded a half kilometre off shore before encountering crazy depths.

 

The blockchain and its various implementations are a wonderful example of technology changing the world. By using a distributed ledger that rewards more people maintaining a true copy, a viable replacement to fiat currencies is now possible.

When I first heard about blockchains, I thought it must use some esoteric technology. This view was easily reinforced by how frequently academic terms like “white paper” and “proof of work” are referenced in the blockchain world. When I started digging deeper into the bitcoin stack however, I found that most of the concepts used were very simple. In fact, I now think that Satoshi was a genius not in that he advanced the state of the art in computer science, but as befits a great engineer, he combined several widely disparate but simple concepts in the computer science & engineering world to create something truly unique & compelling.

What are these concepts? I’ll try to list down 10.

1. Public-Private Key Cryptography: for blockchain identify & signing.
2. Peer to Peer & Multicast: Easily find and talk to other nodes. First pioneered by P2P file sharing way back!
3. Unspent Transaction Output (UTXO) [more detail]: for simplified ledgers.
4. Merkle Trees: for efficient storage & verification of transactions.
5. Proof of Work Mining: Algorithmic Problem Solving as a reward mechanism.
6. Block Creation [more detail]: Use previous block hash + transactions to create block.
7. Building a Blockchain: Distributed order creation to avoid double spends.
8. Blockchain Forks & Resolution: Longest chain wins.
9. Difficulty Adjustment [more detail]: to increase difficulty with mining power, and ensure that blocks are generated in uniform time.
10. Independent Transaction Validation: Every node independently verifies transactions before storing in pool. There is no trusted actor!

So there you go! 10 concepts that you have to grok, and then combine to form the foundations of blockchain-based payment networks like Bitcoin. This should easily be a good weekend read 🙂