DEV Community: calvintwr

The true prototypial nature beneath "JavaScript classes"

calvintwr — Sun, 26 Jul 2020 11:18:46 +0000

I first wrote this stackoverflow answer in 2015. Obviously things has changed quite a bit, but still think there are much misdirections in JavaScript to address.

This article, as its title would suggest, will be contentious. But please, I am not about to say that we shouldn't use class and new. But to make that little dent, catch your attention, and hopefully we can all have some discussions over it.

Mainly is to explore, through a simple syntax, that Javascript is inherently classless, and its powerful prototypial nature obscured by class and new.

But, on balance, you have much to gain, and nothing to lose using ES6 classes (provided one writes it readably).

The point at the end of the day, please think of readability. The closer a language looks like to a human language, the better.

World without the "new" keyword.

And simpler "prose-like" syntax with Object.create().

First off, and factually, Javascript is a prototypal language, not class-based. The class keyword is in fact is just prototypial under the hood. Indulge me, and have a look at its true nature expressed in the simple prototypial form below, which you may come to see that is very simple, prose-like, yet powerful. I also will not use the prototype property, because I also find it rather unnecessary and complicated.

TLDR;

const Person = { 
    firstName: 'Anonymous',
    lastName: 'Anonymous',
    type: 'human',
    name() { return `${this.firstName} ${this.lastName}`},
    greet() { 
        console.log(`Hi, I am ${this.name()}.`)
    } 
}

const jack = Object.create(Person) // jack is a person
jack.firstName = 'Jack'            // and has a name 'Jack'
jack.greet()                       // outputs "Hi, I am Jack Anonymous."

This absolves the sometimes convoluted constructor pattern. A new object inherits from the old one, but is able to have its own properties. If we attempt to obtain a member from the new object (#greet()) which the new object jack lacks, the old object Person will supply the member.

In Douglas Crockford's words: "Objects inherit from objects. What could be more object-oriented than that?"

You don't need constructors, no new instantiation (read why you shouldn't use new), no super, no self-made __construct, no prototype assignments. You simply create Objects and then extend or morph them.

This pattern also offers immutability (partial or full), and getters/setters.

TypeScript Equivalent

The TypeScript equivalent requires declaration of an interface:

interface Person { 
    firstName:  string,
    lastName: string,
    name: Function,
    greet: Function
}

const Person = { 
    firstName: 'Anonymous',
    lastName: 'Anonymous',
    name(): string { return `${this.firstName} ${this.lastName}`},
    greet(): void { 
        console.log(`Hi, I am ${this.name()}.`)
    } 
} 
const jack: Person = Object.create(Person)

Creating an descendant/copy of `Person`

Note: The correct terms are prototypes, and their descendants/copies. There are no classes, and no need for instances.

const Skywalker    = Object.create(Person)
Skywalker.lastName = 'Skywalker'

const anakin       = Object.create(Skywalker)
anakin.firstName   = 'Anakin'
anakin.gender      = 'male' // you can attach new properties.

anakin.greet() // 'Hi, my name is Anakin Skywalker.'

Let's look at the prototype chain:

/* Person --> Skywalker --> anakin */
Person.isPrototypeOf(Skywalker) // outputs true
Person.isPrototypeOf(anakin)    // outputs true
Skywalker.isPrototypeOf(anakin) // outputs true

If you feel less safe throwing away the constructors in-lieu of direct assignments, fair point. One common way is to attach a #create method which you are read more about below.

Branching the `Person` prototype to `Robot`

Say when we want to branch and morph:

// create a `Robot` prototype by extending the `Person` prototype
const Robot = Object.create(Person)
Robot.type  = 'robot'
Robot.machineGreet = function() { console.log(10101) }

// `Robot` doesn't affect `Person` prototype and its descendants
anakin.machineGreet() // error

And the prototype chain looks like:

/*
Person ----> Skywalker --> anakin
        |
        |--> Robot
*/
Person.isPrototypeOf(Robot) // outputs true
Robot.isPrototypeOf(Skywalker) // outputs false

...And Mixins -- Because.. is Darth Vader a human or robot?

const darthVader = Object.create(anakin)

// for brevity, skipped property assignments 
// you get the point by now.

Object.assign(darthVader, Robot)

// gets both #Person.greet and #Robot.machineGreet
darthVader.greet() // "Hi, my name is Darth Vader..."
darthVader.machineGreet() // 10101

Along with other odd things:

console.log(darthVader.type)     // outputs "robot".
Robot.isPrototypeOf(darthVader)  // returns false.
Person.isPrototypeOf(darthVader) // returns true.

Which elegantly reflects the "real-life" subjectivity:

"He's more machine now than man, twisted and evil." - Obi-Wan Kenobi

"I know there is good in you." - Luke Skywalker

In TypeScript you would also need to extend the Person interface:

interface Robot extends Person {
    machineGreet: Function
}

Conclusion

I have no qualms with people thinking that class and new are good for Javascript because it makes the language familiar and also provides good features. I use those myself. The issue I have is with people extending on the aforementioned basis, to conclude that class and new is just a semantics issue. It just isn't.

It also gives rise to tendencies to write the simple language of Javascript into classical styles that can be convoluted. Instead, perhaps we should embrace:

class and new are great syntactic sugar to make the language easier to understand for programmers with class languages background, and perhaps allows a structure for translating other other languages to Javascript.
But under the hood, Javascript is prototypial.
And after we have gotten our head around Javascript, to explore it's prototypial and more powerful nature.

Perhaps in parallel, it should allow for a proto and create keyword that works the same with all the ES6 classes good stuff to absolve the misdirection.

Finally, whichever it is, I hoped to express through this article that the simple and prose-like syntax has been there all along, and it had all the features we needed. But it never caught on. ES6 classes are in general a great addition, less my qualm with it being "misleading". Other than that, whatever syntax you wish to use, please consider readability.

On `#Object.defineProperty`

For free getters and setters, or extra configuration, you can use Object.create()'s second argument a.k.a propertiesObject. It is also available in #Object.defineProperty, and #Object.defineProperties.

To illustrate its usefulness, suppose we want all Robot to be strictly made of metal (via writable: false), and standardise powerConsumption values (via getters and setters).

const Robot = Object.create(Person, {
    // define your property attributes
    madeOf: { 
        value: "metal",
        writable: false,
        configurable: false,
        enumerable: true
    },
    // getters and setters
    powerConsumption: {
        get() { return this._powerConsumption },
        set(value) { 
            if (value.indexOf('MWh')) {
                this._powerConsumption = value.replace('M', ',000k')
                return 
            }
            this._powerConsumption = value
            throw Error('Power consumption format not recognised.')
        }  
    }
})

const newRobot = Object.create(Robot)
newRobot.powerConsumption = '5MWh'
console.log(newRobot.powerConsumption) // outputs 5,000kWh

And all prototypes of Robot cannot be madeOf something else:

const polymerRobot = Object.create(Robot)
polymerRobot.madeOf = 'polymer'
console.log(polymerRobot.madeOf) // outputs 'metal'

4 "Bang For the Buck" Practices For Express API

calvintwr — Sun, 19 Jul 2020 11:26:32 +0000

I will point out 4 basic but common issues I faced over years of working on Express, and how simply following some best practices can produce "bang for the buck" results. I use my own library to solve the problems, but you can prefer your way to address the concepts.

1. Dealing with numbers - Check for EXACTLY what you are expecting

For example:

router.get('/user/:id', (req, res) => {
    let id = parseInt(req.params.id)
    // some code to retrieve a user.
})

The problem here is with #parseInt used wrongly, or interchangeably with #Number. Using #parseInt often accepts inaccuracy and causes problems.

Not ok to accept inaccuracy

The code may look fine at first, because id is almost universally an integer. But #parseInt can inaccurately transform wrong information into something usable.
To illustrate, say someone intends to access the route user/1/photos but accidentally left out a slash:

GET /user/1photos

Familiar error isn't it? This results in #parseInt falsely evaluating the inputs to something usable but misleading:

parseInt('1photos') // gives 1

The code is misled to continue downstream, thinking that you want user #1's information, providing a response with status 200, tripping developers to wonder why the response did not have any photo data.

Using #Number, and being accurate

The right way is to use #Number, which will produce NaN:

router.get('/user/:id', (req, res) => {
    let id = Number(req.params.id)
    if (isNaN(id)) return res.status(400).send('Error')
    if (!Number.isInteger(id)) return res.status(400).send('Error')
    // some code to retrieve a user.
})

Now, you will see that we corrected code to use #Number, and we also have some checking going on ensure it's an integer. But what trips programmers here is that they often forget to complete a full check, or compromise doing so.

Discipline in this aspect is often difficult to instil. And since most of the time the yardstick is that the code works and passes tests, it seemed OCD to be quibbling over cases of others’ carelessness. Or perhaps also it’s not worth the effort to write the code to help other people realise their mistake faster.

Either way, I was left with no choice but to write my own library. Not does away with all these problems.

import Not from 'you-are-not'
const not = Not.create({ willThrowError: false})

router.get('/user/:id', (req, res) => {
    let error = not('integer', req.params.id)
    if (error) return res.status(400).send(error)

    // some code to retrieve a user.
})

2. Provide actionable error messages

Going back to the misfortunate example of missing slashes:

GET /user/1photos

Since we are already returning a status 400 to say that the inputs are wrong, we should also say what's wrong.

This is not easily done because you need to manually write some messages, or developers -- who are almost always -- on tight schedule will be skimpy on error handling/messaging. Again, no amount of discipline will solve this problem. The solution is just to have a library that comprehensively handles type checking/validation, error handling, and error messaging.

Referring to the previous example, we expand the code to use some features of Not to help us out:


// GET /user/1photos

import { format } from 'utils'

router.get('/user/:id', (req, res) => {
    let error = not(
        'integer', 
        Number(req.params.id), 
        'id', 
        `received ${format(req.params.id)}`
    )
    if (error) return res.status(400).send(error)

    // some code to retrieve a user.
})

Not produces a string, this string assigned to error holds the message:

Wrong Type: Expect type `custom:integer` but got `nan`. Note: received "1photos".

Now that clearly tells the API user that there are missing slashes for "1/photos" because the payload is "1photos". This is what I mean by having a very actionable error message to help out the API requestor.

3. Add a timestamp to error messages

This is perhaps the single most "bang for the buck" thing to do that can quickly squash all your bugs. To illustrate: User gets an error, provides the timestamp, you search your logs to locate the error, and the problem gets fixed. Simple, fast, and productive.

The Not way of doing this is automatically taken cared of. Suppose you need to add an array:

let not = Not.create({ 
    willThrowError: false,
    timestamp: true // switch on timestamp
})
router.put('/array', (req, res) => {

    let error = not(
        'array', 
        req.body.array)
    )

    if (error) {
        console.error(error)
        return res.status(400).send(error)
    }

    // some code to add the array.
})

So suppose someone erroneously post a string with commas (a very very common error):

