DEV Community: Hong Jiang

Building Feature-rich Apps with Zero Backend Code

Hong Jiang — Thu, 09 Jul 2020 10:58:04 +0000

The availability of various cloud services makes developing apps ever easier. Now it's possible to develop sophisticated apps without writing any backend code. Instead of becoming a "full-stack" engineer, you can focus on the frontend - what the user sees and interacts with.

This article introduces how to build a diary web app without any backend code. A user can create an account and write diary entries only she can view. There is a demo deployed at Netlify in case you want to play with it first. The complete project is at GitHub.

We will use React for the frontend and LeanCloud to store data. Create a React app and install the LeanCloud JavaScript SDK:

npx create-react-app diary-demo --template typescript
cd diary-demo
npm i -S leancloud-storage

The generated project includes TypeScript support. I've formed the habit of using typescript for all frontend projects.

To follow along, you need to create a free LeanCloud account, create an app, and copy the app Id and app Key from the app settings page. I usually put the initialization code in a file called lc.ts and import it in other files.

import LC from 'leancloud-storage';

LC.init({
  appId: 'YOUR_APP_ID',
  appKey: 'YOUR_APP_KEY'
});

export default LC;

If you've used any third-party services before, you probably are wondering: isn't placing the app key in frontend code insecure? Bear with me. I'll address the security issue soon.

There is no shortage of React tutorials, so I'm only going to discuss code that replaces what you would otherwise accomplish with your own backend API.

Registration and Login

First, we need to let users create accounts and login.

LeanCloud provides a feature-rich user account system, but for the sake of simplicity, we will not deal with email/SMS verification and third-party logins. We will simply ask a new user to create a username and a password. The complete sign-up page is here. Besides the UI part, there're only a few interesting lines:

    const user = new LC.User();
    user.setUsername(username);
    user.setPassword(password);
    try {
      await user.signUp();
      setShowSuccessMsg(true);
    } catch (e) {
      setError(e.message);
    }

We simply create a new User object, set the username and password attributes, and create the new account. user.signUp() resolves to the new account created in the cloud, but we are ignoring the result here.

    try {
      await LC.User.logIn(username, password);
      history.push('/diary');
    } catch (e) {
      setError(e.message);
    }

After a successful login, we redirect the user to the /diary page. The current authenticated user can be obtained from LC.User.current().

Creating and reading diary entries

Our main application logic is on the diary page (complete code). There is only one type of data - diary entries. Let's name it Entry. In LeanCloud terminology each type of data is called a class. You can consider it a table in a database. Creating a Class in code is simple:

const Entry = LC.Object.extend('Entry');

Though the class is not actually created in the cloud until the first object of this type is saved. Saving a new object is similar to the registration code we've seen before:

    const entry = new Entry();
    try {
      const savedEntry = await entry.save({
        user: LC.User.current(),
        content: newEntry
      });
      setEntries([
        {
          id: savedEntry.id!,
          content: savedEntry.get('content'),
          date: savedEntry.createdAt!
        },
        ...entries
      ]);
    } catch (e) {
      setError(e.message);
    }

Note that we store the current user in the user attribute, so that later we can retrieve the entries belonging to this user. After saving the new entry, we prepend it to the list of entries which should be populated when the page is loaded.

To populate the entries, we use the React useEffect() hook to fetch all entries belonging to the current user sorted by creation time in descending order:

  const [entries, setEntries] = useState<DiaryEntry[]>([]);
  const me = LC.User.current();

  useEffect(() => {
    const fetchEntries = async () => {
      const query = new LC.Query('Entry');
      query.equalTo('user', LC.User.current());
      query.descending('createdAt');
      try {
        const fetchedEntries = await query.find();
        setEntries(
          fetchedEntries.map(entry => {
            return {
              id: entry.id!,
              content: entry.get('content'),
              date: entry.createdAt!
            };
          })
        );
      } catch (e) {
        setError(e.message);
      }
    };
    fetchEntries();
  }, [me]);

Now, users can sign up and login, post and read entries. We've implemented all the basic features. But the job is not done, and we must return to the security concern raised earlier.

