I am a Senior Software Architect, Ask Me Anything!

uyouthe profile image Miloslav Voloskov ・1 min read
  • How do I use React and Redux without losing my mind?
  • Why use Immutable JS?
  • Is database X better than database Y?
  • If NoSQL is so fast, why does someone still use SQL?
  • What language to learn?
  • What framework to learn?
  • Why does my CSS always break?
  • ...

Just ask. We'll come up with something together.


markdown guide

Should I use Ruby on Rails over Express.js or Laravel for my web app?


Ruby on Rails.

  • Rails is the most conventional
  • Rails is the most mature out of the frameworks listed
  • Rails has a back catalogue of so many video tutorials and documentation online
  • Ruby community encourages strong convention and good programming practices
  • Rails is the origin of all modern frameworks
  • Rails is a complete web-framework

There is this misconception that Rails is old but in Toronto, 60% of startups are still using Rails. Rails 6 comes out sometime next month.

There is another misconception that Rails is hard or you'll read online that x framework is easier. So bootcamp grads learn express.js and then wonder why they can't get a job after graduation, learn less than you need to know is easier but will not produce the desired outcome.

Laravel I would say is the second best choice since its Rails-like. Laravel has this weird obsession overwriting middleware. I never understood this since Rails comes with all the middleware you would need so you never think about writing middleware. PHP tends to attract poorest quality developers. What you save in money running on dirt-cheap servers you'll lose more in time and QA.

ExpressJs is dead last unless we're talking about building some kind of toy app. micro-frameworks are good in the hands of experts for production since you have the ability to architect some cool components, though less experienced developers tend to roll some weird code. Trusting NodeJs packages is another thing. They have lots of packages but this is due to the langauge coming with next to nothing built in so we see an explosion of dependencies. Packages are so bad I have to use third party service to ensure there is nothing malcious when I put my NodeJs functions running on Lambda.


Wow, so much text!

Thank you for sharing your opinion! I can see you really like RoR :)

I think you underestimate PHP and NodeJS tho. PHP developers are really cheaper, PHP is really much more widespread across junior and middle developers, and if one knows PHP better and needs an MVP in two weeks, these are obvious reasons to stick to it.

RoR is really great tho, this is why I've given it compliments :)


Thanks for the detailed explanation and also the heads-up about Rails 6. I checked that it's scheduled for April 30. 🥳

Also, I've been reading posts claiming RoR is slow. I would love to get insights from someone who's actually worked with RoR and not just conducted some benchmark tests.

You seem to be experienced. Any comments on that, Andrew?

I use to run a B2C web-app with 500K users. I think 30-50K active per day during peak months ~100K active per day. I ran this all on a single server for ~$200 CAD per month where pages would load between 30-70ms with no caching layer and there was quite a bit interactivity on the web-app.

It doesn't make practical sense to drive a race car around town so when it comes to choosing optimal languages to build your web-app you wouldn't choose to write it in C++ (which by the way OkCupid actually did). Choosing your language based on speed in 2019 doesn't matter. If you need speed for specific components for your app, then write them in isolate, and then in your primary language ensure its the most productive for developer and business needs.

We saw an exitus of people leaving Rails around 2014 because of performance issues and I experienced this myself. Instead of moving to Go or Elixir like others I discovered my issue was the many abstractions and DSLs and simply stopped using them and better code.

I was looking at dev.to codebase today and I was flabbergasted by the number of abstractions, anti-patterns and DSLs for such a simple web-app. Looking at their codebase is one of the reasons I stopped doing full-stack development to be a Solution Architect. I'm just tired of dealing with such obvious messes.

Rails is fast enough, its developers over-organizing or mis-organizing their web-apps. If you read the DDH's blog (the creator of Rails) he himself doesn't use any abstractions that are considered "must use" by Rails developers.

David here on Dev.To makes a good point on this about using things you don't need: Why You Shouldn't Use A Web Framework