let payload = "item 1, item 2"
post('/array', payload)

This will produce an error message to the user, as well as in your logs:

Wrong Type: Expect type `array` but got `string`: "item 1, item 2". (TS: XXXXXX)

You can then search your logs and quickly identify the problem (if the user somehow still cannot figure it out with the error message provided).

4. Always sanitise the payload

I cannot emphasise enough the importance of sanitising request payloads. This means regardless of what was sent to your API, your API should always filter out all other information that it is not intended to receive.

Accessing hidden information

I once had a client who wanted to keep deregistered user data in the database. Never mind data security regulations and all, the method was to use a field hidden, which is set to true to "delete" the records.

To illustrate the vulnerability, the simplified request payload and route syntax is like this:

User sends in a request like this:

{
    gender: 'male',
    location: 'Singapore'
}

User information lookup is like this:

router.get('/users', (req, res) => {

    let options = {
        hidden: false
        // and a lot more options
    }

    Object.assign(options, req.body)

    DB.find(options).then(results => { res.send(results) })
})

Again things look fine, except not sanitising payloads can easily open up a security vulnerability for the requestor to get "deleted" users:

{
    gender: 'male',
    location: 'Singapore',
    hidden: true
}

#Object.assign will overwrite the default option of hidden: false to hidden: true, allowing requestor to gain unauthorised access to "deleted" users. You may point out a quick fix, which is to flip the object assignment:

Object.assign(req.body, options)

But that's not the point. One way or another, security vulnerabilities are bound to surface if no sanitisation is done. And it is a pain with custom code. So Not does it like this, on top of all the error messaging functionality it provides:

router.get('/users', (req, res) => {

    // define a schema
    let schema = {
        "gender?": 'string', // you can define your own validation, but we keep it simple as string
        "location?": 'string' // "?" denotes optional
    }

    // payload will only contain what is in the schema
    // so `hidden: true` will be removed
    let payload = Not.checkObject(
        'request', 
        schema, 
        req.body, //payload
        { returnPayload: true }
    )


    // at this point, payload will become an array if there are errors
   // you may simply send the actionable errors back to the requestor
   if (Array.isArray(payload)) return res.status(400).send(payload)

    // otherwise it is an object, ready to be used:

    let options = {
        hidden: false
        // and a lot more options
    }

    Object.assign(payload, options)

    DB.find(options).then(results => { res.send(results) })
})

And there you have it, type checking, validation and sanitisation all nicely settled.

Conclusion

So building an API is really not that simple. Not only that we need it to work, but also to let everyone figure out what's wrong when something breaks. Moreover, we are most likely to create errors more than be successful, so error messaging is really important to quicken up the development process. A small library that can allow neat validation/checking code will also aid that process of (1) vastly improve code maintainability, and (2) reducing the barrier to do error handling/messaging.

I hope my thoughts can contribute to better codes. Let me know what your comments are!

About Not.JS

If you like what you see, do drop me a star here.

Database "Stuff" I Wished I Knew About For NodeJS - Part 2- Postgres

calvintwr — Sun, 12 Jul 2020 09:45:47 +0000

So now that we have covered the use-cases for MongoDB and Postgres in Part 1, let's talk about how to use Postgres with NodeJS.

First off, you don't need to know SQL to use anything SQL, like PostgreSQL. I have written less SQL in my life than I have written poems to my wife. And I am not romantic.

Also I promise this is not one of those "10/20/30 best modules" articles, which looked like a lot of copy, and paste, and paraphrasing, and even still recommending modules deprecated in 2019 as one of the best in 2020.

This here, is my many years of experience, scribed.

Why Postgres?

Postgres has been around for a very long time since its inception in 1996, developed at the University of California, Berkeley. It was commonly seen as "more advanced" than MySQL. On the other hand, MySQL focused on simplicity but compromised performance. It caught on with the mainstream. It didn't mattered back in those days of of pre-2000, data didn't scale at the rate that it is now.

Postgres is anything but ancient, because it is constantly being updated. In fact it is so powerful and reliable, very big corporations like banks uses it for its consistency and speed. And the benefits are immense:

Very mature, time tested and proven.
Very constantly updated.
Which also means it always gets new features.
Very fast.

Apples are red and oranges are orange.

I won't go into the details of what makes Postgres faster than MongoDB, as there are many articles out there on this.

In general, where data is relational, Postgres is almost always faster than MongoDB -- which makes it most of the time true because most data are relational. For non-relational data, even though Postgres also support schema-less storage with JSON fields, this is where MongoDB wins hands down.

Suffice to say, I have read many of these articles/researches, and concluded that you just have to use the right database for the right purpose -- apples are apples and cannot be compared to oranges. People who say that Postgres is also great for NoSQL with JSON fields, are as baseless as those who say MongoDB are great for relational data.

The worst reason to use MongDB

So you can write JavaScipt, but Structured Query Language (SQL) looks completely alien. This is not the reason to choose MongoDB.

Whatever SQL database you use, you don't have to write any SQL, period.

To do away with writing clunky SQL, there are JavaScript query builders and ORMs to access SQL databases using modern and simple Javascript syntax, much like MongoDB's syntax (not convinced? browse through my tutorial to build instagram, you will not see any SQL).

Query-builders and ORM

So what are query builders and Object Relational Mapper?

Query Builders - Knex

Query builders allows you to use Javascript syntax to write your queries. The best one out there is Knex:

knex('users').where({
  first_name: 'Test',
  last_name:  'User'
}).select('id')

Which is essentially in SQL like this:

select `id` from `users` where `first_name` = 'Test' and `last_name` = 'User'

And if you are a speed demon, you can choose to write raw SQLs. But with such thin overheads that Knex has, it makes perfect sense to use Knex to drastically improved readability.

In limited cases, raw SQLs makes sense where libraries have not kept up with new high-level SQL features, or included those that are seldom used. If not, for most cases, debugging a tower of SQL codes doesn't differentiate well with other tortious activities such as burning in hell or watching Cats.

ORM

ORM is essentially one abstraction-level above query builders. It allows you to define your database schema, and unlocks are more intuitive syntax. Using an ORM, one doesn't need to think in traditional terms of tables, rows and columns. It would be more intuitive, in terms of relationships between entities. Hold this thought, which you will understand through reading the syntax of ORMs.

1. SequelizeJS

This is by far the most complete ORM. It uses a await/async/defer/promise-styled syntax that is very readable and maintainable.

I personally prefer the promise-styled syntax (but if you check out their v6 documentation, they have transited to async/await style):


// User table
const User = sequelize.define('User', {
  firstName: { type: DataTypes.STRING },
  lastName: { type: DataTypes.STRING }
})

// Post table
const Post = sequelize.define('Post', {
  title: { type: DataTypes.STRING },
  caption: { type: DataTypes.STRING }
})

// association
User.hasMany(Post)
Post.belongsTo(User)

// query
User.find({ 
    where: { firstName: 'John' },
    include: { model: Post }
}).then(user => {
    // `user` will contain information about John, and all his posts.

    // send data back to requestor
})

Notice how, like I mentioned, you think of data in terms of entities like User and Post, and not in tables, columns and rows.

All the features you need, like transactions

I have used Sequelize extensively, and it really has all the features and customisations that any applications will need. For advanced users, check out how transactions are easily implemented, say when you need to create a user at the same time with a new post:

sequelize.transaction((t) => {

    return User.create({
        firstName: 'Abraham',
        lastName: 'Lincoln'
    }, { transaction: t }).then(user => {

        user.addPost({
           title: 'My first post',
           caption: 'I just joined!'
        }, { transaction: t })

    })

}).catch(error => {
    // handle the error
})

So if something downstream, like the creation of a Post has errors, the creation of User will be rolled back. This is a critical feature, such as for building a bank application: if you run a query to update multiple bank account balances, failure to update any account balance should roll back all the updates, else you will end up with missing money.

Documentation

SequelizeJS has an extensive documentation, but can be difficult to understand sometimes. This is where its customisability does itself in -- there are just too many use-cases to cover. This is addressed partially by using its own Command Line Interface, which generates default codes for connecting to databases, and defining models. And then for more advanced usage, the better way I find is to look for github examples or stackoverflow answers.

Protip: Or like one of the main maintainers Mick Hanson likes to tell me, to read the tests. I have grown to find that this is a very useful way of figuring out the syntax not just for sequelize, but for all other modules.

Common complains about ORM - slow

Yes, feature-rich one like Sequelize adds a lot of overheads and can become very slow. But because it is very customisable; you can switch off some of it features, or even use raw queries for speed.

Augment ORM with query builders

Also, this is where Knex comes in if you do not want to use raw SQL, even though most ORMs will allow raw queries with very thin overheads. But then again, I already addressed the point about raw SQLs and burning in hell.

2. Bookshelf

Bookshelf is based on Knex, and came on as an early competitor to SequelizeJS. It values speed and simplicity, but compromises on features. It also supports major features like eager loading (just means loading a model with its associated models) and transactions. But in general, I don't find any real reasons to use Bookshelf over Sequelize.

3. TypeORM

(Note: @philschonholzer commented that TypeORM development appears to have stalled. It looks like a potential TypeScript replacement could be Mikro ORM. Having only browsed through the documentation, I think it’s okay but similarly not as mature as Sequelize.)

