As engineers we often hear about best practices, but we also see so many smart people disagree about what is or isn't best practice. While some things seem relatively clear and agreed upon many aren't. Many are often vigorously disagreed upon. These disagreements often happend between people at the top of their field. So what's the deal? Is one group just wrong?
I would like to posit that they can both be right but in different contexts. When you put a bunch of smart, motivated, passionate, and caring people together and give them a task to solve it is reasonable that they will do a good job within the context and constraints that they are working. Context and constraints being the key words there.
We all come from different places and are trying to solve different problems. To think that all our problems are the same and thus have the same solution is just as silly as to think that all our problems are completely unique. So many incredible people have come before us and we should learn from them and what they've found generally works. Within a given context we could call those "best practices" for that context. There is a tendency both to over apply solutions put forward by someone we respect or to in our excitement of our own solution misrepresent to others the scope of problems in which it is applicable.
I plan to go through a few of the current tech wars and expose the false dichotomy and advocate for making decisions based on your business, users, domain, and constraints.
Should you use a frontent framework? How do you know? The best way to think through this is what the common types of domain are, what server rendered vs frontend framework are each good at, and how the answers to those questions match up.
While not definitive I usually break projects into three categories (allowing for gray area).
- Apps with lot's of interactions, all behind a login, with plenty of both reads and writes, that the user spends lot's of time on.
- Sites that mainly display content often without a login and often reaching a page from a search engine, an where the user will likely leave shortly after reading The Content. There may be a login and data may be written and there may be user interactions but the most important case is getting that content to the viewer.
- Apps/Sites that are in between
What are each solution good at:
- Server render: Faster time to meaningful interaction and ability to read content. ow bandwidth when viewing one page and then done but have to re-incur more bandwidth for subsequent pages and site visits.
- Frontend Framwork: faster interactions after slower initial load time of the app. Higher initial bandwidth with less bandwidth for subsequent pages, actions, and site visits.
As we can see these match pretty neatly with the first two categories above. It's worth noting ompanies with lot's of complex interactions and lot's of time spent on site often use frontend frameworks whether it's Facebook with react or Google with Angular for it's non-search applications, or every data entry software worth it's salt. On the flip side we see companies like StackOverflow with lot's one off click from search, read the content, and leave championing server rendering (and not using an ORM), even Google that maintains Angular and Polymer uses server rendered HTML for search since that first page load is so critical.
With the third category we pick which of the first two categories it's closest to and use that as are base and progressively enhance throughout the life of the project or product as we have optimization budget. Companies like facebook and netflix both take this approach. For instance you could use a frontend framework but server render the initial state into HTML so that it will paint without needing to wait for data or javascript. You could also use server rendered before login, load the your JavaScript and the frontend libraries while the user is typing in their login info. You could server render most of your app but for a large and highly interactive part of the app that the user spends a lot of time on use a frontend framework and just make sure your components use the same style classes as your server rendered components.
For micro service vs monolith their are 4 main question for me:
- Number of teams
- How likely is it that you will need to scale one part of your app without scaling the entire app
- How big is your app
- What is your turnover rate
For companies with lot's of teams microservices are often the way to go as it allows multiple teams to work in a more structured manner with each team owning a service. The same goes for companies with more platform style applications or companies with large amounts of variable demand. If you have a platform with lot's of moving parts and lot's of areas that could see higher use at one point than another it's going to be much easier to scale individual sections without duplicating the resource usage of the whole app for every instance you need. Likewise if you do something where demand peaks for a certain critical path of your app at a certain time of day (like a traffic or navigation app) or when a certain event happens (imagine being ShowClix or TicketMaster) you may want to be able scale that critical path only to meet demand and then scale back down. Microservices are also great for high turnover companies or companies that heavily use contractors, as it enables developers to not have to know as much of the domain and to be able to do meaningful and valuable work much more quickly. This is part of why they have gained so much popularity in Silicon Valley where both the turnover and the growth rate are so much higher than other local tech sectors.
Monoliths on the other hand are generally faster to get initially developed and for a single product often easier for a 1-2 teams to maintain if the company has low turnover or is still early enough to have the original developers. This makes them great for companies that are just finding product market fit. It also makes them a great fit for single product, slow growth, low turnover companies. Basecamp is a great example: they have prioritized retaining devs, they have commited to low product count, and value profit margin over excessive growth. For them their monolith is scalable based on how they want to scale.
In practice most companies end up somewhere in the middle and will want to have a core monolith that they gradually break services out of, and if they have high growth ambitions eventually going full microservice. But again every company is different and your specific companies ambitions, values, domain, and constraints will determine the best course of action.
There are a lot of things that each version is good at.
MicorORMs and Store Procs are amazing for queries especially retrieving unrelated content or reporting style queries that combine lot's of data in ways that aren't easily modeled as parent/child relationship, they excel both at performance and ability to easily write these complex queries but they can be difficult to maintain for apps that have complex write logic or lot's of writes or logic that fits more of an current record/document model. NoSQL is great for apps that read and write pretty much the same data and list it in simple ways but does not do as well with complex queires. ORMs allow modeling incredibly complex data in a way that is easy to right balanced code that is decent at both reads, writes, queries, and other interesting combinations their of this often comes at a slight performance cost but is probably the most balanced solution for organizations with moderate user count and high levels of domain complexity and/or large numbers of developers.
Trying to decide what to use when can be complex but content sites often do well with MicroORMs and NoSQL because of the lightning fast reads that often go with it. Complex domain B2B apps that sell to a small number of customers who log in and do lot's of different things are usually best served by an ORM. Apps that need speed and mostly read and write in a documentish format with out a lot of data relation usually work better with NoSQL. Apps that are reporting orienged often work well with MicroORMS if it's more static table based reporting or ORMs if it's more dynamic user interactive reporting.