This post outlines the use of Google’s diff-match-patch library to generate patches that can be translated to operations against an AutoMerge.Text CRDT for situations when deriving the operations directly from user interactions is cumbersome.
Continue reading Integrating Google diff-match-patch with AutoMerge.Text
Category: Javascript
Uploading files to MongoDB GridFS via Apollo powered GraphQL API
GraphQL multi-part request spec outlines a specification for multipart form requests in GraphQL. Jayden Seric, the author of the spec, has also authored two libraries apollo-upload-client and apollo-upload-server which makes it effortless to integrate file uploads in Apollo Server.
GridFS is a simple file system abstraction on top of MongoDB. This facilitates storage of large files (beyond BSON document size limit) in mongo database.
This post outlines the minimal integration required to save the files uploaded through the GraphQL API to GridFS.
Continue reading Uploading files to MongoDB GridFS via Apollo powered GraphQL API
Integrating Next.js, Apollo Server and Koa
It is fairly straightforward to add a GraphQL API powered by Apollo Server to a Next.js application through a koa middleware.
The abbreviated snippet below summarizes the setup along with the libraries involved:
Javascript Async/Await with arbitrary Thenables
Usage of C# inspired async/await syntax (Now a stage 4 proposal) is now fairly mainstream in javascript, and native support is available in major browsers and Node.
Most of the times we await on promises (typically returned from async functions), however, it is relatively less well known that await works on arbitrary thenables. By thenables we mean any object with a then function member.
This post covers this usage, and explores some scenarios where it can be interesting.
Continue reading Javascript Async/Await with arbitrary Thenables
Typescript and validations at runtime boundaries
Typescript team has explicitly stated that they don’t intend to extend typescript’s static type checking to the runtime.
Typescript Design Goals lists the following in the section on Non-goals:
Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.
While on one hand this design goal is advantageous in that the output generated by typescript is very close to what hand written javascript would have looked like. And the runtime cost of typescript remains close to zero, therefore adoption of typescript does not alter performance characteristics of an application.
However, this also implies that for cases when static typing cannot help us we need to separately write validators using a validation library (eg. Joi) which has to be kept in sync with the typescript types.
This post outlines an approach to eliminate this redundancy using the io-ts library by Giulio Canti. This approach has also been adopted by some other libraries like MobX State Tree and Runtypes.
Continue reading Typescript and validations at runtime boundaries
An answer to “React is the new Java”
While it is disheartening to see technologically superior software be ignored by industry in favor of lacklustre ones, is the same true for React as well ?
Decoupling your frontend development with gulp and http-proxy
In past developers have often relied on backend-specific toolchains for web application frontends. Some examples would be Rails asset pipeline or the legacy ant based toolchain for YUI. However recently node.js based tooling support for frontend technologies has significantly evolved and it is quite viable to use a node.js based toolchain for managing your frontend projects, even if the backend is not node.js, thus keeping the workflow decoupled from the backend.
Sharing Jade templates between Node.js server and client
One of the biggest promises of Node.js is code re-use across client and server – this post focusses on reusing server side templates on client as well for dynamic rendering.