TypeORM is much newer than Sequelize and hence naturally has a more modern internal syntax (which really isn't something you need to bother). Also, as its name suggest, it is written in TypeScript, which attracted many collaborators from the TypeScript bandwagon.

Code Reliability

I am tempted to say that TypeScript codebases should usually be more reliable. But for TypeORM, at time of this writing it has less than half the amount of dependents compared to SequelizeJS (based on npmjs, TypeORM has 1.5k dependents, and SequelizeJS has 3.7k). But in terms of issues, TypeORM has more than double that of Sequelize (1.8k vs 800). However, suffice to say, both libraries are very heavily assailed by tests and are reliable enough.

Also, if you are developing TypeScript, then TypeORM is a viable piece so that you won't have a JS module disturbing "homogeneity", albeit I find this hardly a reason.

Some say, if you use TypeScript, choose TypeORM

You may have come across this reason if you read comments and articles online. I just don't think there is much logic in this reasoning.

Logically, beyond what is already abstracted away, you would still write TS normally when querying the models. Yes, you are missing out on some autocompletes. But for an ORM it hardly matters, and this is exactly my practical experience. Plus TypeScript can sometimes be quite inflexible and an overkill.

It is also more clunky to define models in TypeORM, which doesn't look very readable, and makes Javascript look like C#/Java:

import {Entity, PrimaryGeneratedColumn, Column} from "typeorm";

@Entity()
export class User {

    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    firstName: string;

    @Column()
    lastName: string;

}

Features and Documentation

Also, being newer, it has less features compared to Sequelize, and will take time to catch up. Likewise, its documentation also needs a lot more work. Nonetheless, the protip mentioned earlier remains true, which is you can always read the tests to get hints of how to use certain features.

Overall I think TypeORM can be selected over Sequelize given it has potential to improve over time. But to be sure, I will advise that you study their documentations before deciding if you can survive without some features that Sequelize has, but missing from TypeORM.

4. ObjectionJS

ObjectionJS is quite a stellar effort to simplify the syntax, where it could have been slightly more complicated in Sequelize or TypeORM. However, it is much, much leaner in terms of features, and provided no real advantages over Sequelize or TypeORM, except perhaps some performance gains with much less overheads.

Conclusion

I think in terms of the value proposition for Postgres, it is clear that in my experience, it will be one major component of your database mix. The main point is to use a database, whether SQL or not, for the right purpose. And that please don't shun away from Postgres (or any relational database for that matter) because you cannot write SQL -- because there are query builders and ORMs. And in terms of comparing what is out there, Sequelize and TypeORM are very viable choices that will cover what you need to build a fast, maintainable and modern application.

Database "Stuff" I Wished I Knew About For NodeJS - Part 1- MongoDB

calvintwr — Sun, 12 Jul 2020 07:01:21 +0000

After a very long time working on NodeJS, and having tried several databases and modules and Object Relational Mappers (ORMs), I think sharing my views may help save many from jumping through or stumbling over a few hoops. Or prevent that wrong misinformed decision that will entrench you when your application grows too big.

No "one-size-fits-all"

First off, there's no "one-size-fits-all" when it comes to databases and modules/ORMs. You have many choices out there, MongoDB, MySQL, PostgreSQL ("Postgres" or "PG") and etc. My opinion on this is that what you will search and read are largely polarised. So, take them all with a pinch of salt.

In my five-part series to build Instagram, I also reiterated this point (very abruptly) and opined that PG is more suitable as the main database. Actually, that is said for the sake of brevity. In truth, data in a social app like Instagram can scale beyond what's best for PG to handle. But it is not whether which is better, but rather, what is for what.

In this article, I will just cover MongoDB (Part 1) and PostgreSQL (part 2). There's pretty much no reason to use MySQL, when you can use the much more powerful and faster PostgreSQL.

MongoDB, and its early days

To understand the hype (or mis-hype) about MongoDB, I needed to cover some history. This is not a post to flame or support MongoDB, I just want to list out its pros and cons.

There are many things to love about MongoDB.

It comes readily shipped and pre-configured with many Node modules out there.
Setting up is extremely simple.
It is built to scale, and supports many such features out-of-the-box. Believe me, the simplicity of set up here is amazing compared to other databases.
Very readable syntax, again, right out-of-the-box.

But

But the problem is that many articles or modules have you believe that it is the right choice for everything. In truth, it's use-cases are very limited.

In its early days, everyone is rushing to get into the bandwagon, and wants to look very modern. Almost every new piece of Node technology or boilerplate shipped with MongoDB.

This can be misleading. And many of these new toys ditched a lot of fundamental database features -- like Reaction Commerce.

Reaction Commerce uses MongoDB, so it must be good.

For a significant part of reactioncommerce's history, it actually can be running into serious data consistency issues, because it was lacking transactions (MongoDB only implemented transactions in v4.2, August 2019). Transaction is an important feature that is available in almost all relational databases. It ensures that updating data across several tables are completed in full, or rolled-backed totally if it some updates have failed, perhaps due to validation failure, data corruption, or temporary hardware failure. This is fundamental in many applications, ecommerce more so probably.

An article in 2017 by Brent Hoover (in the article it says he
"manages Reaction's community/client tea") said NoSQL database is perfect but wrote vaguely about how data in ecommerce is modelled best by NoSQL. Separately on Gitter, he responded to a query on how Reaction overcomes lack of transactions, saying that, "In a document database, this sort of referential integrity is not required because the entire object is stored in one record."

How can everything you need ever be only stored in a single document? Just how big will that single document be, and how much data replication you need to achieve this? There must have been some level of normalisation (breaking into smaller documents) at some point.

Consequently, I don't know how Reaction Commerce deals with such issues, but I can imagine, in your effort to extend new features, you have to give up some data consistency, or write your own transaction-equivalent syntax.

Fast car, with no airbags

Don't get me wrong. Reaction Commerce is a great framework. But my point is that it was a fast and sexy car that shipped with no airbags. And they didn't tell you it came without. If you asked, they'd say it's not required -- that's simply untrue; a compromise was made silently. So please don't be lured in by fast cars with no airbags.

However, if anyone knows of how this is dealt with in context of Reaction Commerce now, I would love to hear your thoughts in the comments section below.

So should I?

The way I see database, is not in whether to use this, or to use that. But rather, in a large application, you will best be using a few databases to optimise performance.

For small and simple apps

If your application is small, and for simplicity since a lot of Node modules ship with MongoDB, you can just go ahead.

However in my experience, every piece of app I have built almost always very quickly scale beyond being the kind of "small" initially imagined.

To augment as a datastore

This is really where MongoDB shines. You have to dissect your application data and see which part has a lot of data that may not have a fixed structure. While many relational databases such as PG also supports storing schemaless JSON data, querying it can be very clumsy, even with use of modules or ORMs.

So, I'll conclude on this point about dissecting data, by referring back to the example of building Instagram (tutorial I mentioned earlier) and how I would do it:

Relational data, use PG:

User
User's posts
Interactions (likes, comments, shares) between Users and Posts.

Non-relational data, use MongoDB:

User activities (logins, time on site, behavioural patterns)
Post performance and statistics (how many click-throughs, trending data)

In the next part of this article, which I will cover how to use PG on Node and the various options of query modules and ORMs out there.

Build Instagram Using TypeScript, Node, Express and Vue - Part 4

calvintwr — Wed, 10 Jun 2020 19:49:15 +0000

This is tutorial 4 of a 5-part tutorial, but each tutorial can be read in isolation to learn various aspects Node+Express+TypeScript+Vue API/Vue web app set up.

Looking to learn mobile/desktop apps? The skills and concepts here are fundamental and re-usable for mobile apps (NativeScript) or desktop apps (Electron). I may cover them as a follow-on.

Navigation to other parts (you are at part 4)

Setting up Node and Express API with TypeScript
Setting up VueJs with TypeScript
Setting up Postgres with Sequelize ORM
Basic Vue templating and interaction with API
Advanced Vue templating and image uploading to Express

In this part of the tutorial you will learn how VueJS can interact with your Node+Express+Sequelize backend.

If you have not, you can start building by cloning and checking out tutorial-part3 branch:

git clone https://github.com/calvintwr/basicgram.git
git checkout tutorial-part3

1. Get a Type-Checking/Validation and HTTP library

The first thing you want to get is a type-checking/validation library for runtime (TypeScript don't check at runtime).

The best practice to do this job is to get 2 zero-dependency libraries, Not and Validator.js:

npm install you-are-not --save
npm install validator --save

Not: This is a type-checking centric library (with comprehensible, customisable error messaging) that comprehensively cover code that will exposed to client inputs at runtime, or for code you don't intend to implement TS (which can be overkill sometimes).

Validator.js: This is "user-input" centric, and readily provides checking like isEmail methods. You need to use it in conjunction with Not because it doesn't type-checks.

So for example, you can type-check and validate client's email address like this:

import Not = require('you-are-not')
import Validator = require('validator')

Not.defineType({
    primitive: 'string',
    type: 'email',
    pass(string) {
        return Validator.isEmail(string)
    }
})
let not = Not.create()

var notEmail = 'notEmail'
var stillNotEmail = 10

not('email', notEmail) // fails
not('email', stillNotEmail) // fails
not('email', 'email@domain.com') // passes and is silent. carry on with execution.

For HTTP library, if you search around you will find that the popular ones lying around are request, axios, and superagent. request is deprecated now, and personally I like superagent's syntax better.

So we go for `superagent`:

npm install superagent --save
npm install @types/superagent --save-dev

We are now ready to start building pages.

2. Build a login component

We could have used some of OnsenUI's prebuilt components, but I just want to use this opportunity to introduce tailwindcss.

The idea is that a lot of times you will not get the components you want. So in Vue, you can build it fast with Tailwindcss.

Also, with Vue components, don't worry about in-line styling because components are reusable, and hence doesn't violate "dry" principle.

Create a "pages/login.vue" component:

<template>
    <div class="flex justify-center content-center items-center h-full w-full">
        <div class="max-w-xs">
            <h1 class="text-center text-xl p-3">Welcome to Basicgram</h1>
            <form class="bg-white shadow-md rounded px-8 pt-6 pb-8 mb-4">
                <div class="mb-4">
                    <label class="block text-gray-700 text-sm font-bold mb-2" for="username">
                        Username
                    </label>
                    <input
                        class="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
                        id="username" type="text" placeholder="Username">
                </div>
                <div class="mb-6">
                    <label class="block text-gray-700 text-sm font-bold mb-2" for="password">
                        Password
                    </label>
                    <input
                        class="shadow appearance-none border border-red-500 rounded w-full py-2 px-3 text-gray-700 mb-3 leading-tight focus:outline-none focus:shadow-outline"
                        id="password" type="password" placeholder="******************">
                    <p class="text-red-500 text-xs italic">Please choose a password.</p>
                </div>
                <div class="flex items-center justify-center">
                    <button
                        class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded focus:outline-none focus:shadow-outline"
                        type="button">
                        Sign In
                    </button>
                </div>
            </form>
        </div>
    </div>
</template>

<script lang="ts">
import Vue from 'vue'

export default {
    data() {
        return {}
    }
}
</script>

Although it looks like doing inline styling, you will notice the difference as you use it more. Also especially when you can use SASS (also prepackaged in my boilerplate) to apply class en-masse (you can check out this concise 15-min video on Tailwind).

Now, we will want to have this login component show up when user is not logged in. You need to do a couple of things to home.vue, from top to bottom:

Use <div v-if="condition"> and <div v-else> to trigger conditional view templating. Basically, it is used like this:

<div v-if="isLoggedIn">
   show our main app
</div>
<div v-else>
   show login page
</div>

Import login.vue as a component and register it with Vue under components object:

<!-- Step3: use it like this in template after registering -->
<login></login>

<script>
// Step 1: import the component
import login from './pages/login.vue'

export default {
    components: {
        login: login // Step 2: register it with Vue
    }
}
</script>

Add a isLoggedIn flag in Vue's data which we will use to toggle (in actual authentication set up, you will store such states in Vuex, but that's a tad complicated for now):

export default {
    data() {
        return {
            isLoggedIn: false
        }
    }
}

`home.vue` will look like this:

<template>
    <div class="w-full h-full">
        <div v-if="isLoggedIn">
            <v-ons-page>
                <v-ons-toolbar>
                    <div class="center">{{ title }}</div>
                </v-ons-toolbar>

                <v-ons-tabbar 
                    swipeable position="auto" 
                    :tabs="tabs" 
                    :visible="true" 
                    :index.sync="activeIndex"
                >
                </v-ons-tabbar>
            </v-ons-page>
        </div>
        <div class="w-full h-full" v-else>
            <login></login>
        </div>
    </div>
</template>

<script lang="ts">
import Vue from 'vue'
import homePage from './pages/homepage.vue'
import camera from './pages/camera.vue'
import profile from './pages/profile.vue'
import login from './pages/login.vue'

export default {
    components: {
        login
    },
    data() {
        return {
            isLoggedIn: false,
            activeIndex: 0,
            tabs: [
                {
                    icon: 'fa-home',
                    label: 'Home',
                    page: homePage,
                    key: "homePage"
                }, 
                {
                    icon: 'fa-camera',
                    label: 'Camera',
                    page: camera,
                    key: "camera"
                }, 
                {
                    icon: 'fa-user',
                    label: 'Profile',
                    page: profile,
                    key: "profile"
                }, 
            ]
        }
    },
    methods: {},
    computed: {
        title() {
            return this.tabs[this.activeIndex].label === 'Home' ? 'Basicgram' : this.tabs[this.activeIndex].label
        }
    }
}
</script>

Fire you your webpack dev server with npm run dev and you should see this:

P.S. I also added class="h-full" to the containing divs which allows the login component to be vertically centered.

So now that you have a login view, we move on to bindings and events to execution codes to do a login.

3. VueJS bindings and events

I'll introduce the 3 most important VueJS binding mechanism.

v-model: VueJS binds your DOM with the data structure via v-model (two-way binding).

v-bind: Declared on DOM properties for one-way binding, like v-bind:href or just :href as the short-form. This is a subset of v-model.

Events: v-on:click="yourMethod()" or shorthand @click="yourMethod()" declarations on the DOM will trigger functions defined in methods. VueJS provides for many other events such as page scrolling via v-on:scroll.

To illustrate:

A username input will use v-model (bound to userName), so that updating its value will update our data:

<!-- this here binds to data.userName ⬇️ -->
<input v-model="userName"> 
<script>
export default {
    data() {
        return {
            // this variable here binds to `v-model="userName" ⬆️ .
            userName: '' 
        }
    }
}

Next is that we need the button to submit login, and also disable itself when it is waiting for a response from the server. So we bind the button to false which we will toggle. We also bind it to @click event, to execute our login method:

<button
    :disabled="loginButtonDisabled"
    @click="login"
>
<script>
export default {
    data() {
        return {
            // a flag that the button's "disabled" attribute 
            // for "disabled" property, VueJS use boolean
            loginButtonDisabled: false
        }
    },
    methods: {
        login(event) {

            // disable the button
            this.loginButtonDisabled = true

            // perform some operations

            // a child component passes data back to parent
            // is by emitting an event
            return this.$emit('login-success', data)

            // enable it if login as failed
            this.loginButtonDisabled = false
        }
    }
}

Tip: When you write @click="login", Vue will pass the event object into your function. Otherwise, you can specify what you want to pass in, like @click="login('myOwnData')", and Vue will respect that.

And when we bring in the `superagent` and `you-are-not` modules into `login.vue`, it will look like this:

<!-- pages/login.vue -->

<template>
    <div class="flex justify-center content-center items-center h-full w-full">
        <div class="max-w-xs">
            <h1 class="text-center text-xl p-3">Welcome to Basicgram</h1>
            <form class="bg-white shadow-md rounded px-8 pt-6 pb-8 mb-4">
                <div class="mb-4">
                    <label class="block text-gray-700 text-sm font-bold mb-2" for="username">
                        Username
                    </label>
                    <input
                        class="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
                        id="username" type="text" placeholder="Username"
                        v-model="userName"
                    >
                </div>
                <div class="mb-6">
                    <label class="block text-gray-700 text-sm font-bold mb-2" for="password">
                        Password
                    </label>
                    <input
                        class="shadow appearance-none border border-red-500 rounded w-full py-2 px-3 text-gray-700 mb-3 leading-tight focus:outline-none focus:shadow-outline"
                        id="password" type="password" placeholder="******************">
                    <p class="text-red-500 text-xs italic">Please choose a password.</p>
                </div>
                <div class="flex items-center justify-center">
                    <button
                        class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded focus:outline-none focus:shadow-outline"
                        type="button"
                        :disabled="loginButtonDisabled"
                        @click="login"
                    >
                        Sign In
                    </button>
                </div>
            </form>
        </div>
    </div>
</template>

<script lang="ts">
import Vue from 'vue'
import * as superagent from 'superagent'
import Not = require('you-are-not')

// Some advanced usage of Not to define your own "types"
// Which is really useful because in a real wrong, '' is a string that makes people lose hair.
Not.defineType({
    primitive: 'string',
    type: 'valid-string',
    pass(string) {
        return string.length > 1
    }
})

const not = Not.create()

export default {
    data() {
        return {
            loginButtonDisabled: false,
            userName: ''
        }
    },
    methods: {
        login(event) {
            console.log(this.userName)

             // this will throw error and stop the operation
            not('valid-string', this.userName)

            // disable the button first and start
            this.loginButtonDisabled = true

            superagent
                .post('http://localhost:3000/users/add')
                .send({ name: this.userName })
                .end((err: Error, res: superagent.Response) => {

                    if (err) {
                        this.loginButtonDisabled = false
                        alert(err)
                        return
                    }

                    console.log(res)
                    this.$emit('login-success', res.body)

                })

        }
    }
}
</script>

In home.vue, you will need to receive and manage this event called login-success, like this:

<!-- home.vue -->

<template>
    <div class="h-full">
        <div v-if="isLoggedIn">
            <v-ons-page>
                <v-ons-toolbar>
                    <div class="center">{{ title }}</div>
                </v-ons-toolbar>

                <v-ons-tabbar 
                    swipeable position="auto" 
                    :tabs="tabs" 
                    :visible="true" 
                    :index.sync="activeIndex"
                >
                </v-ons-tabbar>
            </v-ons-page>
        </div>
        <div class="h-full" v-else>
            <!-- add an event "@login-success" to login component -->
            <!-- this event will trigger #loginView methods ⬇️ -->
            <login @login-success="loginView"></login>
        </div>
    </div>
</template>

<script lang="ts">
import Vue from 'vue'
import homePage from './pages/homepage.vue'
import camera from './pages/camera.vue'
import profile from './pages/profile.vue'
import login from './pages/login.vue'

export default {
    components: {
        login
    },
    data() {
        return {
            isLoggedIn: false,
            userName: { type: String },
            userID: { type: Number },
            activeIndex: 0,
            tabs: [
                {
                    icon: 'fa-home',
                    label: 'Home',
                    page: homePage,
                    key: "homePage"
                }, 
                {
                    icon: 'fa-camera',
                    label: 'Camera',
                    page: camera,
                    key: "camera",
                    props: {
                        userName: {
                            type: String // specify typing
                        },
                        userID: {
                            type: Number // specify typing
                        }
                    }
                }, 
                {
                    icon: 'fa-user',
                    label: 'Profile',
                    page: profile,
                    key: "profile",
                    props: {
                        userName: {
                            type: String // specify typing
                        },
                        userID: {
                            type: Number // specify typing
                        }
                    }
                }, 
            ]
        }
    },
    methods: {
        // this is the loginView method triggered by @login-success event ⬆️
        loginView(user) {
            // this.tabs[2] passes the userName to the `profile` tab child component
            // a child passes data to a parent by events ($emit)
            // a parent passes date to child by `props
            this.userName = this.tabs[2].props.userName = this.tabs[1].props.userName = user.name
            this.userID = this.tabs[2].props.userID = this.tabs[1].props.userID = user.id
            this.isLoggedIn = true
        }
    },
    computed: {
        title() {
            return this.tabs[this.activeIndex].label === 'Home' ? 'Basicgram' : this.tabs[this.activeIndex].label
        }
    }
}
</script>

Now just change `pages/profile.vue` to use `userName` prop that was passed in:

<template>
    <v-ons-page>
        <p style="text-align: center">
            {{ userName }}'s Profile
        </p>
    </v-ons-page>
</template>

<script lang="ts">
import Vue from "vue"

export default {
    props: {
        userName: {
            type: String
        },
        userID: {
            type: Number
        }
    },
    data() {
        return {}
    }
}
</script>

4. Cross-Origin Resource Sharing (CORS)

When you try to log in, you might see an error like this:

Access to XMLHttpRequest at 'http://localhost:3000/users/add' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

This is called the Same Origin Policy restriction which will not allow some HTTP methods when the requestor (our view in localhost:8080) and the resource owner (our API in localhost:3000) are of different "origins".

Same origin must satisfy 4 conditions: 1) domain, 2) subdomain, 3) protocol (https or http), and 4) port (which is usually omitted in production). For example: https://domain.com (view) and https://domain.com/api (api) will work. But api.domain.com or api.domain.com:3000 won’t work.

