4 ms·
> If it grows to a bigger team or high load? Problems Then that's when you should definitely start looking to specific solutions to specific problems. Are you
by midrus 6y ago
> If it grows to a bigger team or high load? Problems
Then that's when you should definitely start looking to specific solutions to specific problems.
Are you having scaling/performance issues? Look into kubernetes.
Are you having problems with "too many cooks in the kitchen"? Start looking splitting things to separate services.
Are you having problems hiring "full stack" people than can work on both ruby and frontend? Then start thinking about an SPA.
That's the power of Rails.... you can get really, really far with it... when your business is a total success and you have steady income, then start looking into the specifics.
Starting from the get go with an SPA, kubernetes, microservices, monorepos, etc is, in my opinion, a recipe for failure.
(not that you have said that of course, just something I see too much around and I just take every opportunity to rant against it )
- treis 6y agoThis post is kind of acknowledging the problem but thinking it's ok. Like the story of people adjusting to a broken stair or not using a broken toilet in a house. Yeah, those are solutions and work around but really they are "solutions" and work arounds that you shouldn't have to do. Like the whole idea of use Rails until you become a big success and then rewrite it all is kind of crazy. Your dichotomy of Rails vs a bunch of complicated stuff aren't the only options. We can have something like Rails minus a bunch of magic in a performant language. Maybe it's a little bit less productive at the beginning, but you're not hating life in 18 months when your team reaches 15 developers or you've got to scale.
- tra3 6y agoOut of curiosity, if not rails than what would you recommend?
- treis 6y agoI think Go is the closest. It's missing a consensus batteries included framework. At least, the last time I looked. But everything you need is there even if you gotta get it from multiple places. It will take longer to get started but what you end up with will be way better. Java/Spring's magic is just as bad with annotations and XML, but you do get better performance and types. It'd be my second choice.
- midrus 6y agoIt is not abour rewriting. It is about extracting functionality into separate services or projects as the TEAMS/PEOPLE grow so that they not step on each other. > We can have something like Rails minus a bunch of magic Examples? Because I'd be very interesting in this. Also, in the world of web development, the magic Rails does is pretty necessary. If you're not using its magic, you're probably going to write it yourself. It just won't look as magic to yourself because you wrote it, but it will to others joining later. Except they won't have as good documentation, community, etc.
- treis 6y agoI'm talking about stuff like passing instance variables from controllers to views, method_missing, monkey patching, use of send, and meta programming. This magic makes code pretty and allows a lot of stuff to just work. But when you have to debug or update code that someone else wrote it makes it really difficult to see what's going on. As an example, if you what to refactor a method it's impossible to be 100% confident that you've found all the places it's used. That makes it very hard to be productive as the team size grows or when you're working in legacy code bases.