A common problem I've been encountering in Toronto with startups that have a python component because they are using Machine Learning and so they think it makes business sense to write their entire web-app in python. Though finding python full-stack developers is difficult and expensive because python developers want to be doing CompSci not tinkering with web-frameworks. It never dawns on them they could use Rails or Laravel but still use python.

This comment has got to be the best explanation on this topic, Andrew. Thanks a lot for spending the time to write this comment.

Means a lot to me. I owe you a coffee or beer whatever you prefer. 😁

I'm sold on Rails. Will be refactoring my Express app to Rails in the coming weeks. It's pretty small right now so porting shouldn't take too much of time.

Want to lay the foundation right. Thanks again, Andrew.

If you ever want some 1-on-1 time with via Zoom to do some Rails.


It may seem I'm Rails obsessed, but I just want to see the best outcome for people and will use whatever technology is the best fit.

Maybe you could tell me about the tech/startup scene in Bengaluru. Lots of people from India come to Toronto specifically to learn full-stack development at bootcamps or community college They keep saying they don't have the learning community and resources they have in India and its changed their life just coming to Canada to learn to code. I'm skeptical to believe that since I have no first hand knowledge and would love some perspective.

Thanks a lot for the Zoom call invite, Andrew. I've started learning Ruby and then will start with Rails.

Let me get a hang of this and then we can have a chat. 🙌🏻

It's not bad here. Bangalore is pretty active in tech if you work for startups. Formal education system lacks proper tech exposure, though.

More on this when we have the call. 😀


RoR, Express, and Laravel are entirely different beasts. If you're doing it for fun, just go ahead and use whatever you think will give you the most of experience. If this will be a commercial product, bear this in mind:

  • I don't think Laravel is stateless by default. You'll probably need to spend some time scaling this up
  • PHP developers are often cheaper than RoR or JS backend folks
  • PHP hosting solutions are cheaper than both RoR and Node
  • On the other hand, you'll probably need multiple servers and databases as you'll grow, you can't do this at some cheap PHP hosting. You will need a VPS
  • NodeJS has by far the largest tool palette
  • Ruby has outstanding metaprogramming features that will allow you to make the implementation really short and thus much less flawed and much more maintainable

If this will be an MVP or a really small commercial product that you have to launch now, I'd suggest you go for Laravel. If NPM already has some specific tool that you require but neither RoR or PHP have it, go for Express. For the long run and superior scalability, go for RoR.


The app that I'm building will be a blogging platform. It's currently at a nascent stage, made with Express but I was thinking of porting my existing backend to RoR because of the very aspects of RoR that you mentioned.

Thanks for the answer, Miloslav. 🙌🏻


I prefer lizards to be honest but still love both cats and dogs. They have totally distinct aesthetics in their behavior but both are totally beautiful.


What kind of lizards, and do you have any yourself?
This is my friend Apollo: Apollo

I don't know why but he (she?) looks so wise. What a wizard :)

No, I don't have any pets :)

She is not so wise... makes a regular habit of walking straight off the couch like she can levitate. Perhaps a wizard in a previous life?

Definitely :) remembers that she's wise but can't really remember why :D


Depending the project, would you go for a SPA (front end framework + stateless API) or a MPA? Which one scales the best for 1 000 vs 1 000 000 users?


It absolutely doesn't matter. All that matters is how fast your servers are.

If I'm building a content website, something conceptually similar to a newspaper, I'd go with server-side templating.

If I'm building an app, conceptually similar to a distinct device, I'd go with a SPA.


Any particular reason for not going SPA when building a content website?

Forget that the web exists.

Are you building a newspaper? Go for a website.

Are you building a separate device? Go for a SPA.

SPA is almost always more complex, just think about SSR, proper Open Graph, client-side routing. Why? Just why do you need this to create a digital newspaper? Just because that's how cool guys do it these days?

Think again.


How do I use React and Redux without losing my mind?