Same Origin Policy very restrictive but does bypassing it cause any issue? Not really, as anyone with malicious intent can easily break through by spoofing origin of request. You can bypass it by enabling Cross-Origin Resource Sharing (CORS):

npm install cors --save
npm install @types/cors --save-dev

Add cors:

Note: app.use(cors) must be instantiated before your routings. So a good place to put can be just before the "//view engine setup"

import cors from 'cors'

// enable cors
app.use(cors({
    credentials: true,
    origin: true,
    methods: ['GET, HEAD, PUT, PATCH, POST, DELETE'],
    maxAge: 31536000000000,
    preflightContinue: true
}))

5. Login

Ignore the password and log in, and whichever name you use, it should either create the user if it doesn't exist, or login if it does:

If you have finished up to Part 4, you have learnt the basics of TypeScript with Express and Vue. So now we are ready to more advance Express API works (receiving images and storing them) and Vue templating (AJAX updating) in Part 5.

Build Instagram Using TypeScript, Node, Express and Vue - Part 3

calvintwr — Wed, 10 Jun 2020 19:48:28 +0000

This is tutorial 3 of a 5-part tutorial, but each tutorial can be read in isolation to learn various aspects Node+Express+TypeScript+Vue API/Vue web app set up.

Looking to learn mobile/desktop apps? The skills and concepts here are fundamental and re-usable for mobile apps (NativeScript) or desktop apps (Electron). I may cover them as a follow-on.

Navigation to other parts (you are at part 3)

Setting up Node and Express API with TypeScript
Setting up VueJs with TypeScript
Setting up Postgres with Sequelize ORM
Basic Vue templating and interaction with API
Advanced Vue templating and image uploading to Express

After you have gotten your view ready in part 2, we must now create API endpoints allow users to post pictures and captions, as well produce a post feed.

If you have not, you can start building by cloning and checking out tutorial-part2 branch:

git clone https://github.com/calvintwr/basicgram.git
git checkout tutorial-part2

1. Setting up runtime checking for your API

