JavaScript for Line of Business Applications

Writing an API client in JavaScript is a lot of work, you have to write one for Node.js and one for the browser. I found out a way to have both on the same codebase with the same API, all that with only changes to the build scripts. It’s called isomorphic code, and doing it with modern TypeScript isn’t easy, but it’s achievable.

TypeScript brings lots of advantages to the JavaScript world with almost mandatory typings. But TypeScript code is transpiled, and to play well with other libraries that aren’t originally written in TypeScript needs manually written type definition and some hacks to play well with other external tools, like code coverage and test frameworks.

In this third post, I’ll show the inner workings of the little helper library that I wrote to build fluent asynchronous APIs. As you’ll see, it’s not simple, but analyzing it does, I hope, give interesting insights about asynchronous programming.

Ariya Hidayat discusses principles for designing JavaScript APIs by observing the interactions between modules, particularly the influence of an interface on the code patterns.

Developing web applications today is quite easy, you will find always a framework/library that does most of the work for you. 

Some month ago, I heard about Apigility and lately I have been playing a little with it. So what’s Apigility?: Apigility is an API Builder, designed to simplify creating and maintaining useful, easy to consume, and well structured APIs. 

For this tutorial I’m going to show you how to create a Todo-Api, using Apigility on the backend and Ember.js on the front end. 

A few tips and libraries for creating and documenting RESTful APIs with Express.js.

These days I spend more time using Express for APIs that send nothing but JSON. In this post I’ll cover a few libraries and reminders to help keep your code organized and your API friendly for developers.

I’m assuming an API backed by MongoDB, and that we’re using Mongoose. Covering the basics of Mongoose is beyond the scope of this article, but I want to highlight a few lesser-known bits.

Intercooler is a Partial View Controller framework that allows you to add AJAX to your application with declarative HTML5-style bindings and REST-ful URLs, giving web applications a richer UX with a minimum of code.

Rather than expecting JSON responses it expects fragments of HTML (i.e. Partial Views), which are then loaded into the DOM directly.

* Scaleable

* Declarative

* Automatic Dependency Detection

* Framework Agnostic

* Bootstrap Friendly

* Open

API’s are often a pain to build. There’s all kinds of moving pieces: routing, data parsing, serialization, database interactions, etc. For years I’ve struggled with writing web API’s in Node.js – there’s just so much complexity required in an API boilerplate. That’s why I wrote Simple API. Simple API is an incredibly easy to use module for writing web-based APIs in Node.js

I often hear people say that they’ve written a library that makes something “simple”, but in reality they’ve just made it a different kind of complex. In this article, I hope to prove that’s not the case with Simple API. This tutorial is going to teach you to write an API for a ToDo list, where the entire project is less than 300 lines of code. That’s the entire project – the API related files are less than 200 lines of code.

Personally, I don’t actually care all that much about the whole promises/callbacks/coroutines/generators debate. It’s provably trivial to turn any callback-taking API into a promise-returning API or generator-yielding API or vice-versa.

I’m of the opinion that breaking functionality into small enough chunks that your boilerplate doesn’t matter is much more important than which boilerplate you decide tastes the yummiest. In JavaScript, we have first-class language support for passing functions around, so I tend to use callbacks, simply because it requires no extra “stuff”.

What’s important to me is that an API be useful, performant, and easy to reason about. When I’m writing JavaScript, I care a lot about how V8 is going to optimize it, and so try to choose patterns that it can optimize nicely. As of today, generators just aren’t first-class enough, and Promises require an extra abstraction. That may change someday, but these principles probably will not.