Build and deploy Javascript modules efficiently to serverless clouds, in a pure functional and composable way. I love . I’ve re-discovered through it, and I’m never going back. I also love . It makes writing server applications so simple, and its -based middleware stack approach makes extending and composing applications easy and fun. , combined with frameworks like Express, is great for microservices. Thanks to its lightweight character, non-blocking nature, and quick development experience, it beats (imho) other microservice technologies such as Spring Boot. Couple it with Docker and the sky’s the limit (…as long as you allocate enough resources to your container cluster, that is). Node.js Javascript Express Connect Node.js Smaller than small First they gave us , so we built .Then they gave us , so we built . Servers Service-Oriented Architectures Containers Microservices Now they give us , so we’ll build . Event Handlers Cloud Functions As we made our hosting platforms more amenable to deploying smaller units, so have our applications broken down into smaller software packages. There are many reasons for this, and there are diverging opinions on whether it’s a good thing. But if we look back at the original concepts behind cloud computing, there was a dream of having code distributed infinitely in a network of connected computation nodes. And we’re getting a little closer with the emergence of serverless platforms. But not too small We cannot go too small because we have blocks (procedures) that consist of sequences of computational steps that require shared memory in order to execute effieciently. Then we wrap those around a function definition, that defines a contract for its input and output, which allows it to be composed with other such functions. This approach has been very successful in the architecture of , and is one of the reasons for its longevity and ubiquity. I don’t mean to suggest that Web applications should follow a comparable cloud-based shared eco-system (although are trying), but I do believe that we could benefit from applying similar principles when building Web applications. Unix some Beyond function definitions, we also group closely related functions in modules. An example would be the CRUD operations for data within a given domain (e.g. user management). Those tend to share code, such as common object models, parsing logic, formatting, etc. So if were to deploy individual functions in serverless environments, we’d end up with a bunch of duplicated code. But let’s assume we don’t mind duplicated code deployments. After all, we can still manage it properly in our code repositories. We might still want to share temporary resources, though, such as database connections. We might also want to make sure that all operations for the same domain are deployed and managed as a single unit. It fits well with the : Single Responsibility Principle Gather together those things that change for the same reason, and separate those things that change for different reasons. Going Serverless So, Node.js is great for Microservices. And it’s also great for writing smaller function modules. And Express is great for building Web application in Node.js. However, most of these serverless environments (AWS Lambda, Google Cloud Functions, etc) already provide a lot of facilities out of the box to handle the common functions of a Web server. And for these , which should not have more than a handful of functions, we really shouldn’t be bothered with the overhead of complex Web server logic. We should certainly leverage HTTP, as it is the ubiquitous transport mechanism for transfering messages between Web services, but we should do it in a more way. Nanoservices RPC kind of This where most current frameworks offer too big of a tool for the small footprint that we’re looking for. If anything, I’d argue that going serverless should allow us to free ourselves from , and focus instead on building functions. There is, however, still a need for basic routing within a in order to map incoming request to the appropriate handler function. Also, because of the proprietary nature of these commercial serverless environments, there is a case to be made for a certain level of abstraction, so that our functions can be decoupled from the specifics of the platform they’re executed in. frameworks purer Nanoservice I think that more applications will surface soon that are focused on enabling functional programming applied to serverless deployments, which I’m very hopeful about because it feels like a step in the right direction. Certainly there are many real-world considerations still to be addressed, such as latency, performance, memory usage, etc. But just like with Microservices, I believe that we’ll find the right set of tools and practices to make this, not just practical, but also highly performant on real-world applications. Modular Functions I wrote a small package to address these needs when I started deploying serverless applications: . modofun It carries no additional dependencies, because we want our deployments to be as small as possible, and it’s limited to about 100 lines of code. It aims to add just enough (and not any more) functionality to make it easier to deploy function modules on serverless platforms, with the added benefit of leveraging existing middleware built for existing frameworks like Express. Here are a few of its features: Basic routing to functions Parameter parsing Automatic HTTP response building Support for ES6 Promises (or any other then-able) Connect/Express-like middleware support Google Cloud Functions (with AWS API Gateway events) AWS Lambda Automatic error handling It makes it easy to expose an existing module as Serverless cloud functions: An simplistic router maps incoming requests to functions, and passes the additional components of the URL path as function arguments. Additional request data is also available as context (this) for the function invocation. intentionally When applying modofun to a function module, you can also re-use existing middleware components to be executed everytime, or only for certain functions (more details in the ). It then returns a handler for events generated by the serverless platform (currently supports AWS and Google Cloud). documentation Get it with : npm npm install modofun You can find more examples and detailed documentation in the official website: . You can also find the full source code on GitHub: . https://modofun.js.org https://github.com/modofunjs/modofun There’s also a that includes exposing , using the alternative Express-like request/response mode, and . All using , combined with and other cool technology. real-world example a GraphQL endpoint a Google Cloud Functions deployment an AWS Lambda deployment modofun Babel
