Monorepo Support
render.com
Monorepo Support
1–10 of 59 posts
Re: Monorepo Support
#2This is great! I’ve been using Render to host all my projects ranging from static sites to full blown web apps ever since moving away from Heroku. Their free tier is also pretty good for prototyping.
Recommend it to anyone moving away from Heroku or looking for a cheap place to start.
Re: Monorepo Support
#3Hey folks. I do devrel here at Render and it's nice to see this floating by on Hacker News--our new monorepo support does a lot to improve the ergonomics of running multiple services out of a single repo.
One note: in Render parlance, "services" includes static websites, so even for systems that wouldn't always be considered a monorepo in other contexts, this is useful to launch a static website alongside your code and, in so doing, more clearly communicate what you're doing to the next person to touch it. (Including six-months-from-now you.)
Re: Monorepo Support
#4No post body was provided.
Re: Monorepo Support
#5Render is one of those companies you don't see a lot on HN, but you talk to developers who use it and they have a lot of love for it. Stuff just works like you'd expect it to. We've been a happy user of monorepo support since it was in beta and it's worked great for us.
Re: Monorepo Support
#6I don't get the case against monorepos, and why it's so polarizing.
You can share code without having to stand up infrastructure to host packages and whatnot.
You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services).
You can still deploy to separate targets, a code repository is not 1:1 with a deploy target, that is a fake constraint that never even existed.
Manyrepos ALWAYS end up being second class citizens. Test setup isn't as good as in the monorepo because that means duplicating it N times, and that is obviously wrong.
Common patterns are The Same But Different everywhere and/or there is crazy complexity in sharing code between repositories to alleviate this (often having its own problems)
It's just... all of that goes away with one/fewer code repositories. So... why? I'm not even anti micro-service, monorepo actually makes MORE sense with microservices IMO. Why do we do this?
Before someone points it out, I do recognize that a monorepo can still be poorly architected. We can all rest assured knowing that poor architecture is poor architecture whether it be monorepo, manyrepo, monolithic, microservice, PHP, Rust, blah blah.
Re: Monorepo Support
#7I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…
To make people feel dumb or smart
Re: Monorepo Support
#8Render is one of those companies you don't see a lot on HN, but you talk to developers who use it and they have a lot of love for it. Stuff just works like you'd expect it to. We've been a happy user of monorepo support since it was in beta and it's worked great for us.
I disagree, any post about Heroku or any of the startups aiming to replace it (Fly or Railway for example) always mention it. From the perspective of someone looking to move to one of them from Heroku:
- Render is closest to what Heroku do, however being on their own hardware they can undercut Heroku who, by running on top of AWS, are both limited but apparently also don’t want to compete on price.
- Fly is both aiming to be a Heroku alternative but also have a really compelling use case of placing many smaller VMs closer to your customers. I believe they are heading towards a target of scale to zero on distributed VM regions for your app. They have some super clever ideas around distributed DB read replicas.
- Railway I think is somewhere in the middle, but I can’t understand their pricing… they say “you only pay for what you use” and the pricing page imply a that you can use fractional resources. It seems confusing as to if they have some sort of auto scale to zero or not. The docs are lacking on in the regard.
For me Fly I think are winning. Probably with Supabase or or Crunchy Data for the DB.
Re: Monorepo Support
#9I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…
In most organizations the gravitational pull of Conway's Law is so overpowering it forces every team to have at least one repo.
Re: Monorepo Support
#10I don't get the case against monorepos, and why it's so polarizing. You can share code without having to stand up infrastructure to host packages and whatnot. You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services). You can still…
My own experience is that most of the times people view this subject as a matter of personal preference. They do not see this as a technical choice that may (or not) solve problems or help reach particular goals. Thus, when discussing this subject from a logical/engineering perspective, laying down pros/cons arguments, the other party may take it personally.