Ask HN: Would you use a Low-effort Microservice Builder?

1 points by jarirajari 2y ago ↗ HN

I am currently building a low-effort microservice builder. I am interested to know if you share the described problem. Also please comment if you find the solution to solve the problem. Thanks!

Promise an easy and fast way of building and deploying a microservice

Problem microservice development is a lot of work: for instance, you need to provision your infrastructure, manage secrets, configure access control, configure network, design and configure your system components, develop your app with public api, business logic, and data persistence, and also pay bills. And repeat this for every new project...

Solution start with something less complex: something that is easy and fast to develop and test, and convenient to deploy. Something that you can later switch to a full-fledged implementation, when you actually know what you need to implement.

My builder technology enables...

development build: build microservices using high-level programming abstractions and browser-based ui test: consistent testing using exactly same code but different configuration values (in profiles) deploy: one-click deployments to private or public cloud

layers api layer: spec-first API development (openapi v3 spec) logic layer: write your logic using high-level functions (DSL) data layer: data connections and (JSON) objects are accessible via name. There is no internal data persistence, but supports many types of external data sources (with authentication)

code loops: supported variables: supported conditions: supported

What do you think?

verdverm 2y ago ↗

I think a lot of people have tried to "low code" this problem. The issue is that everyone has their preferred tech stack and low-code typically only has one choice. Using a DSL for logic (conditionals in yaml strings), or a bespoke language (like DarkLang or WaspLang), is a difficult sell. Developers want to use their language of choice with real programming constructs.

The most interesting approach, the sort of holy grail if you will, is to write your code as a single application, and then the system figures out how to distribute it if/when needed. ServiceWeaver is this concept in Go

https://serviceweaver.dev/

Reddit "critiquing" ServiceWeaver: https://www.reddit.com/r/programming/comments/1962avu/a_goog...

matijash 2y ago ↗

Wasp (https://github.com/wasp-lang/wasp) has actually worked out quite well! It just crossed 10k stars on GitHub and is currently the fastest-growing full-stack framework for React & Node.js. It's being used in both startups and enterprises.

Although Wasp has its own DSL/compiler, the secret to its adoption is probably that it works with the existing stack, like React & Node.js. From the developer's perspective, it feels like a framework; the "compiler" part is just what gives it its superpowers.

verdverm 2y ago ↗

You work for Wasp, so we'll take it with a grain of salt.

I have never seen Wasp used in the wild, because of the aforementioned limitations

- bespoke language

- stack chosen for you

What Wasp provides would be better addressed as a library.

Also, NextJS is the fastest growing, fullstack framework for React, largely because of the superior DX

---

an example of where Wasp has bad DX / DSL edge cases

> {=psl psl=} tags for database schema

You're weaving multiple DSLs together, which compounds the problem.

https://wasp-lang.dev/docs/tutorial/entities