The first thing you want to do is to set up runtime checking for your API, because TypeScript does not do that. Also you may also need to produce comprehensible error messages for your requestors. A library that will serve this specific need is you-are-not:

npm install you-are-not --save

We will change the "routes/user.js" file to ".ts", and set up a /add route so that we can add users:

import express from 'express'
const router = express.Router()
const Not = require('you-are-not')
const not = Not.create()

router.get('/', function (req: express.Request, res: express.Response, next: express.NextFunction) {
    res.send('respond with a resource')
})

router.put('/add', function (req: express.Request, res: express.Response, next: express.NextFunction) {

    not('string', req.body.name, 'User Name', 'Please check your entry') // will error if name is not what you expected.

    // perform tasks here

    res.send('completed task and respond with results')
})
module.exports = router

The Not library also have many more features to strengthen your API, read more here.

You can use Postman or just cURL to test it out.

# This will error
curl -X PUT -d wrong=Input localhost:3000/users/add
# Outputs {"message":"Wrong Type (User Name): Expecting type `string` but got `undefined`. Please check your entry"}

# This will work
curl -X PUT -d name=Jane localhost:3000/users/add

Now that we have an endpoint working, and the error handling looks pretty alright with Not, it's time to create the database to store stuff.

2. Setting up a database - PostgresSQL with SequelizeJS

On PostgresSQL

We will use PostgresSQL as the database. It is fast, reliable and also have JSON field to store schema-less data. So it fulfils quite a lot as a principle database. In truth, a very large project will use different databases to complement each other. But for the most bit, Postgres has everything you need.

This tutorial will not cover how to install postgres, but you can read the following installation guides:

Once you have installed postgres, set up a database and keep the credentials with you, as we will need it later.

Tip: I personally like DBeaver as the GUI db management tool the most.

SequelizeJS

Sequelize is a mature NodeJS Object Relational Mapper/Mapping (ORM) that uses a promise-style syntax, which makes your code very readable:

DB.Model
    .findAll()
    .then(results => { 
        //do something with results
    }).then(results => {
        //respond to client
    }).catch(err => {
        //the promise chain is broken
        //and error handling is elegant
    })

Promise patterns are also very powerful once you get the hang of it. It copes with error bubbling exceptionally well, which is critical in an API context. Promise syntax also makes it easy to use transactions, a data rollback feature which in my experience, is quite a baseline requirement but not always present in even popular apps.

We will continue to bleeding-edge our way with Sequelize beta 6. You will also need to install Postgres' adaptors as well:

npm install sequelize@6.0.0-beta.6 --save
npm install pg pg-hstore --save

You also want the sequelize-cli tool as it will become the default way to handle the models. The cli now generates JS files but we shouldn't need to care.

# @next tag brings in the beta 6 cli
npm install sequelize-cli@next -g

# cd into "basicgram/api/src"
sequelize init

Set up configurations:

/* config/config.json */

// by default node runs in development mode if you
// did not explicitly specify
"development": {
  "username": your username,
  "password": password,
  "database": database name,
  "host": "localhost", // this is usually the cause
  "dialect": "postgres"
}

Sequelize is pretty silent about successfully connecting to the database, so we will just insert some code in `models/index.js` to notify us when the connection succeeds:

/* models/index.js */

// Test and log connection to the database
sequelize
    .authenticate()
    .then(function (err) {
        console.log('Connection has been established successfully.')
    })
    .catch(function (err) {
        console.log('Unable to connect to the database:', err)
    })

3. Create our models

Seqeulize is enforcing use of CLI as a default way. Although it is a little clunky in my opinion, it does prevent a lot of errors once you get the hang of it. To create the User and Post models:

sequelize model:create --name User --attributes nam e:string
sequelize model:create --name Post --attributes caption:string, image:string

This creates user.js and post.js inside of "src/models", and also the migration files, which will be persisted to the db when you run:

sequelize db:migrate

And you should see:

Note: And if you check your database, you will find that Seqeulize created "Users" and "Posts" tables, and took the initiative to plurialise the names. So just keep that in mind.

4. Add associations

The way to do this is to create a new migration file. It's again rather clunky at first but you'll be fine once you get the hang of it.

First we will need to add the associations to the files:

/* user.js */
User.associate = function(models) {
    // I always prefer to manually name my foreignKey.
    // But you can have Sequelize automatically take care of naming for you.
    User.hasMany(models.Post, {foreignKey: 'User_userID' })
}

/* post.js */
Post.associate = function(models) {
    Post.belongsTo(models.User, {foreignKey: 'User_userID' })
}
// #belongsTo will create the foreignKey on the Post table.

And set up a migration file:

sequelize migration:generate --name add-post-user-association

Go under the migrations folder and find a file with "[timestamp]-add-post-user-association". It is a template. And remember that your table names are pluralised:

module.exports = {
  up: (queryInterface, Sequelize) => {
    return queryInterface.addColumn(
      'Posts', // name of Source model - PLURAL!
      'User_userID', // name of the key we're adding 
      {
        type: Sequelize.INTEGER,
        references: {
          model: 'Users', // name of Target model - PLURAL!
          key: 'id', // key in Target model that we're referencing
        },
        onUpdate: 'CASCADE',
        onDelete: 'SET NULL'
      }
    )
  },

  down: (queryInterface, Sequelize) => {
    return queryInterface.removeColumn(
      'Posts', // name of Source model - PLURAL!
      'User_userID' // key we want to remove
    );
  }
};

Explanation: What a migration file does is that the change you want to make is defined in up, and to undo this change, the reversal is defined in down. Which is why in this case the reversal is just to simply remove the User_userID column. To understand better, read this excellent guide by Maria Burlando.

We run the migration again:

sequelize db:migrate

If you get ERROR: relation "public.Post" does not exist error, remember it's Posts, not Post.

5. See if Sequelize works - Get all users

Set up the code to get all users for the '/' route:

/*.routes/users.ts */

router.get('/', function (req: express.Request, res: express.Response, next: express.NextFunction) {
    DB.User.findAll().then((result: any) => {
        console.log(result)
        res.send(result)
    }).catch((err: Error) => {
        // Calling #next will hand the error back to express,
        // so that the error handler defined in `app.ts` will handle.
        next(err)
    })
})

If all goes well, you will be able to see this in your terminal:

[nodemon] restarting due to changes...
[nodemon] starting `ts-node ./src/bin/www`
/ => .routes/index.js
/users => .routes/users.ts
Executing (default): SELECT 1+1 AS result
Connection has been established successfully.

In your browser, go to localhost:3000/users, to verify that a DB query will execute and return results:

Executing (default): SELECT "id", "name", "createdAt", "updatedAt" FROM "Users" AS "User";
[]
GET /users 304 31.818 ms - -
Executing (default): SELECT "id", "name", "createdAt", "updatedAt" FROM "Users" AS "User";

Where's the result? It's the empty array [] because we don't have any users yet, which we will add next.

6: Adding users

For simplicity, we will skip user signup and authentication (many tutorials out there), and provide a simple way to add users in the '/add' route:

/*.routes/users.ts */

router.put('/add', function (req: express.Request, res: express.Response, next: express.NextFunction) {

    not('string', req.body.name, 'User Name', 'Please check your entry')

    // most of the time, you will need findOrCreate
    // as users may attempt to create a user account
    // with a username or email that already exist
    return DB.User.findOrCreate({
        where: {
            name: req.body.name
        }
    }).then((user: any) => {
        // #findOrCreate returns an array [user, created (true or false)]
        console.log(user)
        // if created, it's 201, otherwise Express defaults to 200 so nothing needs to be done.
        if (user[1]) res.status(201)
        res.send(user[0])
    }).catch((err: Error) => {
        next(err)
    })
})

We will use cURL to add a few users:

curl -X POST -d name=Jane localhost:3000/users/add
curl -X POST -d name=John localhost:3000/users/add
curl -X POST -d name=Mike localhost:3000/users/add

You should see the corresponding server logs that shows that the users have been successfully added. And if you now navigate to localhost:3000/users, you will see some results:

Now that your database is all set up, you can head over to Part 4 to learn some basic Vue templating and how it interacts with the Express/Node API.

Build Instagram Using TypeScript, Node, Express and Vue - Part 2

calvintwr — Wed, 10 Jun 2020 19:47:04 +0000

This is tutorial 2 of a 5-part tutorial, but each tutorial can be read in isolation to learn various aspects Node+Express+TypeScript+Vue API/Vue web app set up.

Looking to learn mobile/desktop apps? The skills and concepts here are fundamental and re-usable for mobile apps (NativeScript) or desktop apps (Electron). I may cover them as a follow-on.

Navigation to other parts (you are at part 2)

Setting up Node and Express API with TypeScript
Setting up VueJs with TypeScript
Setting up Postgres with Sequelize ORM
Basic Vue templating and interaction with API
Advanced Vue templating and image uploading to Express

In Part 1 you have completed an API scaffold. So now you will build a view to consume the API.

If you have not, you can start building by cloning and checking out tutorial-part1 branch:

git clone https://github.com/calvintwr/basicgram.git
git checkout tutorial-part1

1. Installing a VueJS + Webpack boilerplate

We will use the best boilerplate I can find that has VueJS 2 with Webpack 4, and TypeScript. I then forked to improve further. Less the fact that VueJS 3 has limited compatibility and Webpack 5 is not out yet, at the time of writing this is really as bleeding edge as possible.

Inside of "basicgram" root directory, run:

git clone https://github.com/calvintwr/vue-webpack-typescript-boilerplate.git 'view'

(Credits to ahmedash95 from who I forked and modified the boilerplate from.)

Go into "basicgram/view" and run the following commands:

npm install
npm run dev

npm run dev spins up a webpack development server that hot compiles when it detects changes to your vue files.

Head over to localhost:8080 and you should see the boilerplate up and running:

2. VueJS component library

VueJS has an ecosystem of component libraries which provides you with pre-built UI components -- like a sticky navigation bar, or a container with infinity scroll feature -- much like building Lego.

OnsenUI already installed for you

OnsenUI is an OK library for mobile use, given that not many mobile libraries exist or are well-maintained. It is already installed in the boilerplate. So you can skip to Step 3 if you are not interested to learn how to install Vue component libraries.

In case you are interested, the following commands and code were used to install Onsen:

npm install onsenui vue-onsenui -save

For your brief understanding, most of these component libraries are portable to different frontends like React, Angular etc. So they always come in a "core package" (in this case onsensui) which you will install for any framework, along with a "bindings package" (in this cause vue-onsensui) specific to the framework you intend to use.

In `src/index.ts` is where you need to import these modules. I merely followed onsen's instructions.

// Onsen
import * as Onsen from 'vue-onsenui' // needed to use * as Onsen for TypeScript to work, this is the only difference from the official guide.
import 'onsenui/css/onsenui.css'
import 'onsenui/css/onsen-css-components.css'
Vue.use(Onsen)

Note: You are not limited to one library, but it makes sense to stick to a few to not bloat your code.

