You Want Modules, Not Microservices

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • rupy

    HTTP App. Server and JSON DB - Shared Parallel (Atomic) & Distributed

    I think we're all confused over the definition. Also one might understand what all the proponents are talking about better if they think about this more as a process and not some technological solution:

    https://github.com/tinspin/rupy/wiki/Process

    All input I have is you want your code to run on many machines, in fact you want it to run the same on all machines you need to deliver and preferably more. Vertically and horizontally at the same time, so your services only call localhost but in many separate places.

    This in turn mandates a distributed database. And later you discover it has to be capable of async-to-async = no blocking ever anywhere in the whole solution.

    The way I do this is I hot-deploy my applications async. to all servers in the cluster, this is what a cluster node looks like in practice (the name next to Host: is the node): http://host.rupy.se if you click "api & metrics" you'll see the services.

    With this not only do you get scalability, but also redundancy and development is maintained at live coding levels.

  • DIStage

    Productivity-oriented collection of lightweight fancy stuff for Scala toolchain

    Right.

    We delivered many talks on that subject and implemented an ultimate tool for that: https://github.com/7mind/izumi (the links to the talks are in the readme).

    The library is for Scala, though all the principles may be reused in virtually any environment.

    One of the notable mainstream (but dated) approaches is OSGi.

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  • ripgrep

    ripgrep recursively searches directories for a regex pattern while respecting your gitignore

    I'm unsure how to "sell" this idea. I don't want to force my view on others until I truly understand the problem that they're trying to solve with modules/microservices.

    For searching multiple files, ripgrep works really well in neovim :)

    [1] https://github.com/BurntSushi/ripgrep

  • TypeScript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

    Counter point - https://github.com/microsoft/TypeScript/blob/main/src/compil... - your task is to just make it a little bit faster. Where do you begin with a 2.65mb source file?

    It’s easy to miss the point of what the OP is saying here and get distracted by the fact this file is ridiculously huge. This file used to be a paltry 1k file, a 10k file, a 20k SLOC file… but it is where it is today because of the OP suggested approach.

  • esbuild

    An extremely fast bundler for the web

    Where do you begin if the code was in hundreds of separate modules? It's not clear if it's easier. You would take time to load the code into your brain regardless of the structure.

    By the way, JavaScript parser in esbuild is a 16 thousand lines of code module too:

    https://github.com/evanw/esbuild/blob/0db0b46399de81fb29f6fc...

  • backstage

    Backstage is an open platform for building developer portals

    Are there similar tools for modules like microservices for observability, discoverability and documentation? I'm thinking something like Backstage [1] that was featured on HN lately but for modules.

    [1]: https://backstage.io/

  • aperture

    Rate limiting, caching, and request prioritization for modern workloads

    While we are on the topic, I would like to point out that the decoupled nature of microservices is governed by queuing theory. Microservices are especially susceptible to positive feedback loops and cascading failures.

    Going back to systems thinking, flow control (concurrency and rate limiting) and API scheduling (weighted fair queuing) are needed to make these architectures work at any scale. Open source project like Aperture[0] can help tackle some these issues.

    [0] https://github.com/fluxninja/aperture

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • umbrella-corp-boilerplate

    A boilerplate monorepo for a conglomerate type business.

    Hey, we have a system like that at my company. Microservices are self contained and responsible for exposing their interface via SDKs created with a tRPC like library. Jump to definition works across the entire monorepo like a charm. Could you take a look and give me any feedback? https://github.com/rectech-holdings/umbrella-corp-boilerplat...

  • Hey, we have a system like that at my company. Microservices are self contained and responsible for exposing their interface via SDKs created with a tRPC like library. Jump to definition works across the entire monorepo like a charm. Could you take a look and give me any feedback? https://github.com/rectech-holdings/umbrella-corp-boilerplat...

  • lib-courier-js

    Messaging mediator library and minimalist framework for Node.js

    I made a framework along those lines for work which we used for many years to mediate ~1000 namespaced commands across dozens of repos. Whether it ran distributed or bundled (I called it "mega-service" mode) was completely controlled by config. We mostly used ZMQ for inter-service messaging, but I had implemented http, redis pub/sub, grpc, etc at various times to prove the concept.

    > https://github.com/NathanRSmith/lib-courier-js

    Interestingly, we're pursuing a monorepo & multi-monolith setup for the next version of our platform. So lib-courier is no longer necessary to stitch it all together. It was fun while it lasted though. Once you understood the routing algo & code patterns, lots of stuff "just worked".

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts