Rise of the "Microlith": Rethinking Microservices for Modern Developers

Hey dev.to community!

We're excited to announce that after two years of development, our project napi is going open-source! We've been building something that we believe will fundamentally change how developers approach building and deploying applications. Here's a quick dive into what we're doing, why we're doing it, and how you can be a part of it from day one.

TL;DR

• 🛠️ We're building to help companies reduce early technical trade-off, and late refactoring efforts, by offering a new way of writing large API codebases.
• 🚀 Initial focus on NodeJS ecosystem, but quickly expanding outward to PHP, Java, and more.
• 👉 Star the project on GitHub to follow along with our progress.

A New Approach to Development: Build Monoliths, Deploy Microservices

The traditional struggle between monolithic architectures and microservices is one every developer knows. With our project, we aim to bridge the gap by providing developers a seamless way to write monolithic applications that can be deployed as microservices. Because of this, we have coined the term "Microlith" This approach brings the best of both worlds — allowing you to work faster in development while benefiting from the flexibility and scalability of microservices in production. This method means no more early architectural compromises; it's all about flexibility and making what you've already built even better.

Starting with Node.js, Expanding Quickly

Our initial focus is the Node.js ecosystem. You may say: "but Joel, the companies that really need to refactor are all in Java" and you would be 100% correct. JS/TS is simply the best place to start until we get community feedback on which languages are most important to you.

Our roadmap is focused on expansion into PHP, Python, C#, Java, and more. If there is a specific language you want to see first, please star us and contribute!

We have some additional features planned on the roadmap as well:

• Auto-detect "dead" API endpoints that no longer see traffic.
• Automatic flagging of bottlenecks within your APIs.
• Codebase metrics for understanding legacy systems faster.
• System-level interaction mapping between multiple services.
• And much more!

Open Tooling for Devs, with Enterprise-level features for Architects and CTOs

We're committed to supporting developers with free, powerful tools while offering additional paid features tailored to solution architects and enterprise environments. By combining an open-core model with additional enterprise-ready features, we can maintain an ecosystem that's both accessible to individual developers and robust for larger organizations with more complex needs.

Going Fair-Source: Why Now?

We've spent two years fine-tuning this project, including gathering valuable feedback and honing in on exactly what developers need most. Based on this feedback we learned that developers really don't want a black-box auto-refactoring tool that works on their code without seeing how it works. (Fair warning to you, AI-based refactoring companies!)

Because of this, the time felt right to open up our code, share our work with the community, and let developers see what we're building. By going open-source, we're creating an ecosystem where everyone can contribute, improve, and shape this project to make it the best it can be.

A Bit About Us & Our Journey

Our team is driven by a vision to improve developer workflows and make large-scale application management easier for everyone. We're a fast-growing and multinational team of 3 going on 4.

• 🇺🇸 Joel is an American abroad; he's worked as a SWE in both enterprises and startups and seen all the technical debt companies struggle with around their APIs.
• 🏳️ Florian is our resident Frenchman. With a background in mechanical engineering, his switch to software brings unique insights into our approach.
• 🇳🇱 Justus is our business guy. Always direct, he keeps us on track by being our "Dutch Uncle".

We plan to continue expanding as we gain traction, and plan to start looking to fill DevRel, DevExp, and other roles in the very near future. If you think this could be you, the best way to get our attention is to join the community and interact with us.

Join Us and Follow Along!

⭐ Star the project on GitHub

Justus Goes Bald

We really want to build a strong community of developers and an amazing project, but Justus:

^ This guy. Doesn't believe we can get developers on board with our project. To prove it, he made a bet with the rest of the team: if NanoAPI gets 1,000 stars on Github in the first week of the project, he will shave his hair off and donate it to charity.

What do you think? Can we make him go bald? 👨🏻‍🦲

Give us a star to make it happen! → ⭐

Comments

[Doug Wilson]

I'm interested, but I didn't get nearly enough detail on "microliths" or how napi can "bridge the gap by providing developers a seamless way to write monolithic applications that can be deployed as microservices" from the article or a visit to the repo.

How can a "Powerful CLI + UI for inspecting and refactoring an API codebase in any language and web framework" help developers create monoliths and deploy them as microservices?

What am I missing?

[Joel Milligan]

We're working on providing more information through future blog posts. It's a technical topic that we understand requires much more explanation and deep dives, so we're trying to balance short-form content with longer posts.

We have another post we've made here: medium.com/@joel_40950/automating-...

We also have a youtube channel where we will be discussing all of the important topics in-depth. For now it just has a simple demo: NanoAPI 2-minute demo

To actually answer your question, we are building this tooling so any developer can take the following steps:

1. Run the UI to get a logical overview of their API codebases. This is to help with the next step.
2. Group endpoints into microservices, or allow them to be deployed independently as serverless functions. Once the endpoints have been grouped, then it is possible to create builds.
3. Builds are exactly as they sound. Similar to how Typescript transpiles to javascript, or Kotlin into Java, the NanoAPI cli will then take your code and slice it up based on your grouping. It does this without ever mutating the functionality, so you can be certain the output will 100% match the input code.
4. These output codebases can then be containerized and deployed in whichever way you prefer. We plan to offer additional functionality in the future for plugging directly into CI pipelines.

Hope this has clarified it further. Happy to answer any additional questions you have.

[Sourabh Singh]

didn't microservices were used for making it easier to develop different aspects of the projects simultaneously with less complexity and making it flexible for each team to work with the tech stack they want. Then how is this "build monolith & deploy microservices" going to help.

[Joel Milligan]

That's one possible use of them, yes. In that case where multiple languages will be used, this solution isn't the best.

However we see that there is a specific case that nearly every company experiences with monoliths that is yet to be addressed by any specific solution. As companies grow, they tend to develop monolithic codebases for ease and speed of development. Only once they reach a certain size of users does it become clear to these companies that their software will not scale well using this approach.

At this time, companies tend to begin refactoring efforts from the monolith to multiple microservices. This process can take many months or years to complete. Larger organizations tend to solve this by bringing consultants in and throwing money at the problem.

With NanoAPI there are now two possible other approaches:

1. Use our tool once to logically split the monolith into microservices, and then replace each microservice over time with a better version.
2. Continue with their monolith and split their code in the way that allows it to best scale.

Will it be a silver bullet for every company? No. But it does provide a new paradigm beyond the original three options: monolith, monorepo microservices, and multi-repo microservices. Since it is a blending of monolithic and microservices practices, we've chosen the name "microlithic development".

[Neurabot]

Right. Interesting topic. I will star you. Sure.

[Dan Silcox]

I like the concept, trying to get best of both worlds - have starred repo and will be interested to see how this progresses!

[Joel Milligan]

Thanks so much for your support Dan!

If you're interested in staying up to date with our progress beyond our posts on dev.to, we also have a youtube channel and a discord.

[FOLASAYO SAMUEL OLAYEMI]

This is fantastic! 👏

As a developer, the concept of building monoliths with the flexibility of deploying them as microservices is a total game-changer.

This approach really feels like it’s solving the pain points we face between development speed and scalable deployment—excited to see where this is going!

I’m thrilled we are spreading the word about this innovative direction. The roadmap looks solid; especially love the future auto-detect and bottleneck flagging features—practical tools that can make developers’ lives a lot easier.

Also, challenge accepted! Let’s get Justus that 1,000-star haircut @nanojoel 😄

[Joel Milligan]

33 down, 967 left to go! 😎

[FOLASAYO SAMUEL OLAYEMI]

Nice!
Only 967 more stars until we see the legendary bald Justus! 👨🏻‍🦲

At this rate, we’ll be there in no time!
Let’s keep the momentum rolling—every star brings us closer to greatness (and a charitable haircut)! 🌟