Security

As we mentioned earlier, the API key is exposed in the frontend code. Even if we minimize and obfuscate the code, it is trivial for someone to find the key by looking at network requests. A malicious user can forge requests to read or overwrite other users' data. The mechanism to safeguard data is access-control list (ACL). When creating a piece of data, we need to consider who should have access to it and save the permission with the data. For example, in our case no one should have access to an entry except its author, so we should add the following lines before calling entry.save():

    const acl = new LC.ACL();
    acl.setPublicReadAccess(false);
    acl.setPublicWriteAccess(false);
    acl.setReadAccess(me, true);
    acl.setWriteAccess(me, true);
    entry.setACL(acl);

Now each user can only access her own entries after login.

This concludes the article. I plan to follow up with more articles about implementing full-text search and realtime updates. Please feel free to leave a comment if you have any questions or want to know more!

Modern C++ in small pieces: constant expressions

Hong Jiang — Thu, 20 Jun 2019 04:45:16 +0000

Modern C++ introduces the constexpr specifier to allow declaring
compile-time constant expressions. This allows the programmer to
explicitly specify what should be computed at compile time, instead of
guessing what might be optimized away as constants by the compiler. A
clearer boundary of compile time versus run time also makes other
compile-time utilities easier to use.

const auto a = 10;
constexpr auto b = a + 1;  // const b = 11;
constexpr auto c = a + b;  // const c = 21;

All variables declared with constexpr are implicitly const and
must be initialized with expressions computable at compile time, but
the converse is not true. A const constant can be initialized with a
run-time expression.

const auto a = std::rand();  // Ok.
constexpr auto b = a -1;  // compile error!

A function's return type can also be constexpr, as long as its
body has no run-time dependencies, and it is only applied to
constexpr arguments. The function is executed at compile time,
and no code is generated for the function body.

constexpr auto smaller(auto a, auto b) {
  return a <= b ? a : b;
}

int main() {
  const auto MAX_GROUP_SIZE = 400;
  const auto MAX_USERS = 500;
  constexpr auto LIMIT = smaller(MAX_USERS, MAX_GROUP_SIZE);
  return 0;
}

Constant expression can also be used as conditions in if and
switch statements. Because the condition is evaluated at compile
time, the false branch is not compiled at all.

if constexpr (sizeof(void*)*CHAR_BIT == 64) {
  std::cout << "Compiled for 64-bit OS." << std::endl;
} else {
  std::cout << "Not compiled for 64-bit OS." << std::endl;
}

A constant expression can consists of other constant expressions, so
you can potentially do some pretty complex computation at compile
time. For example, the following program let the compiler compute the
10th Fibonacci number:

constexpr unsigned int static_fib(unsigned int n) {
  if (n <= 1)
    return n;
  else
    return static_fib(n-1) + static_fib(n-2);
}

int main() {
  std::cout << static_fib(10) << std::endl;
  return 0;
}

Note that functions in constant expressions have to be purely
functional - there cannot be local variables, hence no loops. The code
generated by the compiler for the above program is equivalent to:

int main() {
  std::cout << 55 << std::endl;
  return 0;
}

In legacy C++, it would require unsightly abuse of templates to
achieve the same effect.

Type systems: dynamic versus static, strong versus weak

Hong Jiang — Wed, 06 Mar 2019 10:23:34 +0000

Almost every practical programming language has a type system that specifies how to assign types to various constructs in the language and how constructs of those types interact with each other. Most programmers characterize type systems with two sets of properties. One has to do with when rules of the type system are enforced (aka type checking): dynamic or static; The other has to do with how much safety guarantee the type system provides: strong or week.

This is a confusing topic. I've run into articles on multiple otherwise reputable websites claiming static typing means variables need to be declared before use, and dynamic typing means otherwise. This is very misleading. Haskell is a statically-typed language, yet programmers don't need to declare the type of each name¹. Types are inferred from how the names are used. Its optional type annotation is mostly for the benefit of human readers rather than the compiler. I've also seen articles that equate dynamic with weak and static with strong. This is also wrong. A dynamically-typed language can be more strongly-typed than a statically-typed language.