Note: In the package you will also find tailwindcss module, which is essentially something like bootstrap, but I find a little bit better for Vue use-case. It has some neat features like purging unused css styles from your builds. You will learn about it in the later tutorials.

3. Start building

From the OnsenUI components library, we will select the Tabbar component to begin building our app.

First we create a new file and make a tabbar page, and we want to put it into a subfolder: `pages/homepage.vue`.

<!-- pages/homepage.vue -->
<template>
    <v-ons-page>
        <p style="text-align: center">
            This is the home page
        </p>
    </v-ons-page>
</template>

<script lang="ts">
import Vue from "vue"

export default {
    data() {
        return {}
    }
}
</script>

The above is the simplest form a fresh Vue template can be written in. You can always start from this structure.

Next we modify `home.vue`:

<!-- home.vue -->
<template>
    <div>
        <v-ons-page>
            <v-ons-toolbar>
                <div class="center">{{ title }}</div>
            </v-ons-toolbar>

            <v-ons-tabbar 
                swipeable position="auto" 
                :tabs="tabs" 
                :visible="true" 
                :index.sync="activeIndex"
            >
            </v-ons-tabbar>
        </v-ons-page>
    </div>
</template>

<script lang="ts">
import Vue from 'vue'
// we import homePage, which actually becomes a Javascript object that we can reference.
import homePage from './pages/homepage.vue' 

// the below syntax follows OnsenUI's guide
export default {
    data() {
        return {
            activeIndex: 0,
            tabs: [
                {
                    // By default, OnsenUI uses IOS/Android icons.
                    // Because it's a mobile app centric library. 
                    // So we change to fontawesome for web app.
                    icon: 'fa-home', 
                    label: 'Home',
                    page: homePage,
                    key: "homePage"
                }
            ]
        }
    },
    computed: {
        title() {
            // nothing too interesting, just a logic to handle our page title.
            // this is a pretty standard use of VueJS computed property
            return this.tabs[this.activeIndex].label === 'Home' ? 'Basicgram' : this.tabs[this.activeIndex].label 
        }
    }
}
</script>

Webpack dev server should reload your browser and you should see this:

Continue to add more tabs by duplicating `homepage.vue`. We name the files `camera.vue` and `profile.vue`:

Import them into home.vue:

import Vue from 'vue'
import homePage from './pages/homepage.vue'
// import the pages here.
import camera from './pages/camera.vue'
import profile from './pages/profile.vue'

export default {
    data() {
        return {
            activeIndex: 0,
            tabs: [
                {
                    icon: 'fa-home',
                    label: 'Home',
                    page: homePage,
                    key: "homePage"
                }, 
                // and add more items to the tabs.
                {
                    icon: 'fa-camera',
                    label: 'Home',
                    page: camera,
                    key: "camera"
                }, 
                {
                    icon: 'fa-user',
                    label: 'Home',
                    page: profile,
                    key: "profile"
                }, 
            ]
        }
    },
    computed: {
        title() {
            return this.tabs[this.activeIndex].label === 'Home' ? 'Basicgram' : this.tabs[this.activeIndex].label
        }
    }
}

And you get something basic-looking, but mobile responsive and promising:

With this app scaffold, which you will just add more components as you go.

Now, we need to head back to make APIs for this app to consume. Continue to part 3: Building an API service and setting up Postgres.

Build Instagram Using TypeScript, Node, Express and Vue - Part 1

calvintwr — Wed, 10 Jun 2020 19:44:13 +0000

This is tutorial 1 of a 5-part tutorial, but each tutorial can be read in isolation to learn various aspects Node+Express+TypeScript+Vue API/Vue web app set up.

At the end of this 5-part tutorial, you will learn to build an app like this:

Looking to learn mobile/desktop apps? The skills and concepts here are fundamental and re-usable for mobile apps (NativeScript) or desktop apps (Electron). I may cover them as a follow-on.

Navigation to other parts (you are at part 1)

Setting up Node and Express API with TypeScript
Setting up VueJs with TypeScript
Setting up Postgres with Sequelize ORM
Basic Vue templating and interaction with API
Advanced Vue templating and image uploading to Express

Introduction

All good apps should start from a rock-solid base, which is what this tutorial about, illustrated through building a very simple photo sharing app, instead of a Todo (which really doesn't show much). Through these tutorials, you will learn TypeScript, Node, Express and VueJS, using versions as bleeding edge as it can get at the time of this post (some pre-releases where practicable).

*Sadly, Deno was considered but is still too early and to use. However, when the time comes, you are likely able to switch to Deno and reuse much of your API codebase if you generally follow best practices in this tutorial. You will be able to re-use all your view coding as it is not coupled to the API.

To be completely honest, Instagram can't be built in a single tutorial, so admittedly the title of this post is an exaggeration. We will call this project "Basicgram".

Get your repo

You can start building by cloning and checking out tutorial-part1 branch:

git clone https://github.com/calvintwr/basicgram.git
git checkout tutorial-part1

Folder Structure

Folders will be split into "api", which will run a Node+Express set up, and "view", which will run a Vue+Webpack set up.

Get started - Installing Express (API engine)

npx express-generator --view=hbs

I opted for Handlebars (hbs) as the view engine because it looks like HTML so you won't need to learn new templating syntax. But you hardly will use since we will only be using Express for API service -- but it's there for you when you need it.

We will use the latest Express 5.0 (pre-release) and update all module versions, so edit the package.json file:

{
  "name": "api",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node ./bin/www"
  },
  "dependencies": {
    "cookie-parser": "~1.4.5",
    "debug": "~4.1.1",
    "express": "~5.0.0-alpha.8",
    "hbs": "~4.1.1",
    "http-errors": "~1.7.3",
    "morgan": "~1.10.0"
  }
}

Fire it up and see if it all works

npm install
npm start

Go to localhost:3000 and express should greet you.

Express Routings