1) Why do you have a question like that?
2) Do really people lose their mind (figuratively speaking) with React and Redux?
3) Why are people so reluctant to move away from React to say Elm, or ReasonML (I think they are the best two candidates).


long story short, react and the whole facebook product palette is more focused on conceptual purity rather than real user needs. And I really don't feel like explaining so opinionated topics here (I'm sorry). If you want to discuss this, hit me on email: hello@miloslav.website


Explain to me like I'm a total newbie (almost true).

Why is graphql a better option, for a small/medium sized application, than simply sending the result of a SQL statement as json?


GraphQL makes sense for Github because they have a public API with user demand for data-structures in great variation in returned data.

If you're small or medium you are much better off not dealing with GraphQL at all because it's much easier to work and maintain queries than it is dealing with GraphQL.

If you're using something such as postgres they have amazing JSON functions so you directly return JSON straight from the database.

  1. Adjustability. If you have a very rich data model, for example, if one order of your e-shop must return the full thing when you need it and just order id and order date for the orders list.
  2. Multiple sources. For example, you may want to have Cassandra DB for analytics (cheap writes, expensive reads) and some SQL DB for everything else (cheap reads, expensive writes) and want to assemble this all to provide some unified API

Aside from that, GraphQL just reduces the amount of code you have to write, and less code means less bugs :)


How would you approach architecting a performance critical react/redux application? Ex: stock trading with multiple updates per second.
Is the immutable data structure that redux enforces still viable in this situation?
How do u make sure that UI is keeping up with the multiple state updates?


Nice question.

You pretty much can't achieve that kind of performance in immutable data structures without it being persistent. Something like ImmutableJS or MoriJS is absolutely necessary there.

If you don't need the time traveling here, I'd go with something mutable like MobX because it will obviously outperform any persistent stuff you can do in the browser.

Going even bigger, I suggest you choose a really fast backend and calculate everything there so all frontend has to do is just react to WebSocket message and just apply that data as is, without any changes. This is by far the fastest approach I'd personally use solving this task.


Are you a "all inclusive framework" or "micro architecture" kind? What do you think of both even if you have a preference?


This seems like a common question, glad you'd asked it.

I think there's no universal approach to solve all the problems. But when it comes to real-world applications, I stick to the following two approaches:

  1. Choose the right toolkit for the job. If there'll be many data manipulations, it's better to stick to lisps (Clojure or something like that) and stored SQL-queries. Then just create some broad architectural convention, for pretty much any web application MVC would fit, and just use your toolkit. This is "microarchitecture" kind of approach. Microarchitecture tends to be vulnerable to code smells here and there if your toolkit lacks the expressive power, and I prefer to solve it with rich data-manipulation tool palette such as Lisps. The downside here is that you're tied to the specific language and have very small tool options.

  2. Create a declarative DSL. Write an interpreter for it. Languages and tools don't matter anymore, but the whole thing obviously takes more time. Requires experience, I never did one without at least one failed prototype and rewriting the whole thing. It pays off tho – there's nothing that can beat maintainability and fault-tolerance of good DSL.


Thank you for taking the time to answer :)


Do you have an opinion on Dart or Flutter?

How do you decide whether to put in the time to learn a new language?

What aspects of a language are most important to you and why?


Dart and Flutter? Well, Dart is in SPDY protocol and Firebase league – another Google's attempt to take over the world. It obviously should be polished and probably is perfect, but I don't really feel like investing in anything Google built.

Flutter? Well, if there's a need to build a multiplatform mobile app in two weeks, it's a decent way to go.

New language? I just read about the ideas that'd been implemented there and the reasons behind this language existing. If this fits the project I'm building and will allow me to cut the amount of code (and thus the number of bugs) radically, I go for it.

Aspects? Just what I said above: I need my tools to allow me to implement the damn thing as short as possible. This is all that matter to me.