To understand the distinction, we need to separate names and values. A name is the identifier you use in a program to refer to entities like objects and functions. Values are the entities themselves. A name can refer to different values at different times, and a value can be referred to by different names.

In statically-typed languages, names have types, and the type of a name typically cannot change within its scope. A name of a certain type can only refer to values of that type. In a statement like a = sum(b, c), a, b, c, and sum all have types. The compiler checks to see if the types of a and b match with the parameter types of sum and if the result type of sum matches the type of a. If not, it emits a type error and refuses to compile the program.

In dynamically-typed languages, names themselves do not have types, but the values they refer to do. In the last example a = sum(b, c), when the program runs, the language runtime looks at the values b and c and makes sure they are of the type to which sum can be applied to. For example, sum(b, c) might be implemented as b + c, the language runtime checks if b and c refer to the types for which the operator + is defined. If not, it throws an exception.

Let's turn to the strength of type safety by looking at some examples.

Both C and Rust are statically-typed, but they provide different levels of type safety. Consider the following C program:

#include <stdio.h>

int main() {
  int numbers[] = {0, 1, 2};
  printf("%d", numbers[6]);
  return 0;
}

It has an obvious problem, but can be compiled successfully. Depending on what compiler you use, you might see a warning, but it's just a heuristic added by the compiler to assist programmers. The C language standard allows the program to be compiled. When I run this program on my Mac, it prints 32766% which is just whatever gibberish happened to be at that memory location. If this were a complex program, it would likely be a frustrating bug.

The following Rust program attempts to do the same thing:

fn main() {
    let numbers = [0, 1, 2];
    println!("{}", numbers[5]);
}

But when it is compiled, the following error is emitted. It won't get a chance to run.

error: index out of bounds: the len is 3 but the index is 5
 --> array.rs:3:20
  |
3 |     println!("{}", numbers[5]);

This is because in Rust, the length is part of the type of an array literal, so [0, 1] and [0, 1, 2] are actually different types. In this case the compiler can detect illegal access to an array literal just by looking at the type. To verify this, add a line to the rust code:

fn main() {
    let numbers = [0, 1, 2];
    let foo: () = numbers;  // <- add
    println!("{}", numbers[5]);
}

You will see the following error from the compiler:

error[E0308]: mismatched types
 --> array.rs:3:19
  |
3 |     let foo: () = numbers;
  |                   ^^^^^^^ expected (), found array of 3 elements
  |
  = note: expected type `()`
             found type `[{integer}; 3]`

This is an intentional type mismatch error we add to show the type of numbers. The last line says it's [{integer}; 3], in which 3 is the length of the array. For variable-size vectors, Rust uses a Result type to force programmers to check for the possibility of out-of-bound errors.

The infamous type systems of Perl and PHP have tormented countless programming souls. The following is copied verbatim from the official PHP manual:

$foo = 1 + "10.5";                // $foo is float (11.5)
$foo = 1 + "-1.3e3";              // $foo is float (-1299)
$foo = 1 + "bob-1.3e3";           // $foo is integer (1)
$foo = 1 + "bob3";                // $foo is integer (1)
$foo = 1 + "10 Small Pigs";       // $foo is integer (11)
$foo = 4 + "10.2 Little Piggies"; // $foo is float (14.2)
$foo = "10.0 pigs " + 1;          // $foo is float (11)
$foo = "10.0 pigs " + 1.0;        // $foo is float (11)

PHP and Perl are extremely lenient to type mismatches and go to great length to massage arguments into whatever types required. For quick-and-dirty scripts, they may allow the programmer to get things done with as little code as possible, but for large projects they are good at burying bugs. Most other languages in wide use today require explicit conversion between unrelated types, whether they are dynamically typed or statically typed. For example, in Clojure, you'd need to call Integer/parseInt to parse a string to an integer.

Both static type checking and a strong type system help to uncover bugs as early as possible, usually at the expense of making programs more verbose, but they are different things.

Haskell does not have variables whose values "vary", so I avoid using the term here. ↩