Comment by ivan_gammel | Hacker News Reader

Comment by ivan_gammel | Hacker News Reader

This is a noble idea that unfortunately will not work. As a CTO of another small startup, I have no incentive to reuse those services for a number of reasons:

1. Trust. I need a strong vendor or community behind third party code which will issue security updates, have transparent roadmap that I understand and agree with and good paid licensing and support business model. It’s a high bar, but having some control over supply chain is important.

2. Architecture. Domain-specific services that integrate with some APIs are middleware: either I have to build some other middleware to integrate them with loose coupling, or I have to accept their integration contracts as a basis for my solution architecture. Both don’t look good to me.

3. Cost. If the problem is generic enough, why I should take only the code but spend money on DevOps to deploy it? No-code SaaS today is great and it’s all-in-one, being cost-efficient simply because it eliminates expensive internal maintenance effort. And it’s commodity today, there are often many alternatives for some problems, so vendor lock-in isn’t as scary as it was before.

I value your points because they are the same concerns I would have being a CTO of a company. Ultimately vendors don't yet care enough about this problem to invest in it and I think ultimately that's a mistake because while we have standardisation at the Cloud infrastructure layer, we're missing everything above it. The cost of development to an organisation in these services is quite frankly astronomical. You've got hundreds of devs rewriting identical CRUD services or proxy shims to existing SaaS across the entire industry. That's millions in capex just being burned.

In relation to being a CTO of a small startup, yea OSS maintainer risk is tough. You want to use projects that are used by hundreds of companies and actively maintained. In my case, I am the primary maintainer and it's used for a cloud service called M3O - https://m3o.com. I think it will take a while before we're in a place to warrant more buy in but my hope is eventually it'll get there or at the very least people will come to use the APIs serviced by M3O.

On architecture, I mean you're quite literally talking about software "build vs buy" tradeoffs for the entirety of all software you ever write. In this case, do I integrate something else or write it myself. I think that comes down to the same assessment of whether you should offload to some other piece of software versus your own. When it comes to domain specific services this is always tough yet we see the adoption of the likes of Twilio for SMS, Sendgrid for Email and Stripe for Payments so I'd argue we're getting closer to blurring the lines now.

On cost, you can use the hosted offering - https://m3o.com - but at this point the reason I'm sharing the open source services is really because I think that adoption curve to a cloud service takes a lot longer especially with domain specific services. I would argue these services while on the surface appear a commodity, the development time and integration cost of using bespoke independent APIs or services has a much higher cost. Everyone internally ends up writing proxy/shims to SaaS products to try eliminate this risk for themselves. I just think we should standardise a lot of our business logic service consumption.

A not-so-tiny nitpick: All of the code examples on m3o.com for DB access are a recipe for command injection. They all use a string with "columname == literal" format. That's near the top of all top-10 security don'ts lists..

Yea we are aware, there's a lexer/parser but ideally we should have some Query op and use prepared statements. I am probably looking for some additional help on that front in the near future.

Can you point us to the areas that you are looking for help on? If you save us work on looking for them and you might get a PR for your trouble.

Hey, I have a non-comprehensive list of issues for new services https://github.com/micro/services/issues but most of the bugs/features are still in my head for other stuff. I think purely on the DB front we need to add a new Query endpoint that's more powerful that will accept a repeated array for Filter options that look like the below.

message QueryRequest { repeated Filter filters = 1; }

message QueryResponse { repeated Record records = 1; }

message Filter { string field = 1; string op = 2; string value = 3; }

Something like that. I think otherwise a majority of issues really become clear through use, so those using the services tend to see where the pitfalls are or where they can contribute. It's harder to do that without context and arguably less enjoyable for the person contributing as they're not seeing that change in whatever they're doing.

Why not just use PostgREST for DB?

Just a desire to define an abstraction that's going to be consistent across all the services built. The value of a services catalog isn't just many separate services but the consistency and ability to reuse many in a coordinated fashion.

Why would I use this instead of just using e.g. a postgres jdbc driver? How would I use this? A query compiler library (or service)? How do you do a join? Group by? CTEs? Window functions? Transactions? Bulk inserts/updates? Index and constraint management? Temporary tables? Why does the read endpoint have a hard limit?

You know what though, I think we came a long way. We used to have to DIY our builds, custom Makefiles, custom CI/CD, VCS... Look at how much you can reuse today if you're on AWS for example, using tf and cdk.

Do you mean like 25 years ago? I've never had to do any of this. I did it, sure - but only because I wanted to, not because I had to.

Reply on news.ycombinator.com