I think it's the wrong way to think like "I want to choose the one ultimate language to build anything, and it definitely should have static typing and this and that". Languages are different, just like the ideas behind them. Projects are different too.

Just make them meet.


Cool, thanks I agree. Different languages or frameworks work best for some scenarios.

A language like Java tried (and is still trying) to be useful for building the UI of a web application, but is better suited for the backend while other languages or frameworks work better for the UI.

So I don't think we have a language that fits all needs.


what would you say to your younger-self if you could talk to him ?

  1. Stop being afraid
  2. Stop listening to others

Should one become fullstack dev or stay sane and stick to react frontend? :)


I would suggest neither and become a Solution Architect in 2019 and think about specialization in the next 3 years to ensure job security and career growth.

I was full-stacker for 12 years but stopped because the market is now being saturated by full-stackers coming out of bootcamps. Even though I'm a master of the full-stack I was seeing salary cap at 120K CAD. This may be good pay for someone 3 years into their career but over a decade in and with a growing family, not something that would work for me.

Front-end is honestly a dead-end for career growth especially front-end React. In Toronto its the most requested job but once the React work is done most people are let go 6 months to 1 year later because the react work is done. I tried to warn bootcamp graduates and sad to see it happen so frequently.

AWS is so much in demand if you hold an AWS Professional Certification you can see salaries starting at 100K CAD and not uncommon to see 140K CAD+. This I believe won't last long as it should only take 2-3 years for the market to catch up since this is why I suggest thinking of specializing or having hybrid skills.


Great answer thanks for that. I have to agree that react/vue/angular frontend is dead end. Im currently on senior frontend position usually leading teams and i can see that you have either projects lasting up to 6 months(not stable) or long running projects usually telco or banking where i live(boring).
I really love writing code so managment role is out of the question for now. I guess i will give full stack a chance. Solution architect is bit ambitious i think since im professional only about 6 years


Both are impossible to master without being able to manipulate the concepts, e.g. without becoming at least an average software architect. After you become one, questions like these don't matter anymore – you just focus on the thing you're building and don't think of tools at all.


What is your criteria for deciding a database? Specially since relationships can be abstracted to a Mongoose ORM or a GraphQL data layer.


I'm usually using multiple databases, but my criteria are:

  1. How much data manipulation is needed? If there's the need for something more than just plain reads and writes, it's gonna be a SQL database
  2. Read-first vs write-first

Could you explain what you mean by read-first vs write-first?

Thanks for taking the time to answer this question :)

Read-first is when the read operations are way cheaper than writes. Write-first... you guessed it :)


What are your considerations for doing SSR for an app serving ~5K users? ~50K? ~500K?


As soon as SSR is nothing really special, this.


As someone coming from a mostly Python, R, and data analysis background, how would you recommend I become more attractive for Software Engineering related roles?


I'm afraid there's no universal solution here. I think you should definitely try building your own pet-projects and contribute to your own product hub like GitHub pages, maybe your dev.to profile :)


What's your approach on starting a big project?



The key point for me is to implement anything AFTER figuring out the exact requirements and business-logic cases.


How to implement master-detail relation structure in NoSQL?


Good topic to discuss.

I think many teams nowadays tend to choose NoSQL just because of that fancy Medium articles written by some guys wearing Ray-Bans. E.G. Just because it's "cool".

NoSQL is way trickier than one may think. I personally prefer to use NoSQL ONLY with some expressive backup like Clojure or some solid data management stuff happening on the backend. I don't trust those built-in JavaScript interpreters that databases have.

With that being said, I prefer to store entities as a flat structure with ids and fetching them on the backend. This approach won't be efficient if you need to do some data-intensive stuff, but NoSQL wasn't meant to do this in the first place.

If I need master-detail relations, I'll choose SQL because if today you need master-detail relation, tomorrow you'll need the full-blown aggregation from multiple sources.


Microservice Architecture on your own or Serverless?


Neither without a good reason.