One of the first Express things you want to get is express-routemagic, which automatically require all our routes instead of declaring them file by file (you will see huge Express apps and their tower of routing codes which doesn't make sense). So just get routemagic, problem solved.

npm install express-routemagic --save

We will replace the routing requires:

var indexRouter = require('./routes/index')
var usersRouter = require('./routes/users')
app.use('/', indexRouter)
app.use('/users', usersRouter)

With:

const Magic = require('express-routemagic')
Magic.use(app, { invokerPath: __dirname }) // need `invokerPath` because we shifting Express into a `src` folder.

That's it, you will never need to worry about routings. Let's move on.

Converting to TypeScript

TypeScript provides quite a lot of useful features to build better code. You can google its benefits. It has its downsides too, especially being more tedious and having to deal with non-typescript packages (there are many useful and time-proven ones, but didn't see the need to port themselves over to TypeScript syntax). Throughout this tutorial, figuring how to convert some JS syntax to TypeScript were either painful or close to impossible. But well, we soldier on.

Since now we need to compile our TS to JS for Node runtime, we will need a few steps to get there.

1. Pack your Express into a "src" folder like this:

And also notice that "app.js" is renamed to "app.ts". We will start with this and leave the rest alone for now. Baby steps.

Tip: I think it is OK to have mixed codebase. Not everything needs to be in TypeScript, plus you will be missing out a lot of really good JS modules. But I'm sure this statement invokes agitation amongst TypeScriptors. Oh well, make your case below.

2. Install TypeScript package and set up configurations

Install TypeScript (note: all npm commands are to run in the basicgram/api folder. api and view are technically two different apps. If you run npm in basicgram, you will mixed their node_modules and other configurations up.)

Setting up the TypeScript compiler

npm install typescript --save-dev

Set up the `tsc` command in `package.json`:

"script": {
    "start": "node ./bin/www", // this came default with express, but we will change it later.
    "tsc": "tsc"
}

And initialise tsc which will generate a configuration file:

npx tsc --init

tsconfig.json will now appear in basicgram/api. This controls the compiler's behaviour. There's generally 2 default behaviours we want to change:

TSC by default outputs ES5, which is really unnecessary for Node, being a server-side runtime (if what is stopping you from upgrading Node are your old apps, see Node Version Manager).
It will search compile all .ts files inside of basicgram/api and produce .js alongside it, which really isn't what we want.

So we make the following changes:

{
    "compilerOptions": {
        "target": "ES6", // you can go for higher or lower ECMA versions depending on the node version you intend to target.
        "outDir": "./dist" // to output the compiled files.
    }, "include": [
        "src" // this tells tsc where to read the source files to compile.
    ]
 }

Now let's try out our command:

npm run tsc

You will see errors like:

src/app.ts:21:19 - error TS7006: Parameter 'req' implicitly has an 'any' type.

21 app.use(function (req, res, next) {

That's mean TypeScript works, and it's telling you app.ts -- which is still in Javascript -- has type safety violations, rightfully so. And so we start the conversion.

3. Code conversion and type declarations

First, we need to install type declaration for all modules. Just go with me first, I'll explain what this is all about later. They are named "@types/[modulename]". Whether they are available depends on if the package owner has made it. A lot of them didn't really bothered. In any case, we are only going to do it for node and express as an example, while skipping over type-checking for other modules using // @ts-ignore.

npm install @types/node
npm install @types/express

And convert the app.ts into this:

(Note: Use of @ts-ignore is not recommended, and only for the purposes of this demo.)

// @ts-ignore
import createError = require('http-errors') // change all `var` to import
import express = require('express')
import { join } from 'path' // this is a Node native module. only using #join from `path`
// @ts-ignore
import cookieParser = require('cookie-parser')
// @ts-ignore
import logger = require ('morgan')
// @ts-ignore
import Magic = require('express-routemagic')
const app: express.Application = express() // the correct type declaration style.
// view engine setup
app.set('views', join(__dirname, 'views'))
app.set('view engine', 'hbs')
app.use(logger('dev'))
app.use(express.json())
app.use(express.urlencoded({ extended: false }))
app.use(cookieParser())
app.use(express.static(join(__dirname, 'public')))
Magic.use(app, { invokerPath: __dirname }) // // need to use `invokerPath` because we are not in api's root dir.
// catch 404 and forward to error handler
app.use((req: express.Request, res: express.Response, next: express.NextFunction) => { // type declaration, and changed to use arrow function
    next(createError(404))
})
// error handler
app.use((err: any, req: express.Request, res: express.Response, next: express.NextFunction) => {
    // set locals, only providing error in development
    res.locals.message = err.message
    res.locals.error = req.app.get('env') === 'development' ? err : {}
    // render the error page
    res.status(err.status || 500)
    res.render('error')
})
module.exports = app

What is app.use? It is Express's way of using "middleware" (functions that will run and be given the HTTP request to "read" and do something to it). And it is sequential, and one way is to imagine a HTTP request "falling" through your middlewares: In this case it will first pass through logger('dev'), which logs the request on your terminal, then express.json() which parses the request into json... and so on so forth sequentially.

TypeScript Basics Explanation

The @types/express module you have installed are TypeScript declarations for Express objects. Declarations are like a dictionary -- it explains what something is or isn't.

If you refer lower down in app.ts, the block of // error handler code shows how this "dictionary" is applied to function arguments:

(err: Error, req: express.Request, res: express.Response, next: express.NextFunction) => { ... }

What it means is that, the req argument are "of the same type and -- for a lack of better word -- form" with Express' Request object/prototype (I refuse to use the word "class", because Javascript is irrefutably classless).

So within the function, if you try to use Request as a type that it isn't, or if you try to invoke a method that Request does not have, TypeScript will bitch about it.

(req: express.Request) => {

   req.aMethodThatDoesNotExist() // red curlies underlines, and will not compile.

   if (req === 'someString') {} // TypeScript will tell you this is always false.

})

All that, is in essence a very basic explanation of how TypeScript type-checks your code.

And now if you run npm run tsc again, you should get no errors.

4. Copy all files to "./dist"

TSC will only compile .ts files, rightfully so. But you need to copy the rest of the files over, including those .js files that you either don't intend to convert, or will convert later (that's the beauty, you don't need to always OCD everything to TypeScript -- not all code is worth your time). tsc doesn't seem to provide a good way (see issue here), so we will use the cpy-cli and del-cli modules:

npm install cpy-cli del-cli --save-dev

Set up the npm scripts in package.json.

A prebuild script that uses del shell command (from del-cli module) to delete the old "./dist" folder:

"prebuild": "del './dist'"

A postbuild script that uses cpy shell command (from cpy-cli module) to copy remaining files over:

"postbuild": "cpy --cwd=src '**/*' '!**/*.ts' './../dist' --parents"

// --cwd=src means the Current Working Directory is set to "./src"
// '**/*' means all files and folder in the cwd.
// '!**/*.ts' means excluding all typescript files.
// './../dist' means "basicgram/api/dist", and is relative to "src" folder
// --parents will retain the folder structure in "src"

And your scripts in package.json will be:

{
    "scripts": {
        "start": "node ./dist/bin/www",
        "build": "npm run tsc",
        "prebuild": "del './dist'",
        "postbuild": "cpy '**/*' '!**/*.ts' './../dist' --cwd=src --parents",
        "tsc": "tsc"
    }
}

Now, just to check everything is working, go to "src/routes/index.js" and change title from Express to Express in TypeScript:

res.render('index', { title: 'Express with TypeScript' })

Build and run it:

npm build
npm start

5. Setting up auto re-compiling

For development, it's inefficient to keep running npm build and npm start. So we are going to use nodemon to auto restart the server on file changes, and ts-node to execute the TypeScript files as though they are Javascript (note: this is intended for development environment and does not output to ./dist):

npm install nodemon ts-node --save-dev

Add the following to package.json:

"scripts": {
    "dev": "nodemon --ext js,ts,json --watch src --exec 'ts-node' ./src/bin/www"
}

Explanation:

--exec: We use --exec flag because nodemon will not use ts-node, instead will use node if the entry file is not ".ts". In this case www is not.
--ext: When --exec is used, we also need to use --ext to manually specify the files to watch for changes.
--watch: This defines which folder nodemon will watch for changes to do a restart.
(Credits to this video)

Run your dev server:

npm run dev

Your API is all fired up! Make some changes to see how nodemon auto re-compiles. See Part 2 to set up your view engine with VueJS in TypeScript.

Endnotes:

Build Instagram Using TypeScript, Node, Express and Vue - Part 5

calvintwr — Wed, 10 Jun 2020 18:54:58 +0000

This is tutorial 5 of a 5-part tutorial, but each tutorial can be read in isolation to learn various aspects Node+Express+TypeScript+Vue API/Vue web app set up.

Advanced Vue templating and image uploading to Express

Looking to learn mobile/desktop apps? The skills and concepts here are fundamental and re-usable for mobile apps (NativeScript) or desktop apps (Electron). I may cover them as a follow-on.

Navigation to other parts (you are at part 5)

Setting up Node and Express API with TypeScript
Setting up VueJs with TypeScript
Setting up Postgres with Sequelize ORM
Basic Vue templating and interaction with API
Advanced Vue templating and image uploading to Express

If you have not, you can start building by cloning and checking out tutorial-part4 branch:

git clone https://github.com/calvintwr/basicgram.git
git checkout tutorial-part4

In this tutorial you will complete the last feature, which is to upload a post with image with Basicgram app, build the Express API endpoint to receive the image, and another endpoint to produce a post feed, and finally the Vue templating to display them to complete the whole loop.

1. Image resizing

First, you want to resize images on client-side before uploading. This means using a Javascript browser resizer, which can sound like a bad idea at first, but it really isn't, given this context. On balance, client-side resized images allows faster upload time, reduced server bandwidth consumption, and flexibility to allow users to practically dump images in right from a DSLR. And in fact it is not that slow, with pretty good image results Blitz:

npm install blitz-resize --save

const Blitz = require('blitz-resize')
let blitz = Blitz.create()

blitz.resize({
    source: file or event,
    height: 640,
    width: 640,
    output: 'jpg', // or png or gif etc,
    outputFormat: image/canvas/data/blob/download,
    quality: 0.8 // 80%
}).then(output => {}).catch(err => {})

On Blitz and image manipulation/uploading

For data types in image manipulation, there are commonly 2 types. First is dataURI which comes in handy and can be attached to <img>'s src like this:

<!-- single quote due to XSS Markdown restrictions -->
<img src=`data:image/png;base64,iVBORw0KGgo...`>

Second is the Blob format, which is used for uploading over HTTP/HTTPS.

Blitz can provide for either by using output: 'data' or output: 'blob', but we will see later how this comes in handy.

2. Code `camera.vue` to prepare to post stuff:

<!-- camera.vue -->
<template>
    <v-ons-page>
        <div class="container text-center  mx-auto p-1">
            <!-- attach the #readFile method to change event -->
            <input 
                type="file" 
                capture="camera" 
                accept="image/*" 
                id="cameraInput" 
                name="cameraInput"
                @change="readFile" 
            >
            <img class="py-2" ref="image">
            <!-- `ref` defined for this textarea is a Vue reference which will be handy -->
            <textarea 
                class="py-2 w-full textarea" 
                rows="3" 
                placeholder="Write your caption"
                ref="caption"
            ></textarea>

            <!-- #post is for uploading the post -->
            <button 
                class="my-2 button"
                @click="post" 
                :disabled="buttonDisabled"
            >Post</button>
        </div>

    </v-ons-page>
</template>

<script lang="ts">
import Vue from "vue"
import Blitz = require('blitz-resize')
import * as superagent from 'superagent'
const blitz = Blitz.create()

export default {
    props: {
        userName: {
            type: String
        },
        userID: {
            type: Number
        }
    },
    data() {
        return {
            image: { type: Blob }, // this is to store our image
            buttonDisabled: true // a flag to turn our button on/off
        }
    },
    methods: {
        readFile(event) {
            let file = event.srcElement.files[0] // this is where HTML file input puts the file
            let self = this
            let output;

            // super fast resizing 
            blitz({
                source: file,
                height: 640,
                width: 640,
                outputFormat: 'jpg',
                // we will use data because we want to update the image in the DOM
                output: 'data', 
                quality: 0.8
            }).then(data => {

                // update the image so that user sees it.
                self.$refs["image"].src = data

                // prepare the Blob. Blitz internally has a #dataURItoBlob method.
                self.image = Blitz._dataURItoBlob(data) 

                self.buttonDisabled = false
            }).catch(err => {
                console.log(err)
            })

        },
        post(event) {
            let self = this
            this.buttonDisabled = true
            let caption = this.$refs["caption"].value // using Vue's $ref property to get textarea.

            // Note: To upload image, the request type will be "multipart"
            // Superagent automatically takes care of that and you need to
            // use `field` for text/plain info, and `attach` for files 
            superagent
                .post('http://localhost:3000/posts/add')
                .field('userID', this.userID)
                .field('caption', caption)
                .attach('photo', this.image)
                .then((res: superagent.Response) => {
                    alert('Successful post. Go to your profile to see it.')
                }).catch((err: Error) => {
                    this.buttonDisabled = false
                    alert(err)
                })
        }
    }
}
</script>

3. Prepare the API to receive the post

So now that our view is ready to post, we need to create the API endpoint of localhost:3000/posts/add.

Before we write the code, we should think about where to upload the files. The natural choice is to put under "public/uploads", but remember that in tutorial 1, we set up the TypeScript compiler to delete the whole "dist" folder (which also has public folder in it) before compiling into it. This will delete all our uploaded images with every compile.

So you have to move the public folder out to see on the same level with "api" and src, like this:

Also, you need to tell Express that you have changed the public folder, which is where by default it serves its static files from:

/* api/src/app.ts */

// change
app.use(express.static(join(__dirname, 'public')))

// to
app.use(express.static(join(__dirname, '../public')))

Express doesn't handle "multipart" requests, so we will need a module. The best one lying around is formidable. You also have multer and busboy, but again, I find formidable's syntax to be the most friendly.

Install formidable:

npm install formidable --save
npm install @types/formidable --save-dev

Formidable's syntax is pretty flexible, and is event-driven. So the idea is to attach functions to events. For example, when a HTTP receive completes all data transmission, formidable will emit the event end, which you will use like this:

const form = formidable()
function formEndHandler():void { perform some action. }
form.on('end', formEndHandler)

So with this in mind, we will create routes/posts.ts:

`posts.ts`:

import express from 'express'
import { Fields, Files, File } from 'formidable' // typing
import { join } from 'path' // we will use this for joining paths
const formidable = require('formidable') // formidable

const router = express.Router()
const Not = require('you-are-not')
const not = Not.create()
const DB = require('../models/index')

router.get('/', (req: express.Request, res: express.Response, next: express.NextFunction) => {
    // get all posts
})

router.post('/add', (req: express.Request, res: express.Response, next: express.NextFunction) => {

    const form = formidable({ multiples: true })

    let params: any
    form.parse(req, (err: Error, fields: Fields, files: Files) => {
        params = fields

        // use Not to sanitise our received payload

        // define a schema
        let schema = {
            userID: ['string', 'number'],
            caption: ['string']
        }

        // sanitise it
        let sanitised = Not.checkObject(
            'params',
            schema, 
            params, 
            { returnPayload: true }
        )

        // if sanitised is an array, we will throw it 
        if(Array.isArray(sanitised)) {
            throw Error(sanitised.join(' | ')) // join the errors
        }
        params = sanitised
    })

    let fileName: string;
    form.on('fileBegin', (name: string, file: File) => {
        fileName = name + (new Date().getTime()).toString() + '.jpg'
        file.path = join(__dirname, '../../public/uploads', fileName)
    })

    form.on('error', (err: Error) => {
        next(err) // bubbble the error to express middlewares
    })

    // we let the file upload process complete before we create the db entry.
    // you can also do it asynchronously, but will require rollback mechanisms
    // like transactions, which is more complicated.
    form.on('end', () => {
        return DB.Post.create({
            User_userID: params.userID,
            image: fileName,
            caption: params.caption
        }).then((post: any) => {
            console.log(post)
            res.status(201).send(post)
        }).catch((err: Error) => {
            next(err)
        })
    })
})

module.exports = router

Restart your server and head over to your view, and you should be able to do this:

If you realise, the resizing was very fast, and likewise the upload time, as the file size is drastically reduced with client-side compression by Blitz.

Now we just need to create the endpoints for a user to get all his/her posts, for the profile page, and also make the post feeds for the home page.

4. Profile page `profile.vue` and API endpoint

You should be pretty good by now. The endpoint (which we will name `GET /posts/own`) to get all posts of a user is not hard at all:

/* routes/posts.ts */

router.get('/own', (req: express.Request, res: express.Response, next: express.NextFunction) => {

    // we will receive userID as a string. We want to parse it and make sure
    // it's an integer like "1", "2" etc, and not "1.1", "false"
    Not.defineType({
        primitive: 'string',
        type: 'parseable-string',
        pass(id: string) {
            // TypeScript does not check at runtime. `string` can still be anything, like null or boolean.
            // so you need Notjs.
            return parseInt(id).toString() === id
        }
    })

    // for GET, the standard is to use querystring.
    // so it will be `req.query` instead of `req.body`
    not('parseable-string', req.query.userID)  

    DB.Post.findAll({
        where: {
            User_userID: req.query.userID
        },
        order: [ ['id', 'DESC'] ] // order post by id in descending, so the latest will be first.
    }).then((posts:any) => {
        res.send(posts)
    }).catch((err:Error) => {
        next(err)
    })
})

The low-down on VueJS's Hooks: #created(), #mounted() etc...

Next is profile.vue.

VueJS provides for several "hooks" which are called to prepare the view. They look like this:

<template>
    <div> {{ dataFromAPI }} </div>
</template>
<script>
import Vue from 'vue'
export default {
    data() {
        return {
            // this is bound to {{ dataFromAPI }} in the DOM
            dataFromAPI: 'Waiting for API call'
        }
    },
    // or created(), depending on when you want it.
    mounted() {
        // anything inside here gets called when this view is mounted

        // you will fetch some data from API.

        // suppose API results the results, then doing this:
        this.dataFromAPI = results
        // will update the value in {{ dataFromAPI }}
    }
}
</script>

The most commonly used are `created()` and `mounted()`. We are going to code `profile.vue` like this:

<!-- profile.vue -->
<template>
    <v-ons-page>
        <div class="content">
            <div class="w-full p-10" style="text-align: center">
                {{ userName }}'s Profile
            </div>

            <!-- Three columns Tailwind class-->
            <div v-if="posts.length > 0" class="flex flex-wrap -mb-4">
                <div 
                    class="w-1/3"
                    v-for="post in posts" 
                    :key="post.id"
                ><img :src="'http://localhost:3000/uploads/' + post.image"></div>
            </div>    
        </div>
    </v-ons-page>
</template>

<script lang="ts">
import Vue from 'vue'
import * as superagent from 'superagent'

export default {
    props: {
        userName: {
            type: String
        },
        userID: {
            type: Number
        }
    },
    data() {
        return {
            posts: { type: Array }
        }
    },
    mounted() {
        superagent
            .get('http://localhost:3000/posts/own')
            .query({ userID: this.userID })
            .then((res: superagent.Response) => {
                // attach the results to the posts in our data
                // and that's it! Vue will update the DOM because it's binded
                this.posts = res.body
            }).catch((err: Error) => {
                alert(err)
            })
    }
}
</script>

Explanation: That just tells Vue that when this view is mounted, please run the superagent request for me.

Tip: For some very odd reasons, OnsenUI needs all your content to be wrapped in <div class="content">, if not things will start to behave funny.

Tip: Notice that we wrap the posts with <div v-if="posts.length > 0">. This is to prevent Vue from rendering the DOMs which requires data but the API call has not yet completed. If you don't do that, nothing will break, just that you will see some pesky console log errors telling you that an image url is broken, for example.

For simplicity, we will skip the triggers that will update the views when say, you upload a post. Right now you will have to refresh the whole app.

And you should see:

We will do something similar for the `homepage.vue`, using #created(), which will be called a little earlier:

<template>
    <v-ons-page>
        <div class="content">
            <div v-if="posts.length > 0">
                <v-ons-card v-for="post in posts" :key="post.id">
                    <img class="w-full" :src="'http://localhost:3000/uploads/' + post.image">
                    <div class="py-1 content">
                        <p class="text-xs font-bold py-2">{{ post.User.name }}<p>
                        <p class="text-xs text-gray-700">{{ post.caption }}</p>

                    </div>
                </v-ons-card>
            </div>
        </div>
    </v-ons-page>
</template>

<script lang="ts">
import Vue from 'vue'
import * as superagent from 'superagent'

export default {
    props: {
        userID: {
            type: Number
        }
    },
    data() {
        return {
            posts: { type: Array }
        }
    },
    created() {
        superagent
            .get('http://localhost:3000/posts/feed')
            .query({ userID: this.userID })
            .then((res: superagent.Response) => {
                this.posts = res.body
            }).catch((err: Error) => {
                alert(err)
            })
    }
}
</script>

And our "/posts/feed" inside of `routes/post.ts` API:

router.get('/feed', (req: express.Request, res: express.Response, next: express.NextFunction) => {

    not('parseable-string', req.query.userID)  

    // user's feed is not his/her own posts
    DB.Post.findAll({
        where: {
            User_userID: {
                // this is a Sequelize operator
                // ne means not equal
                // so this means from all post that
                // doesn't belong to this user.
                [DB.Sequelize.Op.ne]: req.query.userID
            }
        },
        // we want to include the User model for the name
        include: [ DB.User],
        order: [ ['id', 'DESC'] ] // order post by id in descending, so the latest will be first.
    }).then((posts:any) => {
        res.send(posts)
    }).catch((err:Error) => {
        next(err)
    })
})

But after doing that, you realise that your app isn't sending userID the API. That is because we did not pass the userID prop to homepage.vue. We can fix that by editing home.vue:

icon: 'fa-home',
label: 'Home',
page: homePage,
key: "homePage",
props: {
    userID: {
        type: Number // add the userID prop to homePage
    }
}

Tip: You will realise that your app quickly outgrows Vue's basic mechanism of passing data around via props and event emitters. This is why you almost always need Vuex for state management, to store data accessible by the whole app in one place.

And it should work:

And there you have it! A super sketchy Instagram.

You can head over to the git repo to clone this completed app to play with it:

git clone https://github.com/calvintwr/basicgram.git

DEV Community: calvintwr

The true prototypial nature beneath "JavaScript classes"

World without the "new" keyword.

And simpler "prose-like" syntax with Object.create().

TLDR;

TypeScript Equivalent

Creating an descendant/copy of Person

Branching the Person prototype to Robot

Conclusion

Further reading

Commonly attached #create method

On #Object.defineProperty

4 "Bang For the Buck" Practices For Express API

1. Dealing with numbers - Check for EXACTLY what you are expecting

Not ok to accept inaccuracy

Using #Number, and being accurate

2. Provide actionable error messages

3. Add a timestamp to error messages

4. Always sanitise the payload

Accessing hidden information

Conclusion

About Not.JS

Database "Stuff" I Wished I Knew About For NodeJS - Part 2- Postgres

Why Postgres?

Apples are red and oranges are orange.

The worst reason to use MongDB

Query-builders and ORM

Query Builders - Knex

ORM

1. SequelizeJS

All the features you need, like transactions

Documentation

Common complains about ORM - slow

Augment ORM with query builders

2. Bookshelf

3. TypeORM

Code Reliability

Some say, if you use TypeScript, choose TypeORM

Features and Documentation

4. ObjectionJS

Conclusion

Database "Stuff" I Wished I Knew About For NodeJS - Part 1- MongoDB

No "one-size-fits-all"

MongoDB, and its early days

There are many things to love about MongoDB.

But

Reaction Commerce uses MongoDB, so it must be good.

Fast car, with no airbags

So should I?

For small and simple apps

To augment as a datastore

Relational data, use PG:

Non-relational data, use MongoDB:

Build Instagram Using TypeScript, Node, Express and Vue - Part 4

Navigation to other parts (you are at part 4)

1. Get a Type-Checking/Validation and HTTP library

So we go for superagent:

2. Build a login component

Create a "pages/login.vue" component:

home.vue will look like this:

3. VueJS bindings and events

And when we bring in the superagent and you-are-not modules into login.vue, it will look like this:

Now just change pages/profile.vue to use userName prop that was passed in:

4. Cross-Origin Resource Sharing (CORS)

5. Login

Build Instagram Using TypeScript, Node, Express and Vue - Part 3

Navigation to other parts (you are at part 3)

1. Setting up runtime checking for your API

2. Setting up a database - PostgresSQL with SequelizeJS

On PostgresSQL

This tutorial will not cover how to install postgres, but you can read the following installation guides:

SequelizeJS

We will continue to bleeding-edge our way with Sequelize beta 6. You will also need to install Postgres' adaptors as well:

Set up configurations:

Sequelize is pretty silent about successfully connecting to the database, so we will just insert some code in models/index.js to notify us when the connection succeeds:

3. Create our models

4. Add associations

First we will need to add the associations to the files:

Go under the migrations folder and find a file with "[timestamp]-add-post-user-association". It is a template. And remember that your table names are pluralised:

We run the migration again:

Creating an descendant/copy of `Person`

Branching the `Person` prototype to `Robot`

Commonly attached `#create` method

On `#Object.defineProperty`

So we go for `superagent`:

`home.vue` will look like this:

And when we bring in the `superagent` and `you-are-not` modules into `login.vue`, it will look like this:

Now just change `pages/profile.vue` to use `userName` prop that was passed in:

Sequelize is pretty silent about successfully connecting to the database, so we will just insert some code in `models/index.js` to notify us when the connection succeeds:

In `src/index.ts` is where you need to import these modules. I merely followed onsen's instructions.

First we create a new file and make a tabbar page, and we want to put it into a subfolder: `pages/homepage.vue`.

Next we modify `home.vue`:

Continue to add more tabs by duplicating `homepage.vue`. We name the files `camera.vue` and `profile.vue`:

Set up the `tsc` command in `package.json`:

2. Code `camera.vue` to prepare to post stuff:

`posts.ts`:

4. Profile page `profile.vue` and API endpoint

You should be pretty good by now. The endpoint (which we will name `GET /posts/own`) to get all posts of a user is not hard at all:

The most commonly used are `created()` and `mounted()`. We are going to code `profile.vue` like this:

We will do something similar for the `homepage.vue`, using #created(), which will be called a little earlier:

And our "/posts/feed" inside of `routes/post.ts` API: